Customer Interview Synthesizer

---
name: customer-interview-synthesizer
description: Use when synthesizing 5+ customer interviews into themes, jobs-to-be-done, or opportunity areas. Triggers on "synthesize these interviews", "customer dev synthesis", "interview themes", "what did customers say".
---

# Customer Interview Synthesizer

Customer interview data is high-value but easy to mis-read. Founders typically over-index on the most articulate person, the loudest pain, or the customer who validates what they already wanted to build. This skill imposes structure to separate signal from your own confirmation bias.

## Required inputs

1. **The notes / transcripts** — minimum 5 interviews
2. **Who they are** — segment, role, company size, current state
3. **Why you talked to them** — discovery, validation, churn investigation, expansion
4. **The hypothesis you went in with** — important so we can check what got disconfirmed

If you have <5 interviews, push back: anything below that threshold is anecdote, and synthesis will mislead.

## Synthesis framework

### Step 1: Extract the jobs-to-be-done
For each interviewee, identify:
- **What were they trying to do** when they ran into this problem?
- **Who else was involved** in solving it?
- **What did they hire instead** (a tool, a person, a workaround)?
- **What outcome were they buying** (not features — outcomes)?

### Step 2: Cluster pains
Group similar pains. A theme requires:
- 3+ unrelated interviewees citing it
- Different language pointing to the same underlying pain
- Specificity (not "things are slow" — "I lose 2 hours/week reconciling X with Y")

Single mentions go into "isolated signals" — interesting, not actionable.

### Step 3: Surface verbatim quotes
For each theme, pull 2-3 verbatim quotes. Quotes are how you know:
- The pain is real (it has a story)
- It's worth building for (someone is willing to articulate it crisply)
- The language to use in marketing (their words > yours)

### Step 4: What surprised you
List 3-5 things that contradict or update the founder's prior hypothesis. This is the highest-leverage section. If nothing surprised you, you're not listening.

### Step 5: What you should NOT build
List 2-3 things that customers asked for OR that the founder was excited about that the data doesn't support. This is where founders lose discipline.

## Output structure

```
# Synthesis: [topic, segment, date range]

## TL;DR
- Top theme + N mentions
- Top surprise
- Top non-obvious opportunity
- Recommended next move

## Methodology
- N interviews, segment, time window, hypothesis going in

## Themes (priority order)
For each:
- **Theme name** + N mentions
- **Underlying job-to-be-done**
- **2-3 verbatim quotes**
- **Specificity / actionability**: high / medium / low
- **What this could mean** (with humility)

## Jobs-to-be-done map
- Top 3 jobs customers are hiring something to do
- For each: who's the buyer, what gets fired, what gets hired

## What surprised us (3-5 specifics)
What contradicted our prior hypothesis. The most valuable section.

## Opportunities (2-3, ranked)
For each: opportunity, evidence strength, what we'd need to validate further

## Don't build (2-3)
Things that surfaced as false signals — feature requests without underlying pain, founder pet ideas without support, etc.

## Weak signals (worth watching)
Single mentions that might mature into themes with more interviews.

## What this synthesis CANNOT tell you
Limits of the data — small sample, biased segment, etc.
```

## Bias controls

- **Don't average out specific complaints** — "users want speed" is useless; "ops teams lose 2-4 hours/week reconciling exports" is actionable
- **Survivor bias warning** — talking only to current customers misses why prospects didn't buy
- **Articulate-customer bias** — the most quotable customer is not necessarily the most representative
- **Founder confirmation bias** — flag where the synthesis aligns suspiciously well with what the founder already wanted to do; force counter-evidence

## Anti-patterns

- "Customers want better X" — meaningless without context
- "8 of 10 said they want Y" — yes, because you asked them about Y
- Treating feature requests as themes — feature requests aren't pain, they're proposed solutions
- Rounding up isolated signals into themes
- Skipping the "don't build" section because nobody wants to hear it

## Tone

- Honest. The point of customer dev is to update your priors, not validate them.
- Specific. Quote real numbers and real words from interviews.
- Skeptical. The data is rarely as clean as the founder wants it to be.

## Output format

Markdown. Use real verbatim quotes (cleaned for grammar but not meaning). End with the "Don't build" section in bold — it's the part founders skip.