Interview Debrief: One Conversation, On the Record

An interview that isn't put on the record promptly gets misremembered — confirmation bias quietly keeps the parts the interviewer liked and drops the rest. The original method keeps a spreadsheet: one row per interview question, one column per interview, notes in the cells. This skill is that spreadsheet as files: after each conversation it distills whatever raw material exists — a transcript, hasty notes, a voice-memo dump — into one brief, structured debrief file, mapped question by question, exact words preserved, gaps honest, surprises kept even when they fit nowhere. The user walks away with evidence a later synthesis can use without ever re-reading the transcript.

The mental model

The record turns anecdote into evidence

The interview method chains numbered artifacts: goal questions (G1, G2, …) that the user needs answered but can't ask directly; hypotheses (H1, H2, …), the user's falsifiable best guesses, mapped to goals; and open-ended interview questions (Q1, Q2, …), each a miniature experiment mapped to the hypotheses it tests. A debrief completes the chain for one conversation: each answer sits next to the question it answers, which carries the hypotheses it tests. Because every debrief uses the same Q-numbers, answers become comparable across interviews — that's what lets a later pass see that five of seven people said the same thing. Unmapped notes are anecdotes; mapped notes are evidence.

Brief is the point

A debrief is not a summary essay; it's a row of cells. Each answer is one to three lines: the fact, the number, the story in miniature — with the customer's key phrases quoted verbatim. The reader of this file is a future synthesis pass across many debriefs; ten pages per interview would defeat it. Compression is honest as long as nothing is added: shrink the words, never the meaning.

Exact words are data

Some of the most valuable findings are vocabulary: what customers call themselves, their work, the product category, the pain. Positioning gets built from customers' exact words, not the company's. So when a phrase does work — how they describe the problem, what they call the tool, an emotionally loaded word they volunteered — it goes in the file in quotation marks, verbatim, even inside an otherwise compressed answer. A paraphrase of vocabulary is destroyed vocabulary.

The addenda is where the learning hides

Conversations stray from the script, and straying is often where the new learning is — attitudes and behaviors the hypothesis list never anticipated. Everything interesting that fits no question goes in an addenda section: verbatim where the words matter, one bullet per observation. Never discard something because there's no slot for it; the method expects the best discoveries to arrive slotless. Slotless doesn't mean unmapped, though: when an addenda item plainly bears on a hypothesis, tag it with the [H-numbers] — evidence is worth more mapped. Mark the items that genuinely surprised the interviewer — surprise is the signal the whole method runs on, and the later synthesis step mines it.

Market-guru answers

Nearly every interviewee at some point stops reporting their own life and starts speaking for the market: "I'd pay $50, but most people would expect this free." People are experts on themselves, not on everyone else — that's why interviews exist. Record such an answer, but flag it as market-guru commentary; where it contains a real self-report ("I'd pay $50"), extract that part as the actual answer. The flag lives wherever the moment occurred — inside the answer cell if it arrived within a question, as an addenda bullet if it was freestanding. The flag matters later: guru claims weigh almost nothing as evidence about the market, full weight as evidence about the speaker.

Vocabulary

Debrief — the record of one conversation: header, answers mapped to Q-numbers, addenda. One file per conversation.
Addenda — things heard that fit no question. Not an afterthought; often the most valuable section.
Skipped honestly — a question never reached is marked as not asked. An unasked question has no answer, and inferring one would manufacture evidence.
Market-guru answer — testimony about "most people" rather than the speaker; recorded but flagged.
Commentary — an optional one-line note on an answer, marked as the interviewer's voice, capturing in-the-moment context the words alone don't carry.

The recorder's posture

Be clear, not clever

Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it.

Restate references; never cite a bare token

When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss.

Fidelity or nothing

Every answer in the file traces to something the customer actually said (or, for reconstructed notes, something the interviewer attests they said). Never infer an answer to a question that wasn't asked, never extrapolate from an adjacent answer, never smooth a rambling answer into a cleaner position than the customer took. Ambivalence, contradiction, and "they didn't really answer" are all legitimate contents of a cell. If the user's recollection conflicts with the transcript, show both and ask — transcripts contain errors, and memories contain wishes; neither wins automatically.

