Writing sharp problem statements
Turn a vague issue into one clear, decision-useful sentence a team can act on.
If the team can't tell whether a solution solves it, the problem statement isn't done yet.
A blurry problem produces confident, scattered work
"Onboarding is bad." "Users are confused." "We need to improve retention." These feel like problems, but a team can't act on them — because any change can be argued to help, and none can be argued to be enough. Everyone points their existing agenda at the fog.
A sharp problem statement does one job: it makes solutions falsifiable. Once it's written well, you can hold any proposed fix up against it and ask, 'does this move that?' — and get a real answer. That's the whole point. Not eloquence. Decision-usefulness.
Blurry vs sharp
Blurry statement
Feels true, can't be acted on.
- "Onboarding is confusing."
- Who? At which step? Confusing how?
- Every idea can claim to help
- No way to know when you're done
Sharp statement
Names who, where, and the cost.
- "New self-serve users abandon at the API-key step; 40% never return."
- Located in a segment and a step
- Ideas either move that number or don't
- Success is unambiguous
Tightening three vague issues
"Search is bad"
Search is bad and people complain about it.
Users who search for a product by exact name get zero results 15% of the time, then leave without browsing.
Names the query type, the failure, and the consequence — a fix either lowers that 15% or it doesn't.
"We need better retention"
Retention is too low; we should improve it.
Teams that don't invite a second member in week one churn at 3x the rate of those that do.
Ties the outcome to a specific early behavior you can actually influence.
"The app feels slow"
The app feels slow and clunky.
The dashboard takes 6s to load for accounts with 10k+ records — our largest, highest-paying accounts.
Locates the pain in a measurable place and flags who bears it, so priority is obvious.
Take a problem your team is working on right now. Can you state it so that a proposed feature either clearly addresses it or clearly doesn't? If not, what's still missing?
A problem statement is finished when the team can look at any solution and agree whether it helps. Until then, you're still describing a feeling.