Home
cd ../playbooks
Product ManagementBeginner

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.

30 minutes
By communitySource
#problem-statement#discovery#empathy#framing#jtbd

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."

CLAUDE.md Template

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*.
README.md

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)

$Related Playbooks