Writing a Problem Statement That Holds Up
Most problem statements are a solution wearing a costume. Here is how to strip it off.
You open the kickoff doc and the problem statement reads: 'Users need a better way to manage notifications.' Everyone nods. Design starts sketching a notification centre. Engineering starts scoping a preferences service. Six weeks later there is a beautiful notification centre, and the actual complaint, which was that the system emailed people at two in the morning about things they did not care about, is untouched.
That statement failed because it contained a solution ('a way to manage notifications') and a verdict ('better') and no evidence. It was a wish written in the grammar of a problem. Anybody could agree with it, which is the tell. A problem statement that everyone agrees with immediately has usually not said anything yet.
Four parts of a problem statement that holds up
- The person
- A specific segment doing a specific job, in words they would recognise. 'Ops coordinators covering the weekend shift', not 'users'.
- The situation
- When and where this bites. Problems have triggers. If you cannot say when it happens, you probably have a complaint rather than a problem.
- The obstacle
- What actually stops them, stated in terms of the world rather than your product. 'They cannot tell which alerts are urgent until they open each one.'
- The evidence
- How you know, and how widely it holds. Interviews, tickets, session data, sales calls. With a count, even a small one. Six of nine beats 'customers tell us'.
The obstacle line is where most statements quietly fail. Watch the difference between 'they have no way to filter alerts' and 'they cannot tell which alerts are urgent until they open each one'. The first is a missing feature. The second is a human difficulty, and it admits several answers: filtering, yes, but also better subject lines, severity in the preview, batching the low priority ones, or sending fewer alerts in the first place. Write the obstacle in terms of the world and you keep your options.
Solution in disguise
- Users need a bulk edit mode.
- The dashboard needs to be redesigned.
- We need SSO.
- Onboarding should be shorter.
Problem stated properly
- Account admins updating seat assignments after a reorg change 30 to 80 records one at a time, and abandon it partway. Seen in 5 of 7 interviews.
- New managers open the dashboard, cannot tell which of nine tiles answers 'are we behind', and go ask someone in chat instead. 4 of 6 sessions watched.
- IT buyers at companies over 500 seats cannot approve us without central account control, and have blocked two deals at security review this quarter.
- Trial users who reach step four of setup drop off at the integration step, because it requires credentials they do not personally have.
Look at the right column for a second. Every one of them could be wrong, and you could find out that it is wrong. That is the property you want. A problem statement is a claim about reality, and claims about reality can be checked. If your statement cannot be checked, it is not doing any work.
Worked example
Roost, property management software
The stated problem was 'landlords want better reporting'. The team rewrote it after five interviews: 'Landlords with 3 to 15 units are asked by their accountant each January for a per property income and expense summary. They currently build it by exporting three separate CSVs and joining them in a spreadsheet, which takes a full evening and which two of five admitted they get wrong.' That version told them the segment, the trigger (January, accountant), the current workaround, and the pain. It also ruled things out. A live analytics dashboard, which was the original idea, does nothing for a once a year accountant request. They shipped a single annual statement export and the January support spike went away.
Notice the workaround in that statement. People rarely sit still inside a problem. They build a spreadsheet, they keep a side document, they message a colleague, they do it manually at the weekend. Finding the workaround is the fastest way to confirm a problem is real, because effort is more honest than opinion. Somebody who spends an evening every January on your behalf has proven the problem exists better than any survey could.
Which of these is a problem statement
Three quick tests before you circulate it
- The disagreement test. Could a reasonable colleague read this and say 'I do not think that is true'? If not, it is too vague to guide anything.
- The three solutions test. Can you list three genuinely different ways to address it? If only one comes to mind, you have written a solution.
- The recognition test. Would the person described read it and say yes, that is my Tuesday? If it only makes sense in your product's vocabulary, you have written an internal problem.
One habit that costs nothing: put the date and the evidence count at the bottom of the statement. Six of nine interviews, January. Problems expire. Segments shift, workarounds get solved by someone else, a competitor changes the baseline. A statement with a date on it invites someone to ask whether it still holds, and that question is worth more than the statement itself.
Write the statement before the solution meeting, not during it. Once a room has started sketching, the statement becomes a justification exercise, and you will write whatever makes the sketch look inevitable.
Quick check
Which problem statement is most likely to lead a team to a solution that misses?
The takeaway
A problem statement earns its place when it names a person, a trigger, a real obstacle and the evidence, and when a reasonable colleague could still disagree with it.
Try this tomorrow
Take the problem statement on whatever your team is currently building and rewrite it in four lines: person, situation, obstacle, evidence with a count. Then list three different solutions it allows. If you cannot reach three, the statement is still a solution in disguise.
Answer the check above, then bank the day.
Where this comes from
- Continuous Discovery Habits, Teresa Torres
- The Mom Test, Rob Fitzpatrick
- Inspired, second edition, Marty Cagan
Product Thinking is one of six tracks. These lessons summarise and build on the work above, they do not reproduce it. Buy the books, they are better.