There is a particular kind of failure that looks like success right up until it doesn't. The team shipped on time. The code is clean. The metrics dashboard is wired. And nobody uses the thing.
Post-mortems on these projects tend to reach for execution explanations — we were understaffed, the timeline slipped, the launch was quiet. Those are rarely the real cause. The real cause is that the problem statement was never interrogated, and everything downstream inherited that defect faithfully.
Vague problems produce confident solutions
Here's the trap: a vague problem statement is easier to agree on than a sharp one. "Users are struggling with onboarding" gets unanimous nods in a room. "New users abandon at the workspace-creation step because we ask for information they don't have yet" gets an argument — because it makes a claim that can be wrong.
The first statement lets everyone build a different product in their heads and believe they're aligned. The second one forces the disagreement to happen now, in a meeting, rather than in six weeks, in code.
A problem statement that cannot be wrong is not a problem statement. It is a mood.
The discipline is to keep pushing a problem until it makes a falsifiable claim about who is stuck, where, and why. That's uncomfortable, because it means committing to a theory that reality might reject.
The test I actually use
Before committing engineering time, I try to answer three questions in writing:
- Who specifically has this problem, and how do I know? Not a persona — a real observed behavior, ideally in data or a transcript.
- What are they doing instead today? Every unsolved problem has a workaround. If there is no workaround, the problem may not be painful enough to matter.
- What would falsify this? If I can't name the result that would tell me I was wrong, I don't have a hypothesis, I have a preference.
If any of the three comes back thin, that's the signal to spend another few days on framing rather than starting the build. It always feels like delay. It's almost always cheaper than the alternative.
Framing has a shelf life
None of this argues for indefinite analysis. Problem framing has sharply diminishing returns, and there's a point past which the only way to learn more is to ship something and watch what happens.
The skill is recognizing that point. It arrives when your remaining uncertainty is about how people will behave rather than what you're actually trying to solve. Behavioral uncertainty resolves through contact with reality. Definitional uncertainty just gets more expensive.
Ship at the first, not the second.