Purpose
Turn scattered discovery inputs — interview notes, support tickets, usage data, survey results, and competitive observations — into a single defensible problem statement with an evidence ledger, affected-segment sizing, and a clear recommendation on whether the problem is worth solving. Solves the "I have 40 pages of research and no shared understanding" problem before any solution work begins.
When to Use
Invoke this skill when the user asks to:
- Synthesize user interviews, surveys, or support data into a problem statement
- Consolidate discovery findings from multiple sources into one narrative
- Decide whether a problem is worth solving before scoping a solution
- Write a defensible problem definition for a product brief or PRD
- Separate signal from noise across qualitative and quantitative research
- Frame an opportunity for stakeholder or leadership review
Inputs Required
Before starting, collect:
- Problem area: The topic, workflow, or user pain being investigated (1–2 sentences)
- Qualitative inputs: Interview notes, verbatim quotes, support tickets, sales feedback, or session observations
- Quantitative signals: Usage metrics, funnel drop-off, retention data, survey results, or NPS/CSAT verbatims
- Competitive/market inputs: What competitors or alternatives do here, or how users currently work around the gap
- Affected segments: Which user types, personas, or account tiers this may touch
- Business context: The goal or bet this discovery feeds (e.g., activation, expansion, churn reduction)
- Decision needed: What the synthesis must inform (go/no-go, prioritization, roadmap slot)
If quantitative signals are missing, note where evidence is qualitative-only and flag the confidence gap explicitly rather than inventing numbers.
Instructions
Step 1: Triage and Tag the Raw Inputs
Sort every input into three evidence classes and tag each with its reliability:
- Behavioral evidence (what users actually do): usage data, funnel metrics, session recordings — highest reliability
- Attitudinal evidence (what users say): interviews, surveys, tickets, sales notes — medium reliability, subject to recall and framing bias
- Market evidence (what the landscape shows): competitor moves, workarounds, category trends — contextual reliability
For each input, note: source, sample size or frequency, and whether it corroborates or contradicts other inputs. Discard anecdotes with a sample of one unless corroborated by another class.
Step 2: Extract and Cluster Themes
Group findings into 3–6 candidate problem themes. For each theme:
- Name the theme in the user's language, not internal jargon
- Count the supporting evidence points across all three classes (triangulation is the goal — a theme backed by behavioral + attitudinal evidence is far stronger than one backed by quotes alone)
- Flag any theme supported by only one evidence class as "unvalidated — needs confirmation"
Step 3: Diagnose Root Cause vs. Symptom
For the strongest 1–2 themes, run a root-cause pass using the "5 Whys" or Jobs-to-be-Done lens:
- State the observed symptom
- Trace to the underlying job the user is trying to accomplish
- Identify what blocks the job today (the actual problem)
- Distinguish the problem from the current solution's shortcomings — a problem statement must survive a redesign of the solution
Step 4: Size the Affected Population
Estimate scale of the problem, using data where available:
- Breadth: What share of users/accounts experience this? (cite the metric or state the qualitative estimate)
- Frequency: How often does the pain occur — daily, per-session, edge case?
- Severity: What does it cost the user in time, money, risk, or abandonment?
- Business linkage: Connect the problem to a measurable business outcome (retention, activation, expansion, support load)
Step 5: Write the Problem Statement
Produce a structured statement in this format:
- Who: The specific affected segment
- Struggles to: The job or outcome they can't achieve
- Because: The root-cause barrier (not the missing feature)
- Which results in: The observable consequence and its business impact
- We know this because: The triangulated evidence summary
Step 6: Frame the Opportunity and Recommend
- Opportunity framing: State the value at stake if solved and the risk of ignoring it
- Confidence rating: High / Medium / Low — justified by evidence triangulation, not gut feel
- Open questions: 2–4 specific things still unvalidated, with how to close each gap
- Recommendation: Build now / Investigate further / Deprioritize — with one-line rationale. Be decisive.
Output Format
- Structure: Sequential sections following the synthesis flow, with the evidence ledger presented as a table
- Length: 800–1,200 words
- Format: Structured document — prose for the problem statement and recommendation, tables for evidence and sizing, bulleted clusters for themes
- Sections: Evidence Triage → Theme Clusters → Root-Cause Diagnosis → Affected-Population Sizing → Problem Statement → Opportunity & Recommendation
- Tone: Senior product strategist — evidence-first, skeptical of weak signals, willing to recommend "don't build this"
Quality Checklist
Before delivering output, verify:
- [ ] Every theme lists its supporting evidence count and evidence class(es)
- [ ] At least one theme is triangulated across behavioral AND attitudinal evidence, or the confidence gap is explicitly flagged
- [ ] The problem statement describes a barrier, not a missing feature (survives a solution redesign)
- [ ] Affected-population sizing cites real data where provided and marks estimates as estimates
- [ ] Confidence rating is justified by evidence triangulation, not asserted
- [ ] A clear Build / Investigate / Deprioritize recommendation is made without hedging
Notes
- The single most common failure in discovery synthesis is confusing a symptom for a problem — Step 3 exists to catch this. A problem stated as "users want feature X" is almost always a symptom of an unstated job.
- Triangulation beats volume: three corroborating evidence classes at small sample outweigh fifty quotes from one channel.
- When the evidence only supports "investigate further," say so — a rigorous "not yet" is more valuable than a confident guess.
- If two themes contradict each other, surface the contradiction rather than averaging it away; contradictions often reveal segment differences worth splitting.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills