Problem Statement

What is a Problem Statement?

A problem statement is a short, evidence-backed description of a user problem worth solving. It names the user, the context, what’s getting in their way, and the impact, without telling the team what to build.

Use it when: you need the whole team to agree on what’s broken before anyone proposes a solution.

Copy/paste template

Use this when you need something the whole team can align on in five minutes:

For [user / segment]
who are trying to [goal / job to be done]
in [context / situation]
the current experience [what happens today]
causes [pain / friction], resulting in [impact on user + business].
We believe this is true because [evidence: interviews, tickets, data].
We’ll know it’s improved when [metric / observable outcome] within [time window].
Constraints: [non-negotiables: legal, tech, brand, time, cost].

Why Problem Statements Matter

Prevents solution-first thrash: you stop debating features and start debating reality.
Makes trade-offs legible: scope decisions get easier because the “why” is explicit.
Improves execution: design, engineering, and stakeholders pull in the same direction without constant re-explaining.

What a good Problem Statement includes

Checklist (include what you know, not what you wish you knew)

User: who experiences this (and who doesn’t)?
Context: when and where it shows up (device, workflow, environment, trigger).
Goal: what they are trying to accomplish.
Current state: what happens today, step-by-step if needed.
Friction: the specific breakdown (confusion, delay, errors, drop-off, workaround).
Impact: what it costs (time, money, trust, churn, risk).
Evidence: what you’ve seen (quotes, tickets, session replays, funnel data).
Success signal: what will change if you fix it (metric + behaviour).
Constraints: boundaries you cannot ignore.

Common Formats

Pick one format, do not collect them like Pokémon.

The 5W format

Who is affected?
What is happening?
Where does it occur?
When does it occur?
Why does it matter?

The user story (diagnostic version)

“As a [user], I’m trying to [goal], but [obstacle] stops me, which leads to [impact].”

The opportunity format

“Our [user] needs a way to [goal] because [limitation + insight].”

How to Create a Strong Problem Statement

A fast, research-backed flow

Gather evidence

Interviews, support tickets, session replays, analytics, sales calls.

Name the moment

The specific point in the journey where things break.

Quantify the cost

Time lost, conversion drop, errors, escalations, churn, risk.

Write the first draft

Use the template above. Keep it short.

Pressure test it

Use the quality checks below.

Validate with users

“Is this your reality?” beats stakeholder agreement every time.

Quality checks (five tests)

A strong problem statement is:

Solution-neutral: it describes the issue without prescribing features.
Specific: a real user in a real context, not “users” in general.
Evidenced: it points to what you observed, not what you assume.
Measurable: it defines the signal that would improve if solved.
Actionable: it’s narrow enough to address, broad enough to allow options.

Weak vs strong examples

Weak: “Users need a better way to organise files.”

Strong: “Freelance designers waste time searching for project files across Drive, Dropbox, and email threads, causing missed deadlines and tense client handovers. Evidence: repeated support requests, interview quotes, and a high rate of ‘search’ retries. We’ll know it’s improving when file retrieval time drops and fewer projects require manual re-sends.”

Examples Across Industries

E-commerce

“Shoppers reach checkout and hesitate when extra costs appear late, leading to abandonment. They need earlier clarity on total cost in the journey so they can commit confidently.”

Healthcare

“Clinicians spend a large portion of appointments documenting rather than engaging patients, reducing care quality and increasing burnout. They need a faster way to capture notes without losing the human moment.”

Education

“First-year students who lack informal support struggle to find resources and community early, increasing dropout risk. They need clearer pathways to help and belonging in the first weeks.”

Common pitfalls

Burying the user: if it starts with tech, you’ve already lost it. → Do this instead: lead with who is affected and in what situation.
Sneaking in the solution: “needs a dashboard” is not a diagnosis. → Do this instead: describe the friction and impact; leave the solution out.
Vagueness: if it could describe ten products, it won’t guide one. → Do this instead: name a specific user, moment, and cost.
No evidence: you cannot align a team around a hunch. → Do this instead: cite interviews, tickets, or data before you lock the statement.
Unmeasurable success: “better” is not a metric. → Do this instead: define the observable outcome and time window.

Problem statement vs solution statement: the first describes what’s broken; the second what you plan to build. If you can add “by building X” at the end, you’ve drifted into solution.
Problem statement vs goal: a goal is the outcome you want (often business-first); a problem statement is what’s broken for the user and why it matters.
Problem statement vs user story: user stories are a delivery format for requirements; a problem statement is a diagnosis the team aligns on before writing stories.
Problem statement vs hypothesis: a hypothesis is a testable bet about a change; it often follows and builds on the problem statement.

Jobs to be done – frames the “job” the user is trying to get done; often feeds into problem framing.
User stories – delivery format for requirements; keep them grounded in a clear problem statement.
User research – where evidence for problem statements comes from.
Value proposition – the promise you make once you’ve agreed the problem; don’t skip the problem step.
Lean canvas – problem block is where a tight problem statement sits.
Continuous discovery – ongoing practice of validating and updating problem understanding.
Feature prioritisation – easier when the “why” is explicit in a problem statement.
A/B testing – tests solutions; start from a clear problem so you know what you’re optimising.

Next step

Write one draft using the template above, then read User stories to turn that problem into shippable requirements.