Problem Statement Canvas
A structured canvas for articulating a product problem from all angles — who has it, how severe it is, what they do today, why existing solutions fall short, and what success looks like. Free to copy, download, and use. No signup required.
# Problem Statement Canvas **Problem Title:** [Short label — e.g. "Onboarding drop-off", "Manual invoice matching"] **PM Owner:** [Name] **Date:** [Date] **Status:** Draft / Validated / Closed --- ## 1. Who Has This Problem? > Describe the specific person experiencing the problem. Not a persona card — a real human in a real context. **User segment:** [e.g. "Ops managers at logistics SMBs with 10–50 drivers"] **When does it occur:** [e.g. "At end-of-month reconciliation, every 4 weeks"] **How often:** [ ] Daily [ ] Weekly [ ] Monthly [ ] Episodic **User quote (if available):** > "[Verbatim quote from a user interview, support ticket, or survey]" --- ## 2. What Is the Problem? > One sentence. Lead with the user, not the system. **Statement:** [User/role] cannot [do X] because [constraint], which causes [consequence]. **Example:** "Ops managers cannot reconcile driver expenses in one place because mileage data lives in a spreadsheet and fuel receipts are emailed separately, which causes a 4-hour monthly manual merge exercise." --- ## 3. How Bad Is It? Rate severity and frequency to prioritize against other problems. | Dimension | Score (1–5) | Evidence | |---|---|---| | **Frequency** — How often does this happen? | | | | **Severity** — How painful is each occurrence? | | | | **Breadth** — What % of users are affected? | | | | **Business impact** — Tied to revenue / retention / NPS? | | | **Overall priority score (avg):** [X.X / 5] --- ## 4. What Do They Do Today? > Describe the workaround or current solution — even if it's bad. This is the benchmark you need to beat. - [ ] Manual process (describe): ___ - [ ] Competitor product (name): ___ - [ ] Custom internal tool: ___ - [ ] They don't solve it / live with the pain: ___ **Why the current approach falls short:** 1. [Reason 1] 2. [Reason 2] 3. [Reason 3] --- ## 5. Why Hasn't It Been Solved? > This is often the most honest question. If it were easy, someone would have built it. - [ ] Technical complexity (explain): ___ - [ ] Coordination problem (multiple teams/systems): ___ - [ ] Not previously prioritized: ___ - [ ] The pain is hidden / users don't articulate it: ___ - [ ] Other: ___ --- ## 6. What Does "Solved" Look Like? > Define success from the user's perspective before designing anything. **User outcome statement:** "After this is fixed, [user] can [do X] in [timeframe] without [the painful step]." **Measurable signal:** - [Metric 1 — e.g. "reconciliation time < 30 min"] - [Metric 2 — e.g. "zero manual spreadsheet merges"] --- ## 7. Constraints and Out-of-Scope **Hard constraints:** - [e.g. "Cannot require driver app change — drivers use personal phones"] - [e.g. "Must work within existing Stripe billing setup"] **Explicitly out of scope:** - [e.g. "Payroll processing — owned by Finance team"] - [e.g. "Real-time GPS tracking — separate roadmap"] --- ## 8. Open Questions | Question | Owner | Due | |---|---|---| | [e.g. "Do ops managers have API access to fuel card provider?"] | | | | [e.g. "Is the 4-hour figure representative or an outlier?"] | | | --- ## 9. Evidence Log | Source | Date | Key Finding | |---|---|---| | [User interview — Priya, Ops at LogiCo] | [Date] | [Finding] | | [Support ticket #4421] | [Date] | [Finding] | | [NPS survey comment] | [Date] | [Finding] |
How to use this Problem Statement Canvas template
Fill in Section 1 before anything else
The hardest discipline in problem statements is specificity. 'SMB ops managers' is a segment. 'Ops managers at logistics companies with 10–50 drivers who own monthly reconciliation' is a user. The more specific, the easier the rest of the canvas becomes.
Write the one-sentence problem in Section 2
Use the template: [User] cannot [do X] because [constraint], which causes [consequence]. If you can't fill in all four parts, you don't understand the problem yet. The 'because' clause is the hardest — and the most important.
Score severity in Section 3
The 4-dimension scoring is for relative prioritization, not absolute truth. A score of 2.5 vs 4.1 tells you which problem to work on next. Don't agonize over exact numbers — directional accuracy is enough.
Describe the current workaround honestly
If the workaround is 'a spreadsheet and 4 hours', write that. It tells you both the bar you need to beat and the workflow you need to fit into. Products that ignore the current workaround often get ignored.
Get the canvas validated by a user before writing requirements
Share Section 2 and Section 6 with 2–3 users and ask: 'Does this accurately describe the problem and what success looks like?' If they say 'sort of', the canvas needs revision. Validated problem statements cut rework by half.
Want a Problem Statement Canvas grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
What's the difference between a problem statement and a PRD?
A problem statement defines what problem exists and for whom, before any solution is proposed. A PRD documents the solution. Skipping directly to the PRD is how teams build the right feature for the wrong problem. The canvas should be written and validated before you open a PRD.
How long should this take to fill in?
If you already have user research, 30–60 minutes. If you're starting from scratch, 1–2 discovery interviews first, then 30 minutes. The canvas should surface what you don't know as much as what you do — treat gaps as research prompts.
How is this different from a 'How Might We' statement?
An HMW reframes the problem as an opportunity and is used as a design thinking prompt. This canvas is more rigorous — it forces you to quantify severity, describe current behavior, and define success. Use both: canvas to validate the problem, HMW to open up the solution space.
Section 5 asks why it hasn't been solved. Isn't that uncomfortable?
Yes, and that's the point. If the answer is 'it was never prioritized', that's fine — go build it. If the answer is 'three teams tried and failed', that's critical context. If it's 'technically very hard', you need to know that before writing user stories.
Should I fill in the Evidence Log before or after the canvas?
Before. The canvas should summarize evidence, not precede it. If you have no entries in Section 9, you're writing fiction. At minimum, 2 user quotes and 1 quantitative signal (support ticket volume, survey %, churn flag) before calling a problem validated.
Other free templates