Problem StatementSAFE

Product Management skills framework built on battle-tested methods for Claude Code, Cowork, Codex, and AI agents.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: problem-statement
argument-hint: "[user and their struggle]"
description: Write a user-centered problem statement with who is blocked, what they are trying to do, why it matters, and how it feels. Use when framing discovery, prioritization, or a PRD.
intent: >-
  Articulate a problem from the user's perspective using an empathy-driven framework that captures who they are, what they're trying to do, what's blocking them, why, and how it makes them feel. Use this to align stakeholders on the problem before jumping to solutions, and to frame product work around user outcomes rather than feature requests.
type: component
theme: discovery-research
best_for:
  - "Framing a problem before anyone proposes a solution"
  - "Getting a team to agree on who is blocked and why it matters"
  - "Turning a vague complaint into something a team can act on"
scenarios:
  - "The team keeps jumping to solutions and we've never written down the actual problem"
  - "I need a crisp problem statement for a PRD that a skeptical exec will read"
estimated_time: "10-20 min"
---


## Purpose
Articulate a problem from the user's perspective using an empathy-driven framework that captures who they are, what they're trying to do, what's blocking them, why, and how it makes them feel. Use this to align stakeholders on the problem before jumping to solutions, and to frame product work around user outcomes rather than feature requests.

This is not a requirements doc—it's a human-centered problem narrative that ensures you're solving a problem worth solving.

## Input

**Works best with:** Who the user is and what they're struggling to do.
**Also useful:** What's blocking them, why it matters, how it feels, and supporting evidence.

Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended `ARGUMENTS:` line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.

**Arriving empty-handed? That works too.** The skill asks for the user and their goal first — a problem statement without a specific 'who' is a solution looking for cover.

**Example invocation:** `Problem statement: clinic schedulers double-book exam rooms because the calendar doesn't show equipment availability.`

## Key Concepts

### The Problem Framing Framework
Based on Jobs-to-be-Done and empathy mapping, the framework structures problems as:

**Problem Framing Narrative:**
- **I am:** [Describe the persona experiencing the problem]
- **Trying to:** [Desired outcomes the persona cares about]
- **But:** [Barriers preventing the outcomes]
- **Because:** [Root cause of the problem]
- **Which makes me feel:** [Emotional impact]

**Context & Constraints:**
- [Geographic, technological, time-based, demographic factors]

**Final Problem Statement:**
- [Single, concise, empathetic summary]

### Why This Structure Works
- **Persona-centric:** Forces you to see the problem through the user's eyes
- **Outcome-focused:** "Trying to" emphasizes desired results, not tasks
- **Root cause analysis:** "Because" pushes past symptoms to underlying issues
- **Emotional validation:** "Makes me feel" humanizes the problem and builds empathy
- **Contextual:** Constraints acknowledge real-world limitations

### Anti-Patterns (What This Is NOT)
- **Not a solution in disguise:** "The problem is we lack AI-powered analytics" = sneaking in a solution
- **Not a business problem:** "Our revenue is down" isn't a user problem (it's a symptom)
- **Not a feature request:** "Users need a dashboard" isn't a problem (what are they trying to do?)
- **Not generic:** "Users want better UX" is too vague to be actionable

### When to Use This
- Kicking off discovery or problem validation work
- Aligning stakeholders before solutioning
- Socializing a problem with engineering, design, or exec teams
- When you have feature requests but unclear underlying problems
- Pitching why a problem is worth solving

### When NOT to Use This
- When you haven't done any user research yet (don't guess—interview first)
- For internal operational problems (this is for user-facing problems)
- As a substitute for a PRD (this frames the problem; PRD defines the solution)

---

## Application

Use `template.md` for the full fill-in structure.

### Step 1: Gather User Context
Before drafting, ensure you have:
- **User interviews or research:** Direct quotes, observed behaviors, pain points
- **Jobs-to-be-Done insights:** What users are "hiring" your product to do (reference `skills/jobs-to-be-done/SKILL.md`)
- **Persona clarity:** Who specifically experiences this problem (reference `skills/proto-persona/SKILL.md`)
- **Constraints data:** Geographic, tech, time, demographic limitations

**If missing context:** Run discovery interviews, contextual inquiries, or user shadowing. Don't fabricate problems.

---

### Step 2: Draft the Problem Framing Narrative

Fill in the template from the persona's point of view:

```markdown
## Problem Framing Narrative

**I am:** [Describe the key persona, highlighting 3-4 key characteristics]
- [Key pain point or characteristic 1]
- [Key pain point or characteristic 2]
- [Key pain point or characteristic 3]

**Trying to:**
- [Single sentence listing the desired outcomes the persona cares most about]

**But:**
- [Describe the barriers preventing the persona from achieving outcomes]
- [Job-to-be-done or outcome obstruction 1]
- [Job-to-be-done or outcome obstruction 2]
- [Job-to-be-done or outcome obstruction 3]

**Because:**
- [Describe the root cause empathetically]

**Which makes me feel:**
- [Describe the emotions from the persona's perspective]
```

**Quality checks:**
- **"I am" specificity:** Can you picture this person? Or is it generic ("busy professionals")?
- **"Trying to" clarity:** Is this an outcome (measurable) or a task (activity)?
- **"But" depth:** Are these real barriers or just inconveniences?
- **"Because" honesty:** Is this the root cause or just a symptom?
- **"Makes me feel" au

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.