The Difference Between Understanding a Problem and Solving It
Most teams skip the diagnostic phase entirely. Here's what that costs — and what the alternative looks like in practice.
Most teams skip problem definition entirely. They jump from “we should do something” to “here’s what we’re shipping” with nothing in between, no diagnostic, no map of the space, no shared picture of what’s actually broken.
It feels productive. It usually isn’t.
The diagnostic phase nobody runs
When a doctor sees a patient with a headache, they don’t immediately prescribe medication. They ask questions. They check vitals. They run tests when the answer isn’t obvious. The diagnostic phase isn’t a delay — it’s the part that makes the treatment land in the right place.
Product teams skip this phase routinely. Someone brings a request. Someone else has a hunch about the cause. A third person has a solution they’ve been wanting to ship. Within an hour, the team is debating implementation details for a problem nobody has actually defined.
What understanding looks like
Understanding a problem means you can:
- State it without naming a solution. “Checkout is slow” is a symptom. “Users are abandoning at the payment step at 3x the rate of the rest of the funnel” is a problem.
- Describe what changes when it’s solved. If you can’t finish the sentence “we’ll know this worked when…”, you don’t understand it yet.
- Name the constraints. What can’t change? What’s fixed by the business, the platform, the team?
That’s the work. It feels slower than jumping to solutions. It’s almost always faster overall.
The alternative in practice
You can fit a diagnostic into an afternoon. Block 90 minutes. Bring whoever has context. Write the problem statement together. Pressure-test it: does everyone agree on what we’re solving, in the same words, with the same scope?
If not, you don’t have a problem yet. You have a topic.