The confusion, and why it's expensive
A problem is a thing that goes wrong for someone. A solution is one way of stopping it. Founders reliably fall in love with the second and then defend it as though it were the first — which is why so many careful, well-built products fail. The build was never the weak part.
The tell is in the sentence. "People need a dashboard for their invoices" is a solution wearing a problem's clothes. The real problem underneath might be "I don't know which clients haven't paid me," which a dashboard could solve — or which one weekly email could solve for a hundredth of the effort.
| Stated as a solution | Stated as a problem |
|---|---|
| We need an AI chatbot for support | Customers wait two days for answers to questions we've answered before |
| We need a mobile app | People need this while standing in a warehouse, not at a desk |
| We need an integration with X | The same data gets typed into two systems every morning |
| We need a dashboard | Nobody knows which numbers changed this week |
Why stating it as a problem changes the work
A problem statement gives you a target you can hit several ways, which means you can pick the cheapest one first. A solution statement gives you a spec, which means the only thing left to do is build it — and if the build was the wrong answer, you find out at the end.
It also changes what "done" means. If the problem is that invoices go unchased, then a product that ships every planned feature and still leaves invoices unchased isn't finished — it's failed politely.
Getting to the real problem
When someone hands you a solution — and they usually will, because people are helpful — walk it backwards by asking what it's for, repeatedly, until the answer stops changing.
How to hold both correctly
- Write the problem on its own line, with no product in itIf a noun in that line is a thing you'd build, rewrite the line.
- List three solutions, not oneDeliberately include one embarrassingly manual option. It's often the right first move, and it's always the fastest test.
- Pick the cheapest one that would genuinely fix itCheapest in your time, not in features.
- Keep the problem line visible while you buildEvery feature request gets checked against it. Requests that don't serve it aren't wrong — they're a different problem, and they wait.
Common mistakes
- Writing a problem statement that contains the product name
- Asking users what they want instead of what happened last time it went wrong
- Treating a feature request as the problem rather than as one person's proposed solution
- Solving a real problem for the wrong person — the one who feels it but can't choose to buy
Key takeaways
- A problem is what goes wrong; a solution is one way to stop it. Only one of them should be fixed
- Solution-first thinking hides in ordinary sentences — look for the product noun
- Walk requests backwards until the answer stops changing
- Always list a manual option among your solutions; it's the cheapest test available
Try it yourself
Take your current idea and write its problem statement with no product nouns in it — no app, no dashboard, no platform, no tool. If the sentence becomes hard to write, that difficulty is the finding.