The Problem Statement
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 toolThe framework
A 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”
Try it yourself
What it prevents
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. |
Step by step
Name the user type specifically
Not “users” — a specific segment in a specific situation. The more precise the who, the more useful the statement.
Describe the goal as an outcome, not a feature
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.”
Provide the insight — the root cause, cited
Say why the gap exists, and cite the research that revealed it. An uncited “why” is an assumption wearing a lab coat.
Add the measurable signal
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.
Check it's solution-free
Read it back. If a specific feature is implied or named, strip it out. The statement should admit many possible solutions.
A short illustration
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 statement, stress-tested
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 |
Why it matters
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.
Common mistakes
“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.
When not to use it
- The problem is genuinely trivial and known. A typo fix doesn't need a formal statement — reserve it for work where the problem is contested or fuzzy.
- You have no research yet. The “why” should be cited; if you have nothing to cite, do discovery first, then write it.
- You're already in delivery on a validated problem. Don't re-litigate — reference the statement, don't rewrite it each sprint.
Where this sits in the toolkit
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.
Reframe a feature request as a problem
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.
New tools and AI deep-dives, occasionally.
No spam. Unsubscribe anytime.