Product planning
Write a product problem statement from evidence
A problem statement says who is trying to do what, what stops them, and how you know. Use it to focus a feature discussion. If a sentence prescribes a button, screen or tool, check whether it names a solution before explaining the problem.
A text to start with
I'm drafting a problem statement for [product or area]. The user is [who]. They are trying to [task]. What I have so far: [interview notes, support messages, usage data or observations, with dates and sources]. Write a draft statement in two or three sentences. Mark each claim with its evidence and list claims that have none. Do not suggest features.
Example request. Change the details to fit your situation.Problem statement worksheet
User (a specific group, not "everyone"): [ ] Task they are trying to complete: [ ] Current obstacle, described without naming a fix: [ ] Evidence 1 (source, date, who it came from): [ ] Evidence 2 (source, date, who it came from): [ ] Evidence 3 (source, date, who it came from): [ ] Consequence for the user: [ ] Consequence for the organization, if known: [ ] Claims with no evidence yet: [ ] How I could get evidence for each: [ ] One-sentence statement: [ ] People who reviewed it and what they changed: [ ]
Solutions hiding in the wording
Look for phrases like "users need a dashboard" or "there is no export button." Ask which task the person cannot finish and what the missing interface prevents them from doing. Check that every obstacle traces to something a person said or did, and that the evidence comes from the people named as the user. Label a single complaint as one person's account. Describe consequences for the user and, where supported, for the business. Keep unsupported claims in a visible list so they do not blend into the statement.
Ask another agent to check the result
Read this problem statement and quote any phrase that names a solution instead of an obstacle. Then list every claim without a cited source, and every claim whose evidence comes from people other than the stated user. Quote the exact wording for each. Do not propose features.
Test the statement with the people it describes
Share the statement with two or three people close to the user, such as researchers, support staff or users themselves, and ask what is missing or wrong. Record their corrections beside the original wording. For each claim without evidence, decide whether to gather some or remove it. Once the statement holds up, link it from later feature discussions so proposals can be checked against it.