One precise sentence that says what problem you're solving, for whom, and how you'll know it's solved — the anchor that keeps discovery from drifting into solutions.
▸ Try the interactive toolA problem statement is a single, precisely worded sentence that defines what user problem is being solved, for whom, and how the team will know it's solved. It is not a feature description, a goal, or a metric target — it's a specific articulation of the gap between what a user is trying to accomplish and what they can currently do.
Its job is to be falsifiable and solution-free. A good problem statement names a real user, an outcome they can't reach, the root cause (cited from research), and a measurable signal that would tell you it's fixed — without smuggling in the solution. If your “problem” already contains the answer, it's a feature request in disguise.
Who — the specific user · What — the outcome they can't achieve (not a missing feature) · Why — the root cause, cited from research · Signal — the measurable definition of “solved”
Teams that skip the problem statement build solutions to problems they never agreed on — and discover the disagreement only after shipping.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Jumping to solutions | Work starts on a feature before anyone agreed what problem it solves. | A solution-free statement forces agreement on the problem first. |
| Vague targets | “Improve onboarding” means something different to everyone. | A specific user and outcome make the target unambiguous. |
| Unfalsifiable goals | “Make users happier” can never be proven solved. | A measurable signal defines done before work begins. |
| Solutions hiding as problems | “Users need a dashboard” assumes the answer. | Naming the outcome (not the feature) keeps the solution space open. |
Not “users” — a specific segment in a specific situation. The more precise the who, the more useful the statement.
State what the user is trying to achieve, not what they're missing. “Can't tell if they're making progress,” not “has no progress bar.”
Say why the gap exists, and cite the research that revealed it. An uncited “why” is an assumption wearing a lab coat.
State what you'd observe if the problem were solved — a behaviour or metric. This is the falsifiability test: if nothing could prove it solved, rewrite it.
Read it back. If a specific feature is implied or named, strip it out. The statement should admit many possible solutions.
A team wrote “users need a better onboarding checklist.” That's a solution. Reframed as a problem: “New users in their first week can't tell whether they're setting things up correctly, so they abandon before reaching value — confirmed in 4 of 5 interviews; solved when first-week drop-off falls below X%.”
The reframed version named the user, the outcome (can't tell if they're on track), the cited cause, and the signal — and crucially didn't name a checklist, leaving room for better solutions than the one originally assumed.
The deliverable is one sentence — but it has to survive four tests.
| Test | The statement fails if… | Fix |
|---|---|---|
| Specific user | It says “users” | Name the segment and situation |
| Outcome, not feature | It names a missing feature | Describe what they can't achieve |
| Cited cause | The “why” is an assumption | Tie it to interview or data evidence |
| Falsifiable | Nothing could prove it solved | Add a measurable signal |
| Solution-free | A solution is implied | Strip the answer back out |
A problem well stated is half solved — and a problem badly stated guarantees the wrong solution, perfectly executed.
The hardest discipline is keeping the statement solution-free. Teams are desperate to start building, and the fastest way to feel productive is to name a feature. But a statement that names the solution forecloses every better solution before discovery has even run. The restraint to say “here is the gap” without saying “here is the fix” is what makes the statement worth writing.
“Users need feature X” is a feature request. State the outcome they can't reach instead.
“Users” or “people” gives the team nothing to design for. Be specific.
An uncited root cause is a guess. Cite the research.
If nothing could prove it solved, you can never close it. Add the signal.
The cited “why” and the user's real outcome come from interview and JTBD work.
The statement is what the Discovery track is trying to solve; solutions are tested against it.
A clear problem makes solution ideation and RICE scoring far sharper.
Problem framing as a discipline — reframing, laddering, opportunity trees — is expanded in the discovery module.
Take a feature you or your team want to build. Write it as a problem statement instead: who, what outcome, why (be honest about whether you actually know), and what signal would prove it solved.
Check whether your statement secretly names the feature you started with. If it does, rewrite until it admits other solutions.
Often the act of reframing reveals you don't actually know the “why” yet — which is the most useful thing the exercise can tell you.
Related · Problem Framing →