The first customer interview is easy to use: you remember all of it. The value and the trouble both start around interview ten, because discovery isn't a collection of conversations — it's a comparison across them. How many respondents have the pain? Who already pays for a workaround? Which objection repeats? Answering requires every interview to be captured the same way, and that's exactly what degrades as the series grows: notes sprawl, the comparison spreadsheet gets filled in at night from memory — reintroducing the confirmation bias the interviews were supposed to eliminate.
The fix is boring and structural: decide the fields once, extract them identically from every conversation, and keep the evidence one click from every claim.
Key takeaways
- Discovery's unit of value is the pattern, not the interview. Patterns require identical structure per respondent — which manual note-taking can't sustain past a handful.
- Define extraction fields in plain language, matched to your interview guide: core pain, current workaround, willingness to pay, objections (product fact below).
- Every synthesis claim should be one click from a quote with a timecode. "Respondents hate the onboarding" is a memory; "[14:32], respondent 7" is evidence.
- Honest limit: fifteen interviews are qualitative signal, not statistics. Structure makes patterns visible; it doesn't make percentages meaningful.
Why discovery notes rot
Interview notes decay through three predictable stages. Fresh: rich, verbatim-ish, usable. A week later: you're consulting your own summary of what you think they meant. By synthesis time: the spreadsheet row says "price-sensitive," and nobody can reconstruct whether the respondent said that or you inferred it — the distinction the whole method hangs on, as anyone who's read their Mom Test knows.
The root cause isn't laziness; it's that comparison structure and conversation flow fight each other. A good interview meanders; a good dataset doesn't. Asking the interviewer to produce both live is asking them to do two jobs at once, badly.
Fields first: encode your guide as extraction
Separate the jobs. The conversation stays free; the structure gets applied after, by processing. In MeetResult you define custom insight fields in natural language — "core pain in their words," "current workaround," "willingness to pay," "who else decides" — and every processed interview fills them from the recording, identically across respondents (product fact).
The discipline this enforces is subtle but real: writing the fields is writing your research questions. If you can't phrase what you want extracted, you don't yet know what you're testing — better to discover that before interview one than after interview twenty.
Synthesis: query the corpus, don't re-read it
With the series processed into one account, synthesis stops being an archaeology project:
- Cross-series questions. "Who mentioned competitors?" or "which respondents already pay for a workaround?" — asked of the whole archive, answered with quotes and timecodes (product fact).
- Multi-interview reports. Pull the corpus, or a slice of it, into one document when it's time to write up findings (product fact).
- The verification habit. Every surprising insight gets checked against the recording before it drives a decision — the same "transcript nominates, audio confirms" rule that interview craft demands, covered in how to transcribe interviews.
For teams whose synthesis lives in an AI-assisted workflow, the archive is also queryable by your own agent over MCP — the setup is described in give your AI agent your meeting archive.
The honest limits of structured discovery
Two cautions keep this workflow scientific rather than theatrical. First, extracted fields are LLM output: excellent at "what did they say about pricing," fallible at nuance — treat a surprising field value as a pointer to the recording, not as ground truth. Second, a discovery series is qualitative: eight of fifteen respondents mentioning a pain is a strong signal worth building on, but it is not "53% of the market." Structure sharpens judgment; it doesn't replace it.
The economics fit discovery's rhythm: interviews come in sprints — a series this month, silence while you build — and per-minute billing charges for the interviews that happened, not for the seats that waited (product fact; the model is compared in per-minute vs. per-seat pricing).
Sources and method
Product facts (custom insight fields defined in natural language and auto-filled per meeting, archive-wide questions with quoted timecodes, multi-meeting reports, full-text search, MCP access, per-minute billing) describe MeetResult as documented in the product catalog at the time of writing. Methodological guidance on discovery bias and qualitative limits is editorial practice, stated without invented statistics. Respondent consent to recording remains the researcher's responsibility.
Related: How to transcribe interviews · Give your AI agent your meeting archive · Per-minute vs. per-seat pricing · Customer discovery without the spreadsheet sprawl (use case)
Before your next discovery sprint, write your fields — then process interview one through @meetresultbot and see the structure fill itself. New accounts include free processing minutes.