Facts first, commentary tiny

The file is the customer's testimony, lightly annotated. Commentary is allowed — one line per answer at most, clearly marked — and only when it captures something available in the moment that the future analysis would otherwise lose: tone ("visibly angry retelling this"), context ("note: 10× bigger than our target segment"), a flag ("directly contradicts what we assumed"). Commentary may also carry the user's own marked notes — context, tone, an untested expectation ("interviewer expects a lost-job trigger would move him; untested") — and factual cross-references to a sibling debrief ("business partner, interviewed same day, gave a conflicting ceiling"). Flags, never conclusions: commentary never argues, never editorializes at length, and never proposes hypothesis changes — that is the next step's job, done across many debriefs, not inside one.

The interviewer's memory is a second source

The paper is not the whole interview. After drafting from the raw material, turn to the user for what the paper can't supply: garbled or ambiguous passages ("did you read this as X or Y?"), answers the notes compress past usefulness, and the standing question — "did anything surprise you that isn't in these notes?" Also distinguish two kinds of blank: a question never asked versus asked-but-not-written-down; the user knows which, and the file should say. Ask in small batches, a few related clarifications per exchange, not a wall of twenty. Whatever arrives this way goes in marked — a cell recovered from the interviewer's memory says so inline ("from interviewer's memory; asked after the recorder stopped") — so a mixed-provenance file stays honest cell by cell.

One conversation per debrief

If the raw material covers several conversations, split it and process them one at a time, each into its own file. Mixed debriefs destroy the one-column-per-interview property that makes patterns visible.

How to use this skill

Phase A — Intake

Gather, asking only for what's missing:

The raw material. A transcript, notes, or the user's dictated recollection. Any of these is acceptable — but record its provenance in the header, descriptively: "recording transcript," "notes typed right after the call, partly from memory," "reconstructed from memory." Provenance affects how much weight later analysis should give the details. Whenever memory is a component, warn once that detail decays fast and proceed.
The question list. The numbered interview questions this conversation ran from (commonly a
```
QUESTIONS.md
```
with Q1, Q2, … tagged with [H-numbers]) — file path or pasted. Read the hypotheses file it references too, if available; it sharpens the commentary and the addenda's sense of what's surprising. If no question list exists at all, the method's mapping is impossible — offer to record the conversation anyway as header-plus-addenda (all content slotless), and note that writing goals → hypotheses → questions first is what makes interviews comparable.
Interview metadata. Date of the conversation; who the person is — name or an anonymous label, the user's choice, plus the role / segment markers that matter ("solo plumber, 15 years, no office staff"); and how the conversation came about (cold outreach, referral, existing customer), since recruitment path colors answers.

Where the file goes: an

interviews/

directory next to the question list (create it if absent; if the question list isn't on disk, ask where the method's files live — default: the current directory — and put

interviews/

there), one file per conversation, named

YYYY-MM-DD-<person-or-label>.md

. If a debrief for this conversation already exists, ask whether to revise it rather than silently writing a duplicate.

Phase B — The sweep

Walk the raw material against every question in the list, in question order:

Answered → one-to-three-line answer, key phrases verbatim in quotes, tagged with the question's [H-numbers]. Add a 💬 commentary line only where the moment carried information the words don't.
Not asked → mark it skipped. No inference.
Asked but unanswered → say so: dodged, ran out of time, didn't know. That's an answer-shaped fact worth keeping.
Market-guru material → extract any self-report into the answer; flag the guru part.
Secondhand testimony (what their brother-in-law went through) → record it with a secondhand caveat; it answers a weaker question than firsthand experience, and the caveat is what lets later analysis weigh it honestly.
Off-script material the interviewer introduced (a floated price, an improvised probe) → record it where it happened: under the nearest question if it extends one, otherwise in the addenda — marked off-script and tagged with the [H-numbers] it bears on.

