Customer Interview Analyst

Interview transcripts hide their patterns behind charisma: the articulate participant gets remembered, the quiet majority gets lost, and whoever spoke last feels like the truth. This skill replaces memory with method — a consistent coding scheme applied across every transcript, a participant-by-code matrix, and pattern thresholds — so the findings that emerge are the ones the evidence supports, each defensible with counts and quotes.

When to use this skill

• A batch of three or more interviews is complete and must become findings
• Discovery research needs to inform a build, kill, or positioning decision
• Two colleagues ran interviews separately and their headline takeaways disagree
• Building a durable evidence base future questions can be run against, not a one-off recap

Workflow

1. First pass: read, do not code. Read every transcript once for orientation. Write candidate patterns down as hypotheses to test during coding — recording them now prevents them from silently becoming conclusions later.
2. Fix the coding scheme. Start from the base scheme below, adapt it to the study, and freeze it before the coding pass. If a new code proves necessary mid-pass, add it and re-sweep the transcripts already coded; unevenly applied codes manufacture fake patterns.
3. Second pass: code every transcript, oldest first. Tag segments, not whole answers — a single reply can carry a pain, a workaround, and a switching signal. Participant IDs stay attached to everything.
4. Separate reported behavior from self-theory. "Last Tuesday I exported it and rebuilt it by hand" is behavior; "I always end up doing things manually" is generalization. Code both, weight the first — specific recent episodes are the closest thing interviews have to ground truth.
5. Build the matrix: participants down the side, codes across the top, presence or counts in the cells. This one artifact kills the loudest-voice problem, because patterns must recur across people rather than within one person's eloquence.
6. Apply a pattern threshold before calling anything a finding. A reasonable default: present in at least a third of participants and in at least two segments, where segments exist. Below threshold is a signal — reported separately and labeled honestly as such.
7. Write findings with the evidence attached: the pattern, the count ("7 of 10 participants"), two typical quotes with IDs, and the so-what for the decision at hand. Check the interviewer's phrasing whenever a quote seems too perfect; answers to leading questions get flagged, not counted.

Coding scheme (base)

• PAIN — a problem in their workflow, tagged with severity: blocks, slows, or annoys
• EPISODE — a specific, dated behavioral account; the highest-value code in the scheme
• WORKAROUND — what they built or do instead; duct tape is unpriced demand
• GOAL — the outcome they are trying to achieve that this area touches
• TRIGGER — the event that started a search, a switch, or a purchase
• TOOLSTACK — what they use today and how the pieces connect
• ASK — a requested feature, recoded alongside the underlying need it implies
• MONEY — budget, willingness to pay, who approves spend
• SWITCH — friction or fear about changing from the current way

Output format

A findings memo: method line (participant count, segments, date range, scheme version); findings above threshold with counts and quotes; signals below threshold; the participant-by-code matrix as an appendix; and the open questions the next interview round should target.

Guardrails

• No finding stands on fewer than two participants or without one verbatim quote behind it
• Feature ASKs are evidence about problems, never instructions to build
• One participant repeating a pain five times counts once in the matrix
• Disconfirming cases ship with the finding they complicate — a 7-of-10 pattern has three other stories, and the reader gets them
• Interviews establish the existence and texture of problems, not market size; counts of ten people never masquerade as percentages of a market