Problem Statement Template

What is it?

A problem statement is a short, shared, solution-free definition of what you're solving: who has the problem, what they're struggling to do, why it matters, and how you'll know it's fixed.

What problem does it fix?

It stops the most common product failure: jumping to solutions before the team agrees on the problem. Without one, you build for a fuzzy target, scope creeps, stakeholders quietly disagree on what "done" means, and you can't tell if you actually succeeded. It's the cure for solution-first thinking.

The one big idea

A well-defined problem is half-solved. Keep the problem and the solution apart, and describe the problem as the user's struggle and the outcome they want - not the feature you already have in mind. Fall in love with the problem, not the solution.

The template

Pick the format that fits the moment. Keep all of them solution-free.

1. The "Mad Lib" - fast, user-centred.

[User] needs a way to [do something] because [surprising insight].

2. The structured PM version - for a PRD.

[Who] is trying to [goal], but [obstacle], which causes [impact]. Today they [workaround], which falls short because [why]. We'll know it's solved when [success metric].

3. The gap format - for stakeholder alignment.

Current state: … Desired state: … Gap / obstacle: … Why it matters (impact + metric): …

The steps - how to do it

Start from the struggle, not the solution - combine product data (drop-offs, churn, friction) with real user research.
Name who's affected and the situation where the pain shows up.
Find the root cause using the 5 Whys - separate symptom from driver.
Define the gap - current state vs. desired state.
Write it solution-free using one of the templates above.
Attach evidence and a success metric so "solved" is measurable.
Reframe as "How Might We…" to kick off ideation.

What you get out of it

Alignment - one definition the whole team and stakeholders share.
A solution-agnostic brief that keeps your options open during discovery.
A measurable bar for success that ties cleanly to your North Star and OKRs.
Tighter scope and less scope creep.
A ready ideation prompt (the HMW reframe) and a strong foundation for the PRD.

It's also cheap and fast - minutes of writing can save weeks of building.

When to use it - and when not to

Use it when you're:

Kicking off discovery or a new feature.
Writing a PRD.
Aligning stakeholders who don't yet agree.
Testing whether an idea solves a real problem.
Prioritising a backlog.

Don't over-ceremony it when:

The problem is trivial and universally understood (a one-line bug fix doesn't need a template).
You're mid-execution and tempted to re-litigate.
You're trying to rubber-stamp a solution you've already chosen - that's the failure mode, not a use case.

Common mistakes

Smuggling the solution in. "Users need a dark-mode toggle" is a solution, not a problem.
Vague and unfalsifiable. "Improve engagement" can't be solved or measured.
No user, no impact, no metric - then it's an opinion, not a problem statement.
Stating a symptom, not the root cause.
Wrong altitude - too broad ("fix onboarding") or too narrow ("move the button 4px").
Write-once-and-forget - problems evolve; revisit the statement.

Worth knowing its limits, too: a problem statement doesn't size the problem (pair it with data and willingness-to-pay evidence), and a weak insight produces a weak statement - garbage in, garbage out.

How it fits with other frameworks

Jobs To Be Done - the job defines the problem space; the problem statement articulates one struggle within it.
Design Thinking / Double Diamond - it's the output of the Define stage.
5 Whys - feeds the "why" in your statement.
How Might We - the bridge from a defined problem into ideation.
Amazon Working Backwards (PR-FAQ) - a sharp problem statement is the seed of the press release.
Lean Canvas - populates the "Problem" box; PRD / OKRs inherit its success metric.

A full example - Airbnb (2008)

Mad Lib:

Budget-conscious travellers need a way to find affordable, local places to stay when hotels are full or too expensive - because the existing options force a trade-off between price, authenticity, and trust.

Structured version:

Who: travellers at peak-demand events (and, separately, people with spare rooms). Trying to: find affordable, welcoming lodging - or earn from unused space. Obstacle: hotels sell out and spike prices; informal options feel unsafe. Impact: travellers overpay or skip trips; hosts leave money on the table. Workaround: expensive hotels or couch-surfing - each inadequate on price, trust, or availability. Solved when: travellers can book a stranger's space with confidence, and hosts get paid safely.

Reframe:

How might we make booking a stranger's home feel as safe and easy as booking a hotel?

Notice it never says "build a marketplace with reviews and secure payments." Those solutions fall out naturally once the real problem - mostly a trust and availability gap - is named clearly.

Problem statements behind famous products

The core problem each set out to solve, in one line:

Uber - People can't reliably get a ride when they need one, with zero visibility into whether it's coming.
Spotify - Music fans want instant access to any song, but are stuck choosing between paying per track or pirating.
Dropbox - People work across devices, but their files are trapped on one machine - painful to access and share.
Slack - Teams lose time and context because work talk is scattered across email and tools, with no searchable home.
Netflix - Renting movies means store trips, limited stock, and punishing late fees.
Canva - Non-designers need professional visuals, but pro tools are too complex and hiring a designer is too slow.
Stripe - Developers want to accept payments online, but legacy systems take weeks of painful setup.

Who made it?

There's no single inventor - it blends several traditions:

Management consulting and the scientific method popularised hypothesis-driven problem definition.
Toyota's 5 Whys (Sakichi Toyoda) gave us root-cause thinking.
Design Thinking at Stanford's d.school and IDEO (David Kelley, Tim Brown) produced the POV "Mad Lib." "How Might We" traces to Min Basadur at Procter & Gamble in the 1970s, later popularised by IDEO and Google.
Gause & Weinberg's Are Your Lights On? (1982) is a foundational text on problem definition.
Amazon's Working Backwards / PR-FAQ is the influential modern corporate version.

(The famous Einstein line about spending 55 of 60 minutes defining the problem is almost certainly apocryphal - but it captures the spirit.)