User Interviews

User Interview Synthesis

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

Before synthesizing

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

Workflow

1. 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.
2. Second pass — cluster into themes. A theme needs evidence from ≥2 participants. Singletons go to an "Outliers worth watching" section, never promoted to themes.
3. 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

1. 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").
2. 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.

Source & license

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

• Author: ramanbamba
• Source: ramanbamba/10x-pm
• License: MIT

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