You know that sinking feeling in your stomach right before a product launch? The PRD is finished, the design is pixel-perfect, the team has approved every detail. And then, a random conversation with a user pulls the rug out from under you.
You realize, with absolute horror, that you built the wrong thing.
This isn’t an execution failure. The engineering wasn’t sloppy, and the design wasn’t off-brief. You simply spent three months rigorously and professionally solving the wrong problem. I know because I lived it.
Early in my career, I was tasked with building a Lesson Plan module for an EdTech SaaS serving K-12 teachers. The directive was clear: teachers need lesson plans. It’s a universal requirement. I’d seen the standard administrative templates they use—teaching goals, key points, post-lesson reflections. So, I built a highly structured, table-driven lesson plan generator. It was logical, professional, and completely wrong.
At a dinner party, I mentioned the project to a friend who happened to be a teacher. I casually asked how she used lesson plans.
Her response made my heart drop: “Oh, those structured tables? Those are just bureaucratic compliance documents we hand to the administration for inspections. For my actual classes, 90% of what I use is just notes on how to present the material, what examples to use, and where students get confused.”
We were building a compliance tool. The teachers needed a classroom execution tool. The requirement was identical, but the target scenario was completely different.
You didn’t fail at building the product. You failed at defining the problem.
I call this the “Narrow Framing Trap.” It’s the silent killer of product strategy. You take an open-ended question (“How do we help teachers?”) and unconsciously compress it into a closed solution (“Let’s build a lesson plan template”). You lock your thinking into “how it should look” before ever asking “what goal does this serve.”
The most dangerous part? You actually did your user research. You validated the need. The problem is that validating a need is not the same as anchoring to a goal.
If I had asked teachers, “Do you need a lesson plan feature?” 100% of them would have said yes. That need is real. But if I had anchored to a goal first—asking “Are we trying to help teachers pass admin inspections, or are we trying to help them teach better?”—the optimal solution would have been entirely different.
Asking users what they want is a trap. They don’t know what they want; they only know how they currently survive.
In the corporate world, narrow framing doesn’t look like an emotional knee-jerk reaction. It wears a convincing mask of “industry experience” and “professional judgment.” When you’ve seen a pattern before, your brain defaults to it. You mistake familiarity for understanding. And when the whole team agrees on the premise, questioning the premise feels like a waste of time.
So, you collaborate efficiently to build the wrong thing. Faster.
To stop this from happening again, you have to break the inertia. Here are three immediate actions to embed into your workflow:
1. The 10-Second Question Flip
Whenever someone says, “We need to build [Feature X],” stop. Do not evaluate feasibility. Force a mental flip: change a solution-question into a goal-question. “Should we add a points system?” becomes “How do we improve user retention?” “Should we rebuild the export tool?” becomes “How do we solve the pain of slow data extraction?” Ten seconds of refraining breaks the illusion that the default solution is the problem itself.
2. Ask “How,” Never “What”
If I had asked teachers, “What should a lesson plan include?” they would have regurgitated the administrative standard. Users default to giving “professional” answers. Instead, ask: “Walk me through how you prepared for your last class.” “What materials did you open?” “What did you write by hand?” You must observe their workflow, not interrogate their wishlist.
Familiarity is the most dangerous shortcut in business. “I’ve seen it” masks itself as understanding.
3. Weaponize Skepticism Against Your Own Expertise
The moment you feel the confident rush of “I understand this requirement,” hit the brakes. That exact certainty is what blinds you to the context you’re missing. Ask yourself: “Is the scenario in my head the same scenario the user actually lives in?”
Most direction mistakes aren’t failures of execution; they are failures of imagination. We draw a boundary around a problem, assume the boundary is correct, and then act shocked when the polished product misses the mark.
Perfect execution of the wrong problem is the most expensive mistake in business. Don’t just pick the right solution. Pick the right boundary.
FAQ
Q: What if users explicitly tell me what feature they want?
A: Ignore their solution and watch them work. Users can only describe how they currently survive a broken process, not what will actually fix it. Your job is to find the goal behind their frustration.
Q: What's the practical implication for my next sprint?
A: Stop debating feature specs on day one. Spend the first half of your planning meeting debating whether the problem boundary itself is correct before writing a single line of code or designing a single screen.
Q: Isn't this just overcomplicating standard agile development?
A: No. Agile makes you incredibly efficient at executing the wrong thing faster. Defining the goal before the solution is the only way to ensure you aren't just shipping a polished failure every two weeks.