Your problem statement is the whole project: how to write one

A good problem statement names who is affected, what happens to them, when and where it happens, and why it matters, in two or three plain sentences with no solution hidden inside. Write it from evidence, not opinion, say what is out of scope, and test it with people outside the team before you generate a single idea. Get this right and every later step, from ideas to prototypes to the business case, has something firm to stand on.

Why the statement decides the project

Teams rarely fail because they could not find ideas. They fail because they solved a problem nobody had, solved the wrong part of a real problem, or argued for weeks because each person was quietly solving a different one. The problem statement is where those failures start or stop.

Three things make it carry so much weight. It sets the boundary of what counts as a good idea. It tells you who to talk to and what to measure. And it is the sentence leadership will remember, so it shapes whether the work gets support. A vague statement does not stay vague; it gets filled in by whoever has the most authority in the room.

The five parts of a usable problem statement

A statement you can act on answers five questions:

1. Who is affected? A specific group, not "users" or "stakeholders". "First-time applicants with incomplete documents" is a who. "Customers" is not.
2. What happens to them? The observable situation, in their terms. Something you could watch or count.
3. When and where does it happen? The moment or channel. This is often where the real insight is hiding.
4. Why it matters, to them and to the organisation. The cost of leaving it alone: time, money, trust, risk.
5. What we know, and how. One line on the evidence: interviews, complaints data, observation. This keeps the statement honest.

Many teams add a sixth line that is just as useful: what is not the problem. Kepner-Tregoe's "is / is not" analysis is a classic way to do this. Stating that the issue happens with online applications but not in branches, for instance, narrows the search immediately.

How to write it, step by step

1. Write the first draft badly and fast. Each person writes their own version of the problem in one sentence, silently, in three minutes. Put them side by side. The differences between them are your first finding: they show where the team does not yet agree.
2. Strip out the solutions. Underline any word that describes a fix: "app", "portal", "training", "lack of a system". "We lack a booking system" is a solution in disguise. Rewrite each one as the situation people face: "Customers cannot tell in advance whether a slot is free."
3. Ask why, then ask what stops it. Use five whys or a problem tree to move from symptom to cause. Stop when you reach a level the team can actually influence. Go too deep and you end at "the economy"; stay too shallow and you only treat symptoms. For a full treatment, see how to find the root cause of a problem.
4. Go and check. Take the draft to five or six people who live the problem. Use stakeholder interviews and ask them to describe the last time it happened, not what they think in general. If their account does not match your statement, change the statement.
5. Fill in the five parts. Rewrite using who, what, when and where, why it matters, and what you know. Keep it to three sentences. If you need more, you probably have two problems.
6. Write the boundaries. Add one line on what is out of scope and one on the constraints you must respect, such as regulation, budget cycle or a system you cannot change this year.
7. Turn it into a point of view. A point-of-view statement, the user–need–insight format taught by the Stanford d.school, compresses the problem into one human sentence: "[Who] needs [need] because [insight]."
8. Open it up as questions. Only now write how might we questions from the statement. For examples of good and bad ones, see 10 "how might we" questions: five good, five bad.
9. Test it with an outsider. Read it to someone from another department. Ask them to tell you back what the problem is and who has it. If they cannot, it is not ready.

Before and after

Do's and don'ts

Do

• Write the statement in the language of the people affected, not internal jargon.
• Base it on something you observed or heard, and say what.
• Keep it short enough to say aloud in twenty seconds.
• Revise it openly when new evidence arrives, and keep the old versions so the team can see how its understanding changed.
• Use assumption mapping to list what you still believe but have not yet checked.

Don't

• Don't let the statement contain a solution, a technology or a department name as the cause.
• Don't write it in a meeting with no evidence and call it final.
• Don't make it so broad that any idea fits, or so narrow that only one idea fits.
• Don't use "lack of" as your main verb. It almost always hides a solution.
• Don't skip the "why it matters" line. Without it, the work will lose support at the first budget review.

Illustrative example

Illustrative. A city council in Australia asked its service team to "build an online portal for building permits". The team's first draft repeated the brief. Instead of starting the build, two team members spent a week at the permits counter and spoke to eight applicants and four assessors.

What they heard was different. Most applications were already submitted online. The delay came after submission: many of the applications they looked at had been sent back for missing information, and applicants did not understand the request letters. Assessors spent much of their day on phone calls explaining them.

The rewritten statement read: "Homeowners applying for small building permits often submit incomplete applications because the requirements are spread across several documents and the request letters use technical language. Each return adds weeks to the process and fills assessors' time with explanation calls. This applies to small residential works, not commercial developments."

The ideas that followed were cheaper and faster than a portal: a one-page checklist by project type, plain-language request letters and a short pre-submission call. The portal idea was not rejected; it simply stopped being the starting point.

Questions people ask

What is a good problem statement example? A good one names a specific group, describes what happens to them and when, says why it matters, and contains no solution. For example: "Night-shift nurses miss handover information because notes are written in three different places, which leads to repeated checks at the start of each shift."

How long should a problem statement be? Two or three sentences, plus a line on scope. If you need a full page, you are either describing several problems or including your solution. Short statements are easier to test, remember and share with leadership.

What is the difference between a problem statement and a "how might we" question? The problem statement describes the situation as it is, based on evidence. A "how might we" question turns it into an open invitation for ideas. Write the statement first, then derive several questions from it, each looking at a different angle.

Where to go next

Work through the problem tree and five whys guides to find the cause, then compress it with a point-of-view statement and open it up with how might we. For where this step sits in the wider process, read design thinking, step by step and the hub guide which innovation tool should I use.