Turning Interview Notes into a Problem Map

An evidence unit is one observation, expressed as a full sentence, with a source tag. This is the core discipline behind affinity mapping from transcripts: you pull short excerpts, write each as a single note, and keep a source ID so every theme traces back to a line of the original file (GoTranscript).

Raw quotes are usually bad units. People ramble, use filler words and circle back, so a paragraph of auto-transcript should be distilled into an action plus its context: who does what, how, why and with what outcome (Design Bridges). One note should carry one finding and be understandable on its own.

A workable unit format:

U-014 | P03 | 00:12:10-00:12:34 | severity:3
Customer re-keys supplier invoices into the ERP because the
portal export drops the tax code, and does this every Friday.

Four rules keep units clean:

1. One idea per unit. If a sentence contains two observations, split it.
2. Past or present behavior only. Hypotheticals ("I would probably...") are discarded at this stage, not coded.
3. Keep the source tag. Participant ID plus timestamp or line numbers. Without it you cannot defend a theme later.
4. Write the unit in plain language, close to what was said, without adding interpretation. Interpretation belongs to themes.

For a ten-interview batch you should expect this step to produce somewhere between 15 and 40 units per interview depending on length. If you have fewer than ten units from an hour-long conversation, you are summarizing rather than segmenting.

A code is a short label that says what problem a unit is an instance of. The codebook is the table that defines each code, so two people coding the same unit reach the same answer.

Start with a handful of interviews, code them, and then freeze the list. After the lock, new codes can still appear, but only through a merge log: a short note saying which existing code the new material was folded into, or why a genuinely new code was needed. Without this, every interview invents vocabulary and your counts mean nothing because no two units share a definition.

Two quality checks are worth the ten minutes. First, have a second person code ten random units against the locked codebook without discussion. If you agree on fewer than seven of ten, the definitions are too vague and the code needs a tighter inclusion rule. Second, read each code aloud as a sentence: "Customers cannot X, so they Y." If that sentence is not a problem, it is probably a feature request and belongs in a separate parking lot, not the codebook.

Keep the codebook small. A locked book with 20 to 30 codes will cover a ten-interview batch. If you are past 40 active codes, you are coding symptoms rather than problems and should merge upward before continuing.

The instinct is to count how often a phrase appears. Do not. One emotional participant can mention the same frustration eleven times in forty minutes and dominate the ranking.

Count instead how many distinct interviews contain at least one unit for each code. This is a presence/absence matrix: one row per interview, one column per code, a 1 where the code appears and a 0 where it does not (Skimle). It gives you the honest denominator, and it reveals which codes co-occur, which is often more interesting than the counts themselves. Always report the base: three of five interviews is a very different signal from three of fifty (Skimle).

Frequency is also not importance. A code raised by two participants can matter more than one raised by fifteen if those two are your primary persona, which is why the Rock Center advises focusing discovery on one or two primary personas rather than diluting attention across many (HBS Rock Center).

A worked example makes the trap visible. Suppose you ran 12 interviews and coded 900 units:

Raw mention counts put EXPORT-SLOW first with 46. Distinct-interview counts put it first too, at 11 of 12, but the severity column shows it costs people seconds, while AUDIT-LATE appears in only three interviews yet carries the top severity rating. A map built on mentions alone would recommend speeding up exports and miss the audit problem entirely. This is exactly the failure that severity rating exists to prevent.

Severity is a per-unit judgment, not a per-code one, because the same problem can be trivial for one customer and career-threatening for another. Magnitude coding, adding a symbolic or numeric meta-code to an existing code to capture intensity, direction or evaluative content, is a standard qualitative technique for exactly this reason (Delve).

Use a five-point scale anchored to observable consequences, not feelings:

The strongest signal on this scale is action already taken. Richard von Kaufmann's problem interview script treats "what actions have been taken to find better solutions" as the most important question, because if little or no action has been taken the problem is low-level for that person (Richie von Kaufmann). If a customer already pays for a workaround, that is evidence of severity 4 or 5 without any interpretation from you. The same logic appears in The Mom Test's advice to ask what someone currently pays and how much time the problem costs them, rather than what they would pay for a hypothetical fix (Looppanel).

Report severity as the median score per code alongside the interview count. Then apply a simple decision rule:

