How to Analyze User Interviews with AI Without Losing the Insight

Why "summarize these interviews" is the wrong prompt

Summarization is a compression task, and compression is lossy by design. Ask any model to summarize six hours of user conversations and it will do exactly what you asked: compress. The problem is what gets thrown away in the process — the one interviewee who described a workaround so specific it reads like a feature spec, the hesitation before an answer, the thing three of eight users said unprompted versus the thing you had to ask about directly.

None of that survives a generic "what were the main themes?" prompt. It survives an agent that knows what you're trying to find out before it starts reading. That's the entire difference between interview analysis that produces decisions and interview analysis that produces a word cloud with better formatting.

A summary answers "what did people say?" A synthesis answers "what does this mean for the bet I'm making?" You need the second one, and it requires the agent to know the bet first.

Step 0 — Write your hypotheses down before you read a single transcript

This is the step that makes everything downstream work, and it's also the step most PMs skip because talking to users feels more productive than writing a sentence first. Resist that. Before your interviews even happen, write a short context/hypotheses.md file with the specific, falsifiable bets the round is meant to test — not "users want a better dashboard" but something you could actually be wrong about: "Sellers abandon bulk upload because the error messages don't say which row failed, not because the feature is undiscoverable."

If you skip this, an agent (or a human) analyzing the transcripts has nothing to check the evidence against, so it defaults to reporting whatever is loudest — which is usually not the same thing as whatever is true.

Step 1 — Ground the agent in the hypotheses and the product, once

Same principle as every other agentic PM workflow: the agent needs your context in files before it reads a single transcript, not scattered across the prompt each time. In your Claude Code workspace, keep (or create with an interview-style setup, as described in our non-engineer's guide to Claude Code):

• context/hypotheses.md — the specific, falsifiable bets this research round is testing
• context/product.md — what exists today, so the agent doesn't flag known limitations as new discoveries
• context/users.md — your segments, so it can tag which insights came from which type of user

This is the same discipline behind why generic prompt packs plateau fast: a prompt with no persistent context re-explains your world from scratch every time, and re-explaining is where nuance gets rounded off.

Step 2 — Feed it raw notes, not your own summary

Paste transcripts, not your recap of them. The moment you summarize before the agent sees the material, you've already done the lossy compression yourself — there's nothing left for the agent to extract. Raw notes, awkward phrasing and all, are the actual data.

Here's a starting prompt. It encodes the two rules that keep this from turning into another word cloud:

Read context/hypotheses.md, context/product.md and context/users.md first.

I'm pasting raw notes from 6 user interviews below. For each interview:
1. Pull direct quotes tied to pain points, workarounds, and desired
   outcomes — quote, don't paraphrase.
2. Tag each insight with the hypothesis it supports, contradicts, or
   is unrelated to.
3. Do NOT round a single data point into a confident finding. If 1 of
   6 users said something, write "1 of 6," not "users said."

Then synthesize across all 6:
- Which hypotheses gained evidence, which lost it, which are still untested
- 3 patterns that showed up in at least half the interviews, with the
  supporting quotes
- The most interesting outlier — something one person said that
  contradicts the group, and why it might matter anyway
- The single riskiest assumption I should test next

Interviews:
[paste transcripts or notes]

The instruction to preserve minority signal (rule 3, plus the outlier ask) is doing the real work here. Most synthesis prompts implicitly optimize for consensus. The insight that changes your roadmap is disproportionately likely to be the thing one sharp user said that the other five didn't think to mention — this is the toolkit's /interview-analysis command in miniature, and it's built specifically to resist that consensus pull.

What good output looks like in practice: not "users find the export flow confusing," but something you can act on directly — "Hypothesis 2 (sellers abandon bulk upload over unclear errors) gained evidence: 4 of 6 quoted the row-level error message by name, unprompted. Hypothesis 3 (undiscoverable feature) lost evidence: all 6 found the feature within the first two minutes, so discoverability isn't the blocker their support tickets suggest. Outlier: one seller described exporting to a spreadsheet first as a manual workaround for exactly this — worth a closer look even though it was one voice." That's a paragraph you can bring into a planning meeting and defend, because every clause traces back to a specific interview.

Step 3 — Validate against hypotheses, don't just collect themes

A theme list ("users struggle with onboarding") is comfortable and useless — it confirms what you already suspected without telling you whether to act. Validation against a written hypothesis produces a decision: gained evidence, lost evidence, or genuinely untested. Push the agent to be explicit about which bucket each hypothesis landed in, and to say when the evidence is too thin to conclude anything yet. An agent instructed to ask instead of invent will tell you "3 interviews isn't enough to kill hypothesis 2" rather than manufacturing false confidence either direction.

Batch your interviews in groups of 4-8 rather than dumping thirty transcripts into one pass. Below that range there's no pattern to see yet; above it, even a careful agent starts compressing individual voices into an average — the exact failure this whole approach is designed to avoid. Run synthesis per batch, then a second pass that synthesizes the syntheses, checking whether the pattern held across rounds or was one loud batch.

Step 4 — Turn synthesis into next steps, not just a document

Interview analysis that ends as a static findings doc is where a lot of good research goes to die quietly in a drive folder. The synthesized opportunities — the specific, evidenced gaps between what users need and what exists today — are the raw material for an Opportunity Solution Tree mapped against your outcome, and from there into an initiative or straight into a PRD if the evidence is strong enough to commit. Each step reads the previous artifact instead of starting over, which is the actual point of working agentically rather than just using AI to type faster.

Common mistakes to avoid

• Summarizing before you paste. If you've already distilled the transcript into three bullet points, you've done the lossy compression yourself. Give the agent the raw material.
• No hypotheses to check against. Without a written bet, "synthesis" degrades into "themes," and themes don't tell you what to build.
• Dumping everything into one pass. Thirty transcripts at once average out the exact minority signal you're trying to catch. Batch it.
• Treating consensus as truth and outliers as noise. The user who described a workaround nobody else mentioned is often more valuable than the five who agreed on something vague.
• Skipping the "how confident is this" check. Three interviews is not proof. Ask the agent to flag when a finding is thin, and believe it.

FAQ