Purpose
Turn a messy pile of raw user feedback into a structured, decision-ready insight report — clustered by theme, scored by frequency and severity, backed by verbatim quotes, and ranked into product opportunities — so the team acts on what users actually mean instead of the loudest anecdote.
When to Use
Invoke this skill when the user asks to:
- Synthesize a batch of user interview transcripts or notes into themes
- Make sense of app store reviews or a pile of support tickets
- Find patterns across open-ended survey responses
- Turn customer feedback into a prioritized list of product opportunities
- Prepare a research readout or insight report for a product review
- Identify the top pain points and unmet needs from qualitative data
Inputs Required
Before starting, collect:
- Feedback source: What type of data — interviews, app store reviews, support tickets, survey open-ends, sales call notes (specify each type if mixed)
- Raw feedback: The actual text — transcripts, review dumps, ticket exports, or pasted notes
- Product area: What part of the product or which flow this feedback concerns
- Research question: What decision or question this synthesis is meant to inform
- User segments (if known): Any labels attached to feedback — new vs. power user, plan tier, platform
- Volume context: Roughly how many pieces of feedback are represented (for frequency framing)
If segment labels are missing, synthesize across the full set and flag where segment differences likely matter. If the research question is missing, infer the most useful decision the data can inform and state the assumption.
Instructions
Step 1: Ingest and Normalize
Read every piece of feedback and normalize it into discrete observations.
- Break multi-point feedback into separate atomic observations (one complaint, request, or reaction each)
- Tag each observation as: Pain (something broke or frustrated), Desire (a want or feature request), Praise (what's working), or Confusion (misunderstanding or expectation mismatch)
- Preserve the user's original wording for later quote selection — do not paraphrase away the signal
- Note the source type and any segment label per observation
Step 2: Cluster Into Themes
Group observations into themes by underlying need, not surface wording.
- A theme is a shared user problem or motivation — "I can't tell if my changes saved" is the same theme whether phrased as a bug, a fear, or a feature request
- Aim for 5–9 themes; if you exceed 12, you're clustering by feature instead of by need — merge up
- Name each theme as a user-voiced statement or clear problem phrase (e.g., "I lose work when the app crashes"), not a category label ("Reliability")
- Watch for the distinction between stated requests and underlying needs — a request for "more export formats" often masks a need to "get my data into the tool I actually use"
Step 3: Score Each Theme
Apply two scores per theme:
- Frequency: How many distinct users/observations raised it — report as a count and a rough share of the set (High / Medium / Low based on ~top third / middle / bottom)
- Severity: Impact on the user when it occurs — Critical (blocks core task or drives churn), Major (significant friction, workaround exists), Minor (annoyance, low stakes)
- Flag any theme where low frequency + critical severity appears — rare but severe issues (data loss, security fear, trust breaks) get elevated regardless of count
- Note segment concentration if a theme skews heavily to one user type
Step 4: Frame Themes as Jobs and Needs
For each theme, translate into product-usable framing:
- Job-to-be-done: "When [situation], I want to [motivation], so I can [outcome]"
- Unmet need: The gap between what users are trying to do and what the product currently supports
- Root vs. symptom: State whether the feedback describes a symptom (surface complaint) and what the likely root cause is
Step 5: Select Representative Quotes
For each theme, pull 1–3 verbatim quotes that best capture it.
- Choose quotes that carry emotion or specificity over generic ones ("I gave up and used a spreadsheet" beats "it's not great")
- Attribute by segment/source where known (e.g., power user, support ticket)
- Never invent or embellish quotes — use only wording present in the source material
Step 6: Rank Product Opportunities
Convert themes into a ranked opportunity list.
- Rank primarily by frequency × severity, then elevate any critical-severity outliers
- For each opportunity, state: the theme it resolves, the user job it serves, and a one-line hypothesis of what to build or investigate
- Distinguish quick wins (low effort signals in the feedback) from strategic bets (recurring deep needs)
- Explicitly list what the data does NOT tell you — open questions that need quantitative validation or a follow-up study
Output Format
- Structure: Executive summary → theme table → per-theme detail → ranked opportunities → open questions
- Length: 900–1,400 words depending on volume of input
- Format: Structured report — a scannable theme table plus per-theme detail blocks and a ranked opportunity list
- Sections: 1. Executive Summary (3–5 sentences: top signal, biggest surprise, clearest opportunity) 2. Theme Overview Table (columns: Theme | Frequency | Severity | Segment skew) 3. Theme Detail (per theme: JTBD framing, unmet need, root vs. symptom, 1–3 quotes) 4. Ranked Product Opportunities (numbered, each with theme resolved, user job, build/investigate hypothesis, quick win vs. strategic bet) 5. What the Data Doesn't Tell Us (open questions and validation gaps)
- Tone: Researcher's voice — precise, evidence-anchored, non-hyperbolic; states confidence honestly and never overclaims from thin data
Quality Checklist
Before delivering output, verify:
- [ ] Every theme has both a frequency count and a severity rating
- [ ] Themes are named as user problems/needs, not feature or category labels
- [ ] Every quote is verbatim from the source material — none invented or paraphrased into a quote
- [ ] At least one low-frequency-but-critical theme is checked for and surfaced if present
- [ ] Ranked opportunities are ordered by frequency × severity with critical outliers justified
- [ ] The "What the Data Doesn't Tell Us" section names specific validation gaps, not a generic disclaimer
Notes
- The most common synthesis error is clustering by feature area instead of by user need — a "search" theme and a "filters" theme are often the same underlying job ("I can't find my stuff quickly")
- Frequency alone is a trap: the loudest complaint isn't always the most important. Severity and the low-frequency/high-severity check exist to catch trust-breaking issues that few users mention but that quietly drive churn
- Distinguish requests from needs relentlessly — users describe solutions ("add a dark mode toggle") when the report should capture the need ("the app is hard on my eyes at night")
- With small samples (under ~8 interviews), treat frequency as directional, not statistical, and lean harder on the open-questions section
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