• High reach (half the interviews or more) and median severity 3 or above: build.
• Low reach but any severity 5: investigate with three more interviews aimed at that segment.
• High reach and severity 1 or 2: document, do not build.
• Low reach and low severity: discard.

That rule is the insight a first search result will not give you: it converts a subjective pile of quotes into a sortable decision, and it keeps the loudest annoyance from winning.

Group related codes into themes, but the label matters more than the grouping. A strong theme names the customer's reality; a weak one names your solution (GoTranscript). "Users don't see the invite entry point" is a theme. "Add a tooltip" is a backlog item wearing a theme's clothes.

A useful test, borrowed from jobs-to-be-done thinking, is to phrase each theme as the progress the customer is trying to make rather than the task they perform. JTBD holds that people hire products to make progress toward a goal, and interviews should surface the trigger for searching, the first purchase and the switch between solutions (dscout). A theme like "finance teams cannot close the month without re-keying supplier data" describes a job and a blockage. A theme like "export button improvements" describes your roadmap.

Good theme labels share three properties: they contain a verb the customer would use, they name the blocker, and they survive being read aloud to the customer without embarrassment. If you could not say the label to the person you interviewed, it is internal jargon.

Affinity mapping sessions fail for a predictable reason: teams run them on dirty input, then argue about grouping. Clean units make clustering fast, and silent clustering before discussion stops the first senior voice from steering the whole board (Design Bridges; GoTranscript).

The output is a single page a decision-maker can read in three minutes. Six blocks, in this order:

1. Scope line: personas covered, number of interviews, date range of conversations.
2. Themes, ranked by the decision rule above, each with a one-sentence statement, distinct-interview count, median severity and one anchor quote with its source tag.
3. Runner-up themes: one line each, no quotes, so they are recorded but not competing for attention.
4. Discarded list: see the next section.
5. Open questions: what the evidence cannot answer, phrased as the next interview question.
6. Recommended next action: build, test with a lo-fi prototype, or run three more interviews.

Keep the discarded list on the page. It is the cheapest defense you have when someone asks why their pet feature is not on the map.

This is also where a journey map earns its place. Laying the themes along the steps of the customer journey, from first awareness through purchase and use, shows where the biggest pain points sit and lets you earmark candidate responses to each, and the exercise stays iterative as new evidence arrives (HBS Rock Center). A theme map tells you what hurts; a journey map tells you when.

Most synthesis decks are inflated by three kinds of material that should never reach the map.

Compliments. "This is a great idea" is worthless as evidence. Fitzpatrick's whole framing is that people, especially people who like you, tell you what you want to hear, so compliments should be deflected rather than recorded (The Mom Test). Studio Zao's guide makes the same point: questions like "do you think it's a good idea" produce false positives because they ask for an opinion about the future rather than a behavior from the past (Studio Zao).

Hypotheticals. "I would definitely use that" is an over-optimistic guess. The Mom Test's rule of thumb is that anything involving the future is an over-optimistic lie, and the fix is to ask what the person does now and what it costs them (Looppanel). NSF I-Corps instructors put it plainly: stories about past and present behavior beat hypotheticals, because past behavior indicates the threshold at which a customer actually takes action (Desert Pacific I-Corps).

Feature requests. People know what their problems are but not how to solve them, so a requested feature is a symptom at best (Looppanel). Park requests in a separate list, and only promote one to the codebook if you can restate it as a problem with a trigger and a current workaround.

There is a fourth category worth naming: transcripts that should not be coded at all. If an interview was run with leading questions, or the participant bought so long ago they cannot recall the decision, the transcript is contaminated. Fitzpatrick warns against dumping whole transcripts into a knowledge base and extracting lessons from it, because that muddles biased and bad data together with the good (Rob Fitzpatrick). Mark contaminated transcripts as excluded and note the reason on the map, so the count of usable interviews stays honest.

AI helps here, but only narrowly. It is reasonable to use a model to draft units from a cleaned transcript, to suggest candidate codes for a human to accept or reject, or to rehearse an interview before it happens. It is not a substitute for running the conversation, and treating automated output as equal evidence inflates the map with exactly the material you were meant to discard (Rob Fitzpatrick; Great Lakes I-Corps).

If you want a model to pre-draft units or stress-test a codebook against your transcripts while a human keeps the final call, a single API for text models makes that easy to wire into your existing pipeline: Quanta Inference.