What This Template Is For
A problem statement is the foundation of every good product decision. It defines who is affected, what the problem is, why it matters, and how you will know when it is solved. Without a clear problem statement, teams drift toward building features that nobody asked for or that solve the wrong thing.
The most common failure mode is jumping to solutions before defining the problem. A team hears "users want a dashboard" and starts designing a dashboard. A strong problem statement would reframe this as: "Marketing managers at mid-market SaaS companies cannot track campaign ROI across channels in one place, causing them to spend 3+ hours per week compiling data from 4 different tools, which leads to delayed budget decisions."
This template gives you three structured formats for writing problem statements at different levels of detail. Use it alongside the Product Discovery Handbook for the full discovery methodology. The customer journey mapping glossary entry explains how to identify problem hotspots in the user experience. For validating whether the problem is worth solving, the TAM Calculator helps you size the addressable market, and the RICE framework helps you score problems against each other.
When to Use This Template
- At the start of any new product initiative, before writing a PRD or spec
- When your team disagrees about what to build next and needs a shared frame
- After customer discovery interviews, to synthesize findings into a clear statement
- During quarterly planning to define problems that map to OKRs
- When a stakeholder requests a feature and you need to identify the underlying need
How to Use This Template
- Choose the right format. Use the Quick Format for lightweight problem framing (Slack messages, quick alignment). Use the Standard Format for most product work. Use the Deep Format for complex, high-stakes initiatives.
- Fill in every field. Blank fields usually mean you have not done enough research. If you cannot fill in "Current workaround," you need more customer interviews.
- Write from the customer's perspective. Use their words, not yours. Reference specific behaviors, not abstract frustrations. "Spends 3 hours compiling spreadsheets" is stronger than "has difficulty tracking metrics."
- Run the quality checklist. After writing your statement, evaluate it against the rubric in Part 4. A score below 15/25 means the statement needs more customer evidence or specificity.
- Share it before solutioning. Post the problem statement in your team channel or project doc before any design or engineering work begins. Get alignment on the problem before discussing solutions.
The Template
Part 1: Quick Format (One Sentence)
Use this for Slack messages, ticket descriptions, or fast alignment checks.
[Who] needs a way to [do what] because [why it matters], but today they [current workaround or blocker].
Part 2: Standard Format
Use this for most product work: PRDs, sprint planning, discovery kickoffs.
Who is affected?
[Specific user segment: role, company size, industry, usage pattern]
What is the problem?
[Observable behavior or outcome that is broken. Be concrete. What can you see or measure?]
When does it occur?
[Specific trigger, workflow step, or time-based pattern]
What is the current workaround?
[How do users handle this today? What tools, hacks, or manual processes do they use?]
What is the cost of the problem?
[Quantified impact: time lost, revenue lost, error rate, churn risk, support tickets]
Why does it matter now?
[Why should the team prioritize this problem over others? Business context, market timing, strategic alignment]
How will we know it is solved?
[Specific metric and target. What changes when the problem no longer exists?]
Part 3: Deep Format
Use this for complex, cross-functional, or high-stakes problems that require full organizational alignment.
Problem title: [Short, descriptive name]
Problem owner: [Name and role of the person accountable for solving this]
Date written: [YYYY-MM-DD]
Evidence base:
| Source | Finding | Date |
|---|---|---|
| [Customer interview #12] | [Key quote or observation] | [date] |
| [Support ticket analysis] | [Pattern: X tickets/month about this] | [date] |
| [Usage analytics] | [Drop-off rate at step Y: Z%] | [date] |
| [Churn survey responses] | [N% cited this as reason for leaving] | [date] |
Affected segment:
[Detailed description: role, company size, industry, usage frequency, lifecycle stage, geography]
Problem description:
[2-3 sentences. What is happening? What should be happening instead? What is the gap?]
Root cause analysis:
- ☐ User education gap: Users do not know the feature exists or how to use it
- ☐ UX friction: Users know what to do but the interface makes it hard
- ☐ Missing capability: The product does not support this workflow at all
- ☐ Performance issue: The feature exists but is too slow or unreliable
- ☐ Integration gap: The product does not connect to tools users depend on
- ☐ Pricing barrier: Users need the feature but it is behind a plan they cannot afford
Current workarounds:
[What do users do today? How much time/money does it cost them?]
Impact quantification:
| Metric | Current State | Cost |
|---|---|---|
| Time lost per user per week | [hours] | [hourly rate x hours = $] |
| Support tickets per month | [count] | [cost per ticket x count = $] |
| Churn attributable to this problem | [%] | [ARR at risk = $] |
| Opportunity cost (deals lost) | [count] | [avg deal size x count = $] |
Success criteria:
[Metric + target + timeframe. e.g., "Reduce drop-off at onboarding step 3 from 42% to 20% within 60 days of launch."]
What this problem is NOT:
[Explicitly state what is out of scope. This prevents scope creep during solutioning.]
Stakeholder alignment:
| Stakeholder | Perspective | Aligned? |
|---|---|---|
| [Engineering lead] | [Their view of the problem] | [Yes/No] |
| [Design lead] | [Their view] | [Yes/No] |
| [Sales/CS lead] | [Their view] | [Yes/No] |
| [Exec sponsor] | [Their view] | [Yes/No] |
Part 4: Problem Statement Quality Rubric
Rate your problem statement on each dimension (1-5).
| Dimension | 1 (Weak) | 3 (Acceptable) | 5 (Strong) | Score |
|---|---|---|---|---|
| Specificity | Vague audience ("users") | Named segment | Named segment + size + behavior | [/5] |
| Evidence | No customer evidence | Anecdotal (1-2 sources) | Multi-source pattern (5+ data points) | [/5] |
| Measurability | No success metric | Directional metric ("improve X") | Specific metric + target + timeframe | [/5] |
| Scope | Too broad (boil-the-ocean) | Reasonable scope | Focused, achievable in one quarter | [/5] |
| Customer language | Internal jargon | Mix of internal and customer language | Written in the customer's own words | [/5] |
| Total | [/25] |
Interpretation:
- 20-25: Ready for solutioning. Share with the team.
- 15-19: Close but needs more specificity or evidence. Fill in the gaps.
- Below 15: Not ready. Go back to customer interviews or data analysis.
Filled Example: Analytics Dashboard for Marketing Managers
Quick Format
Marketing managers at mid-market SaaS companies (50-500 employees) need a way to see campaign ROI across all channels in one view because delayed budget reallocation costs them 10-15% of quarterly ad spend, but today they manually compile data from Google Analytics, HubSpot, and LinkedIn Ads into a spreadsheet every Monday morning.
Standard Format
Who is affected?
Marketing managers at B2B SaaS companies with 50-500 employees who run paid campaigns across 3+ channels (Google, LinkedIn, Meta, email).
What is the problem?
These managers cannot see cross-channel campaign ROI in real time. They spend 3-4 hours every Monday compiling data from 4 separate tools into a Google Sheet to make budget allocation decisions for the week.
When does it occur?
Every Monday morning (weekly reporting cycle) and at month-end (budget reallocation windows). The pain intensifies during high-spend periods (product launches, end of quarter).
What is the current workaround?
Manual spreadsheet compilation. One marketing manager described a 47-tab Google Sheet maintained by a marketing coordinator. Three of 8 interviewees have tried Databox or Supermetrics but found them too expensive for mid-market budgets ($200-400/month) with limited customization.
What is the cost of the problem?
3-4 hours/week per marketing manager ($75/hr avg = $300/week = $15,600/year). Budget decisions delayed by 2-3 days. Estimated 10-15% of quarterly ad spend wasted on underperforming channels due to slow reallocation.
Why does it matter now?
Marketing budgets are tightening in 2026. CFOs are demanding faster proof of ROI. Our product already ingests data from these marketing platforms via API. Adding a cross-channel view builds on existing infrastructure.
How will we know it is solved?
Time-to-insight drops from 3-4 hours to under 15 minutes. Marketing managers report making budget reallocation decisions within the same day instead of 2-3 days later. Target: 60% adoption among existing marketing manager segment within 90 days.
Key Takeaways
- A problem statement defines what to solve. A solution defines how to solve it. Never mix the two in the same document
- Every field you cannot fill in is a gap in your understanding. Blank fields are signals to do more research, not fields to skip
- Use the customer's words, not internal jargon. "47-tab spreadsheet" is more persuasive than "suboptimal data aggregation workflow"
- The quality rubric keeps you honest. Score your statement before sharing it. If it scores below 15, invest in more discovery
- A good problem statement saves weeks of wasted engineering by preventing the team from building the wrong thing
About This Template
Created by: Tim Adair
Last Updated: 3/5/2026
Version: 1.0.0
License: Free for personal and commercial use