User interviews

Skill ramanbamba/10x-pm/skills/user-interviews

Prompts don't compound. Skills do. The open-source AI toolkit for product managers — 13 Claude Code skills + 3 red-team agents for the full PM workflow.

Install

npx -y skills add ramanbamba/10x-pm --skill user-interviews

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Synthesize raw user interview notes, call transcripts, or research sessions into themes, evidence, and product implications. Use when the user says "synthesize these interviews", "analyze this transcript", "what did users tell us", "research synthesis", or shares interview notes or call recordings' transcripts.

SKILL.md

3.2 KB, as published. Nobody here has run it

User Interview Synthesis

Turn raw interview material into findings a team can act on — without laundering weak signals into confident claims.

Before synthesizing

Confirm the inputs: how many interviews, what segments, recruited how? (Recruitment bias shapes every finding — 5 power users are not "users".)
Ask what decision this synthesis feeds. Synthesis for "should we build X" reads differently than open discovery.
If transcripts are files, read all of them fully before writing anything. Never synthesize from the first two and pattern-match the rest.

Workflow

First pass — extract observations. For each interview, pull direct quotes and observed facts. Tag each with participant ID. Keep the user's words; do not paraphrase into your framing yet.
Second pass — cluster into themes. A theme needs evidence from ≥2 participants. Singletons go to an "Outliers worth watching" section, never promoted to themes.
Separate the three layers explicitly — this is the core discipline:
- Observation: what participants said or did (quote, ID)
- Interpretation: what it likely means (your inference, labeled as such)
- Implication: what the product team might do about it
Hunt for disconfirming evidence. For each theme, check the transcripts for participants who contradicted it. Report the count both ways ("6 of 8 struggled; 2 did not — both were admins").
Flag surprises. The most valuable output is usually the thing nobody expected. Give it its own section even if the evidence is thin — labeled as thin.

Output format

# Research synthesis — [topic], [date]
**Inputs:** [N] interviews · [segments] · recruited via [method]
**Decision this feeds:** [the decision]

## Top findings
[3–5, one line each, strongest evidence first]

## Themes
### 1. [Theme as a declarative sentence, e.g. "Setup fails at the credentials step"]
**Evidence ([X]/[N] participants):**
> "[quote]" — P3
> "[quote]" — P7

**Counter-evidence:** [who contradicted it and how, or "none found"]
**Interpretation:** [labeled inference]
**Implication:** [what to consider doing]

## Surprises
[Unexpected findings, with honest evidence strength]

## Outliers worth watching
[Single-participant signals; keep for future pattern-matching]

## What this doesn't tell us
[Limits: segment gaps, sample size, recruitment bias, leading questions noticed]

Quality bar — self-check

Every theme cites participant counts and verbatim quotes. "Users want X" with no quote fails.
Observation and interpretation never blend. "Users are frustrated" is an interpretation; "P4 said 'I gave up after the third try'" is an observation.
Counter-evidence was actually searched for, not just omitted.
Sample limits are stated. 5 interviews is a direction, not a proof — say so.
No theme built on one participant.