asb-interview-debrief

Facilitates the learning step of a proven customer-interview method — the recording half: turning raw material from ONE customer conversation (transcript, notes, memory dump) into a brief per-person debrief file, mapped against the numbered interview-question list (Q1, Q2, … with H-number tags). One

By asmartbear · 440 installs

npx skills add asmartbear/asb-skills --skill asb-interview-debrief

Source repository · Upstream listing

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: 1. 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. 2. 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. 3. 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: 1. Ambiguous or garbled passages, each with the candidate readings — "X or Y?" — rather than an open ended "what did they mean?" 2. Suspiciously thin cells: "the notes only say 'pricing — fine.' Do you remember the number, or their reaction?" 3. 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.) 4. Always, once: "Did anything surprise you that isn't in thes