Problem Statement (User-Centered)
Write an empathy-driven problem statement (I am / Trying to / But / Because / Which makes me feel) that frames product work around user outcomes — not feature requests or business symptoms.
Your problem statement is "users need a better dashboard." That's a feature wishlist. A real problem statement names a person, what they're trying to accomplish, what's blocking them, why, and how it feels — and produces a one-sentence summary that makes stakeholders nod. "Users want efficiency" doesn't ship. "Sarah spends 8 hours/month manually chasing invoices" does.
Who it's for: PMs framing discovery, founders aligning teams on real problems, UX leads avoiding solution-first thinking, engineering leaders needing user context
Example
"Frame a problem statement for our 60% onboarding drop-off" → I am a non-technical SMB owner / Trying to start using the product / But the dashboard is empty and jargon-heavy / Because there's no guided flow / Which makes me feel overwhelmed and abandon → "SMB owners need a guided first session because empty dashboards cause 60% to abandon within 24 hours."
New here? 3-minute setup guide → | Already set up? Copy the template below.
# Problem Statement
Write a user-centered problem statement using the empathy-driven framework: who is blocked, what they're trying to do, why it matters, and how it feels. A human-centered narrative that ensures you're solving a problem worth solving.
Not a requirements doc. Not a solution in disguise.
## The Framework
```markdown
**I am:** [persona experiencing the problem]
**Trying to:** [desired outcomes the persona cares about]
**But:** [barriers preventing the outcomes]
**Because:** [root cause]
**Which makes me feel:** [emotional impact]
```
Plus **Context & Constraints** (geographic, tech, time, demographic) and a **Final Problem Statement** (one-sentence empathetic summary).
## Why This Structure Works
- **Persona-centric** — see the problem through user's eyes
- **Outcome-focused** — emphasizes results, not tasks
- **Root cause** — pushes past symptoms
- **Emotional validation** — humanizes the problem
- **Contextual** — acknowledges real-world constraints
**Anti-patterns:** Not a solution in disguise ("we lack AI analytics"). Not a business problem ("revenue down"). Not a feature request ("users need a dashboard"). Not generic ("better UX").
## When to Use
**Use:** Discovery kickoff, stakeholder alignment, socializing problems with eng/design/exec, pitching why a problem matters.
**Don't use:** Before any user research (interview first), internal operational problems, as PRD substitute.
## Application
### Step 1: Gather User Context
- User interviews/research (quotes, behaviors, pains)
- JTBD insights (`jobs-to-be-done`)
- Persona clarity (`proto-persona`)
- Constraints data
If missing: run discovery. Don't fabricate.
### Step 2: Draft the Problem Framing Narrative
```markdown
**I am:** [Persona, 3-4 key characteristics]
- [Pain/characteristic 1]
- [Pain/characteristic 2]
- [Pain/characteristic 3]
**Trying to:**
- [Desired outcomes the persona cares most about]
**But:**
- [Barrier 1]
- [Barrier 2]
- [Barrier 3]
**Because:**
- [Root cause, empathetically described]
**Which makes me feel:**
- [Real emotions from research]
```
**Quality checks:** Specific persona, outcome-focused "trying to," real barriers, root cause (not symptom), authentic emotions.
### Step 3: Document Context & Constraints
```markdown
## Context & Constraints
- [Geographic / tech / time / demographic factor]
- [e.g., "Must work offline in rural areas"]
- [e.g., "Used by non-technical users"]
- [e.g., "Decisions must be made within 24 hours"]
```
### Step 4: Craft the Final Problem Statement
Formula: `[Persona] needs a way to [desired outcome] because [root cause], which currently [emotional/practical impact].`
**Example:** "Enterprise IT admins need a way to provision user accounts in under 5 minutes because current processes take 2+ hours with manual approvals, which causes project delays and frustrated end-users."
**Quality:** One sentence, measurable, empathetic, shareable.
### Step 5: Validate & Socialize
- Read aloud to people who experience it. Do they say "Yes, exactly!"?
- Share with product/eng/design/exec
- Iterate if anyone says "that's not the real problem"
## Mini Example
```markdown
**I am:** A software developer on a distributed team
**Trying to:** Communicate in real-time without losing context
**But:** Email is too slow and IM is ephemeral
**Because:** No tool combines real-time chat with searchable history
**Which makes me feel:** Frustrated and disconnected
```
## Common Pitfalls
1. **Solution smuggling** ("we don't have feature X") → reframe around outcome
2. **Business problem disguised** ("users want to increase our revenue") → user perspective
3. **Generic personas** ("busy professional") → specific role + behavior
4. **Symptom instead of root cause** ("UI is confusing") → keep asking why
5. **Fabricated emotions** ("makes me feel empowered") → use real interview quotes
## References
- `jobs-to-be-done` — informs "Trying to" and "But"
- `proto-persona` — defines "I am"
- `positioning-statement` — problem informs positioning
- `user-story` — guides story prioritization
**External:** Christensen *Jobs to Be Done*, Osterwalder *Value Proposition Canvas*, Dave Gray *Empathy Mapping*.
What This Does
Walks through the I am / Trying to / But / Because / Which makes me feel framework with quality checks at each box — plus context/constraints and a one-sentence synthesis. Forces user-centered framing instead of feature requests or business-metric problems disguised as user problems.
Pairs with proto-persona (defines "I am"), jobs-to-be-done (informs "Trying to"/"But"), and feeds into positioning-statement, user-story, PRDs.
Quick Start
mkdir -p ~/Documents/ProblemStatement
mv ~/Downloads/CLAUDE.md ~/Documents/ProblemStatement/
cd ~/Documents/ProblemStatement
claude
Provide user research (quotes, behaviors, pains), persona context, and constraints. Claude drafts the narrative and stress-tests for solution smuggling, vague personas, and fabricated emotions.
The Five Boxes
| Box | Purpose |
|---|---|
| I am | Specific persona (not "busy professionals") |
| Trying to | Desired outcome (not a task) |
| But | Real barriers (not inconveniences) |
| Because | Root cause (not a symptom) |
| Which makes me feel | Real emotions from research (not marketing copy) |
Plus Context & Constraints and a Final Problem Statement in one sentence.
Tips & Best Practices
- Specific personas only. "Sales rep managing 50+ leads in spreadsheets" beats "busy professional."
- "Trying to" = outcome, not task. "Make data-driven decisions faster" beats "use the dashboard."
- Keep asking "why" until you hit root cause. "UI is confusing" is a symptom.
- Real emotions only. Use actual interview quotes — "frustrated," "overwhelmed," "stuck" — not "delighted" or "empowered."
- One-sentence synthesis must pass the meeting test: stakeholders nod, don't ask clarifying questions.
Common Pitfalls
- "The problem is we lack feature X" (solution smuggling)
- "Our churn rate is too high" (business problem, not user problem)
- "Busy professionals want better tools" (generic persona, vague pain)
- "Because the UI is confusing" (symptom, not root cause)
- "Makes me feel empowered" (fake emotion, marketing copy)