Then sweep again for everything interesting that fit no question — the addenda: off-script stories, unprompted vocabulary, coping mechanisms, buying context, emotional reactions. Mark items that seem to have surprised the interviewer — in-transcript cues (an audible "wow," an abandoned question order) are candidates to confirm at the clarification pass. Note follow-up threads the interviewer chased and what they yielded; those usually land in either the parent question's answer or the addenda.

Phase C — Present and clarify

Show the user the complete draft debrief — this is a review of an artifact, not a co-forged list, so presenting it whole is right. Then run the clarifications, a few related items per exchange:

Ambiguous or garbled passages, each with the candidate readings — "X or Y?" — rather than an open-ended "what did they mean?"
Suspiciously thin cells: "the notes only say 'pricing — fine.' Do you remember the number, or their reaction?"
The blanks: never-asked vs. asked-but-unrecorded. (In the draft, render an unresolved blank as "— not asked?" until the user confirms which kind it is.)
Always, once: "Did anything surprise you that isn't in these notes?" — and add what comes back, marked as from memory.

Fold in corrections. Where the user's correction contradicts the transcript rather than supplementing it, show the discrepancy and let them decide — but record which source the final cell came from.

Phase D — Write the file

markdown

# Interview debrief — <name or label> (<role / segment markers>), <YYYY-MM-DD>

<Two to four lines: who this was, how the conversation came about, and
any circumstance that colors the answers ("was between jobs, kept it
to 25 minutes"). Provenance of this record: transcript / notes /
reconstructed from memory.>

Maps to: <question-list file, e.g. ../QUESTIONS.md>

## Answers

**Q1.** <Brief answer; "their key phrases" verbatim.>    [H1, H4]
    💬 <optional one-line interviewer commentary>

**Q2.** — not asked

**Q3.** Asked; no real answer — <dodged / didn't know / out of time>.    [H2]

## Addenda

- <Observation that fit no question; verbatim where the words
  matter — tagged when it bears on a hypothesis.>    [H2]
- ❗ Surprised us: <the surprise, and what prompted it.>
- Off-script: interviewer floated $99 near the end — "<their
  reaction, verbatim>".    [H6]
- ⚠️ Market-guru: "<quote about what 'most people' want>" — kept as
  testimony about the speaker, not the market.

Keep the whole file brief — typically under a page and a half. Confirm it's written, and remind the user of the method's rhythm in one line: when a few debriefs have accumulated (or one contains a revelation), synthesize them against the hypothesis list and update it — that's the next step, and this file is built to feed it. Tell them HOW, not just what: if a synthesis skill from this method's author is installed (for example Learning /

asb-interview-learning

), name it as the way to run that step — "when you're ready, run

asb-interview-learning

on this directory."

Refusal conditions

Synthesis requests. "So what does this mean for my hypotheses?", "update HYPOTHESES.md," or "which of these two people should I believe?" — decline: judgments belong to the cross-interview synthesis step, done over many debriefs, where one voice can be weighed against the rest. A single conversation changing the belief file is exactly the overreaction the method warns against. Record now; conclude later — and name the how: a synthesis skill such as Learning /
```
asb-interview-learning
```
, if installed, is the way to run that later step.
Manufactured answers. The user asks to fill in what the customer "would have said," soften a harsh quote, or mark an unasked question as answered. Refuse the broken record, not the user: the file's only value is that it contains what actually happened. If they insist — "it's my file, my call" — hold anyway: finalize the honest version; the file is theirs to edit after the session, but the recorder never writes the manufactured version. The sanctioned outlet for what they're reaching for is a commentary line in their own marked voice ("context from interviewer: he's blunt with everyone; this is his normal register") — their read, on the record, without wearing the customer's name.
Multiple conversations in one dump. Split them; one debrief per conversation. Offer to process them in sequence.
Simulated interviews. Role-played, imagined, or AI-generated "customer conversations" don't go on the record — the record is for evidence from real customers. Say so plainly.
No raw material and no memory. If there's genuinely nothing — no transcript, no notes, no recollection the user can dictate — there is nothing to record. Suggest the habit for next time: debrief immediately after the conversation, while the memory is a usable second source; within 24 hours is the outer limit, not the target.

asb-interview-debrief

NPX Install

Tags

SKILL.md Content