Problem Framing

Purpose

Produce a Problem Definition Document — a structured artifact that decomposes a vague or assumed problem into an evidence-graded problem statement with identified stakeholders, quantified opportunity size, mapped constraints, and prioritized sub-problems. This is the upstream skill that feeds every downstream PM activity: Discovery, Competitive Analysis, Spec Writing, and Metric Design. The output is not a brief or a pitch — it is a rigorous decomposition that forces the question "What exactly are we solving and for whom?" to be answered with evidence, not assumption.

When to Use / When NOT to Use

Use this skill when:

• A stakeholder says "we should build X" and you need to determine whether X solves a real problem
• You have a vague problem area ("user retention is bad") that needs decomposition into solvable sub-problems
• Multiple teams disagree on what the real problem is — you need a shared, evidence-graded definition
• You are starting a new product initiative and need to define the problem space before Discovery or Competitive Analysis
• A feature request arrives disguised as a problem statement and you need to peel back to the actual user pain
• You need to prioritize across multiple candidate problems with limited resources
• An existing product is underperforming and nobody agrees on why

Do NOT use this skill when:

• The problem is already well-defined and validated — you need a spec, not more framing (use Spec Writing)
• You need to understand the competitive landscape (use Competitive & Market Analysis — that skill consumes this one's output)
• You need to design metrics for an already-defined feature (use Metric Design & Experimentation)
• You need to run user research — this skill identifies what research to do, not how to do it (use Discovery & Research)
• The "problem" is a technical bug with a known root cause (use your bug tracker)

Anti-inputs (what this skill does NOT handle):

• Solution design or feature specification (-> Spec Writing skill)
• User research methodology and interview design (-> Discovery & Research skill)
• Competitive positioning (-> Competitive & Market Analysis skill)
• Metric hierarchy and experiment design (-> Metric Design & Experimentation skill)
• Organizational change management (this is product problem framing, not org design)

---

Format Rules

These rules govern every output produced by this codex. They are quality enforcement mechanisms derived from benchmarking against investment-grade problem definitions. They are mandatory, not optional.

Rule 1: Take Positions with Calibrated Confidence

Never use weasel words in conclusions. Replace "likely," "may," "could," "seems" with explicit confidence levels:

• H (>70%) — Strong evidence supports this conclusion. Act on it.
• M (40-70%) — Direction is probable but evidence is mixed. Validate before committing resources.
• **L (I->R->C->W Cascade Applies to All Recommendations

Every problem framing recommendation or intervention follows:

OBSERVATION [evidence tier] -> IMPLICATION [mechanism] -> RESPONSE [specific action + owner] -> CONFIDENCE [H/M/L + key assumption] -> WATCH INDICATOR [observable signal]

Why: The most common problem framing failure is disconnected findings — "users struggle with onboarding" without specifying the mechanism, the recommended investigation, or the observable signal that confirms the problem is real and worth solving.

Rule 4: Framework Selection Before Application (Step 0)

Different problem types require different framework subsets. Always apply the Step 0b routing table before selecting which of the 8 frameworks to use.

Why: Applying all 8 frameworks to every problem inflates output 2-3x without improving decision quality. A prioritization question does not need 5 Whys root cause analysis; a root cause investigation does not need opportunity sizing.

Rule 5: Surface Contradictions Between Frameworks

When the Problem Definition Canvas and 5 Whys reach different conclusions about the root problem, or when Opportunity Sizing suggests high value but Problem-Solution Fit Assessment says the problem is not painful enough, surface the contradiction explicitly. Do not resolve artificially.

Why: Contradictions are the most valuable signals. A problem that scores high on opportunity size but low on validated severity is a hypothesis, not a finding — and that distinction changes the next action entirely.

Rule 6: Staleness Flags

Any claim based on data older than 6 months must carry [POTENTIALLY STALE -- verify before presenting].

Why: Problem landscapes shift. A pain point validated 12 months ago may have been solved by a competitor, a workaround, or a market shift. Tier labels alone are insufficient; recency matters independently of source quality.

Rule 7: Evidence-Limited Flags

If a key problem framing conclusion rests only on Tier 4-6 evidence, prepend it with [EVIDENCE-LIMITED: validate with Tier 1-2 before acting].

Why: A problem statement built entirely on stakeholder assertions (T5) and inference (T6) is a hypothesis document. Treating it as a validated problem definition is the single most expensive upstream mistake in product development.

Rule 8: Framework References Get One-Line Context

Not "Jobs-to-be-Done analysis" but "Christensen's framework for understanding why customers 'hire' products — we use it here to identify what functional, emotional, and social jobs the user is trying to accomplish, which reveals the real problem underneath the stated feature request." The reader needs to understand why a framework matters for their decision.

Rule 9: The Document Must Be Navigable by Non-Creators

Include a reading guide (by time and by role), a notation key, and layered depth. A VP should be able to read only the Executive Summary and understand the problem. A PM should be able to read through Findings and skip Deep Analysis. The full document is for the analyst or researcher who will design the next investigation. No reader should encounter unexplained notation.

---

Output Template (Mandatory Document Skeleton)

Every Problem Definition Document MUST follow this exact structure. Copy this skeleton and fill it in. Do not reorder sections, skip sections, or invent new top-level sections. If a framework was skipped in Step 0b, note "Skipped -- not load-bearing for this question type" in that section.

# Problem Definition Document: [Subject -- e.g., "Enterprise Onboarding Drop-Off"]

> **Date:** [YYYY-MM-DD] | **Confidence band:** [Overall H/M/L] | **Staleness window:** [Date after which key claims need revalidation]

---

## Executive Summary

[5 sentences max. A VP reads only this and understands: what the problem is, who has it, how big it is, why it matters now, and what the recommended next step is. No framework names, no jargon, no evidence tier tags. Plain language a non-PM exec can act on. Final sentence = the recommended next action in bold.]

---

## How to Read This Document

**What this is:** A problem definition -- not a solution proposal, not a spec, not a brief. It answers "What exactly are we solving and for whom?" with evidence-graded confidence. It is the upstream artifact that feeds Discovery, Competitive Analysis, and Spec Writing.

**Reading by time available:**

| Time | Read | You'll get |
|---|---|---|
| **5 min** | Executive Summary only | The problem, who has it, how big it is, and the recommended next step |
| **15 min** | Executive Summary + Problem Statement + Opportunity Sizing | The structured problem definition with quantified impact |
| **30 min** | Full document through Recommendations | Complete problem decomposition with constraints, stakeholders, and prioritization |
| **Deep dive** | Everything including Appendix | Full framework applications, assumptions, adversarial self-critique |

**Reading by role:**

| Role | Start with | Then read | Skip unless curious |
|---|---|---|---|
| VP / Exec | Executive Summary | Opportunity Sizing (section 5), Recommendations (section 10) | Framework sections, deep root cause analysis |
| PM Lead | Executive Summary | Problem Statement (section 2), Constraint Map (section 7), Prioritization (section 9) | Individual framework deep dives |
| Researcher / Designer | Full document in order | Root Cause (section 3), JTBD Framing (section 4), Stakeholder Matrix (section 8) | Opportunity Sizing financial details |
| Engineer | Executive Summary | Constraint Map (section 7), Problem Statement (section 2) | Stakeholder analysis, prioritization methodology |

---

## Notation Key

**Confidence levels** -- applied to every problem framing conclusion:
- **H (>70% confident)** -- Strong evidence supports this conclusion. Act on it.
- **M (40-70%)** -- Direction is probable but evidence is mixed. Validate before committing resources.
- **L (I->R->C->W):
- **O**bservation -- What we see (with evidence tier)
- **I**mplication -- Why it matters (the mechanism)
- **R**esponse -- What to do (specific action + owner + timeline)
- **C**onfidence -- How sure we are (H/M/L + key assumption)
- **W**atch -- How to know if we're wrong (observable signal)

**Flags:**
- `[POTENTIALLY STALE]` -- Source data is >6 months old; verify before presenting
- `[EVIDENCE-LIMITED]` -- Conclusion rests on T4-T6 evidence only; validate with stronger data before acting

---

## Step 0: Context Fitness Check

Before selecting frameworks, verify that a Problem Definition Document is the right artifact.

| Question | If Yes | If No |
|---|---|---|
| **Is the problem space genuinely unclear or contested?** | Proceed to Problem Framing. This is exactly when you need it. | If the problem is already well-defined and validated, skip to Spec Writing or Discovery. A Problem Definition Document for an already-validated problem is overhead. |
| **Do you have access to user behavioral data (T1) or primary research (T2)?** | Problem definition can produce H-confidence conclusions. | Flag prominently: "This problem definition is built from stakeholder input and inference (T5-T6). All problem statements are hypotheses -- validate with user research before committing to solutions." Cap confidence at M for problem severity claims. |
| **Is the requester asking for a problem definition or already asking for a solution?** | Proceed normally. | The requester may need to be redirected. A Problem Definition Document that arrives when the team expects a feature spec will frustrate. Clarify the purpose: "This document defines WHAT to solve. The next step is HOW." |
| **Are multiple stakeholders involved with potentially different views of the problem?** | Stakeholder Impact Matrix (F7) is load-bearing. Apply it. | If single stakeholder, Stakeholder Impact Matrix can be simplified or skipped. |
| **Is there time pressure to ship something immediately?** | Produce a Quick Version (10-step) problem definition; flag gaps for later validation. | Full Version with all applicable frameworks. |

**If the core answer is "the problem is already clear":** State this prominently. Recommend the appropriate downstream skill instead. A Problem Definition Document for a validated problem is waste.

---

## Step 0b: Framework Selection

| Question type | Primary frameworks (apply in full) | Supporting frameworks (scan only) | Skipped (why) |
|---|---|---|---|
| [e.g., "Decompose a vague problem"] | [e.g., F1 Problem Definition Canvas, F2 5 Whys, F3 JTBD Problem Framing] | [e.g., F5 Problem-Solution Fit, F7 Stakeholder Matrix] | [e.g., "F8 ICE/RICE -- single problem, no prioritization needed"] |

**Framework Selection Routing Table:**

| Question Type | Prompt Signals | Primary Frameworks | Frameworks to Skip |
|---|---|---|---|
| **Decompose a vague problem** | "what's the real problem", "users are struggling", "something is broken" | F1 Problem Definition Canvas, F2 5 Whys, F3 JTBD Problem Framing | F4 Opportunity Sizing (premature), F8 ICE/RICE (single problem) |
| **Quantify a known problem** | "how big is this", "should we invest", "is this worth solving" | F4 Opportunity Sizing, F5 Problem-Solution Fit, F7 Stakeholder Impact | F2 5 Whys (root cause already known), F6 Constraint Mapping (premature) |
| **Prioritize across problems** | "which problem first", "where to focus", "rank these" | F4 Opportunity Sizing, F8 ICE/RICE Prioritization, F5 Problem-Solution Fit | F2 5 Whys (apply per-problem, not across set), F6 Constraint Mapping (apply after selection) |
| **Root cause investigation** | "why is this happening", "symptoms vs. cause", "keeps recurring" | F2 5 Whys, F1 Problem Definition Canvas, F6 Constraint Mapping | F4 Opportunity Sizing (premature), F8 ICE/RICE (single problem) |
| **Stakeholder alignment** | "everyone disagrees", "leadership wants X but users need Y", "political" | F7 Stakeholder Impact Matrix, F1 Problem Definition Canvas, F3 JTBD | F8 ICE/RICE (not a prioritization problem), F4 Opportunity Sizing (secondary) |
| **Constraint discovery** | "what can we actually do", "regulatory limits", "tech debt", "timeline" | F6 Constraint Mapping, F1 Problem Definition Canvas, F5 Problem-Solution Fit | F2 5 Whys (not a root cause problem), F8 ICE/RICE (not a prioritization problem) |
| **Full problem definition** | "define the problem space", "new initiative", "starting from scratch" | All -- tier explicitly: 4 primary, rest supporting | None -- but label tiers and apply primary frameworks at full depth, supporting at scan depth |

---

## 1. Problem Statement

**One-sentence problem statement:** [Who] experiences [what pain] when [trigger/context], resulting in [measurable consequence].

**Confidence:** [H/M/L] | **Evidence basis:** [T1/T2/.../T6]

**Problem type:** [New problem / Existing problem worsening / Existing problem newly visible / Assumed problem needing validation]

---

## 2. Problem Definition Canvas

| Dimension | Finding | Evidence | Confidence |
|---|---|---|---|
| **Who has this problem?** | [Specific user segment, not "users"] | (TX: source) | H/M/L |
| **What are they trying to do?** | [The goal, not the feature they want] | (TX: source) | H/M/L |
| **What do they do today?** | [Current behavior including workarounds] | (TX: source) | H/M/L |
| **Why is that painful?** | [Specific friction, cost, risk, or failure] | (TX: source) | H/M/L |
| **What triggers the pain?** | [The moment or context where pain is acute] | (TX: source) | H/M/L |
| **What does "good" look like?** | [Desired end state in the user's words] | (TX: source) | H/M/L |
| **How do they know it's solved?** | [Observable success criteria from user perspective] | (TX: source) | H/M/L |

---

## 3. Root Cause Analysis

**Presented problem:** [What the stakeholder or user SAID the problem is]
**Root problem:** [What the 5 Whys analysis reveals the actual problem is]

| Layer | Why? | Evidence | Tier |
|---|---|---|---|
| Surface symptom | [Presented complaint] | (TX: source) | TX |
| Why 1 | [First layer cause] | | |
| Why 2 | [Deeper cause] | | |
| Why 3 | [Structural cause] | | |
| Why 4 | [System-level cause] | | |
| Why 5 (root) | [Root cause] | | |

**Divergence check:** Does the root cause match the presented problem? If not, flag the gap explicitly. The stakeholder expects you to solve the surface symptom; the analysis says the root is elsewhere. This is a critical communication moment.

---

## 4. JTBD Problem Framing

| Job Dimension | Finding | Evidence | Unmet? |
|---|---|---|---|
| **Functional job** | [What they're trying to accomplish] | (TX) | Over-served / Under-served / Unserved |
| **Emotional job** | [How they want to feel] | (TX) | Over-served / Under-served / Unserved |
| **Social job** | [How they want to be perceived] | (TX) | Over-served / Under-served / Unserved |

**Consumption chain analysis:**

| Phase | Current behavior | Pain points | Opportunity |
|---|---|---|---|
| Before (trigger/discovery) | | | |
| During (active use) | | | |
| Aft

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [Avyayalaya](https://github.com/Avyayalaya)
- **Source:** [Avyayalaya/agent-prime](https://github.com/Avyayalaya/agent-prime)
- **License:** MIT
- **Homepage:** https://avyayalaya.github.io/agent-prime/

Install and usage instructions live in the source repository linked above.