A useful problem statement describes an observed gap between what people need to accomplish and what happens today. Include the affected group, the task or process, the conditions where the gap appears, and its consequence. Keep a preferred solution and an unverified cause outside the statement so they remain open to investigation.
There is no single mandatory problem statement format for every organization. The format below is a practical writing aid. It works for a product discovery, project proposal, or recurring issue found in a team retrospective.
The principle of understanding the problem before committing to a solution also appears in the GOV.UK discovery guidance. The examples and workshop in this article are original hypothetical illustrations, not reported customer results.
A copyable problem statement format
Use this as a starting sentence:
When [context], [affected group] needs to [task or desired outcome], but [observed gap]. Evidence from [source and period] shows [scope or frequency, if known], which results in [supported consequence].
Then add a short evidence note:
- Known: observations that support the statement.
- Unknown: questions that could change the interpretation.
- Outside scope: adjacent problems this effort will not address.
- Success signal: what observable change would matter.
Do not force a number into every blank. “Frequency not yet measured” is more trustworthy than an invented baseline. If the source covers a small or unusual sample, name that limit. A statement should become more precise as evidence improves.
What belongs in the statement?
| Element | Useful wording | Wording to challenge |
|---|---|---|
| Affected people | New account administrators | Everyone |
| Task | Invite colleagues and confirm access | Use our product better |
| Observed gap | Cannot distinguish pending from accepted invitations | Need a dashboard |
| Context | After sending multiple invitations | Always |
| Consequence | Contact support to confirm status | Lose millions in productivity |
| Evidence | Reviewed cases from a named period | It is obvious |
A consequence can be qualitative. For example, a user needing help with an otherwise self-service task is meaningful even before its financial cost is known. Do not translate every inconvenience into revenue loss without a defensible method.
Worked example: from request to problem
Hypothetical example: a project starts with the request, “Build an invitation dashboard.” That is a solution proposal. The team could build it correctly while solving the wrong problem.
During discovery, the team reviews twelve support conversations from a defined month and observes four administrators completing the invitation task. Several ask whether an invitation was delivered or accepted. Those observations suggest a problem worth investigating, but they do not establish its prevalence across all customers.
A better statement is:
After inviting several colleagues, account administrators need to confirm who can access the workspace, but the invitation screen does not distinguish pending and accepted invitations. Support conversations and four observed sessions show administrators seeking confirmation elsewhere, adding a manual check to the onboarding process.
The team adds two unknowns: whether the uncertainty occurs outside the observed account types, and whether delivery failures also contribute. Possible responses now include clearer status labels, a confirmation message, an activity view, or changes to the invitation process. The statement does not choose among them prematurely.
Three common formats and when to use them
Short decision statement: use two or three sentences in a project brief when readers need the problem quickly. Include a link to evidence rather than attaching the entire research record.
Current state, desired state, gap: use this when a process has a defined expectation. Describe today, explain the required condition, and name the difference. Verify that the desired state is actually required, not just a manager's preference.
User, task, obstacle, consequence: use this when a product or service problem begins with someone's experience. Include operational constraints so the statement does not imply that a screen change alone can fix a wider process.
These are writing structures, not competing methodologies. Choose the smallest one that makes your decision clear. If a single sentence becomes unreadable, use a paragraph and a supporting table.
Run a 35-minute problem-framing workshop
Bring people who experience the problem and people who can interpret the evidence. Include someone who can challenge the assumed solution. Send the source material in advance and explain which claims are still uncertain.
- Five minutes: read silently. Each participant marks observations, interpretations, and proposed solutions in different ways.
- Eight minutes: write separate statements. Ask everyone to describe the gap without naming a product, tool, or implementation.
- Ten minutes: compare boundaries. Discuss who is affected, which context matters, and what lies outside the effort.
- Seven minutes: write one shared version. Keep disputed claims in an uncertainty note.
- Five minutes: choose the next evidence step. Name the owner and the decision the evidence will inform.
The purpose is not unanimous confidence. It is an inspectable statement that shows where confidence ends. If the group cannot agree on the affected population, the next task may be research rather than a solution workshop.
Check for hidden solutions and unsupported causes
“Customers need an AI assistant” prescribes a technology. Ask what task is difficult and what outcome they are trying to achieve. A technology can remain in the options list without becoming the definition of the need.
“Requests are delayed because the team does not care” asserts motivation without evidence. Replace it with an observable condition, such as requests remaining unassigned after a handoff, then investigate why that condition occurs.
“Communication is poor” is too broad to guide action. Identify which information, between whom, at what decision point, and with what consequence. The answer may expose several separate problems. Split them rather than creating a statement nobody can own.
A retrospective is one way to find recurring gaps in team work. Use a simple board format to collect observations, then bring the selected issue into this problem-framing process.
Decide whether the statement is ready
Ask a colleague unfamiliar with the project to read it. Can they identify the affected person, describe what goes wrong, and suggest two different responses? If they can only repeat your preferred solution, revise the statement.
Then check traceability: each factual claim should connect to evidence, and each assumption should be labeled. Agree when the statement will be revisited. New evidence may narrow the problem, reveal another cause, or show that the problem does not justify further work.
After a change is tested, inspect it through the retrospective improvement process. Completing an implementation is not the same as closing the observed gap.
Frequently asked questions
How long should a problem statement be?
Usually a short paragraph is enough for the statement itself. Keep evidence, assumptions, and boundaries in a supporting note so precision does not make the main statement unreadable.
Should a problem statement include the solution?
Keep the solution separate unless the context explicitly requires a constrained implementation. Even then, explain the problem independently so readers can judge whether the chosen response addresses it.
What if we do not have quantitative evidence yet?
Use concrete qualitative observations and describe their limits. Record the missing measurement as a next step rather than fabricating a frequency, cost, or expected benefit.