Discovery interviews that produce decisions, not transcripts

Product teams run dozens of customer conversations and still argue from opinion in roadmap meetings. The interviews happened. Recordings exist. Somewhere in a shared drive, transcripts accumulate. None of it changes what gets built because the output format does not connect to a decision. Discovery interviews that produce decisions treat every conversation as input to a specific choice — prioritize this opportunity, kill that solution, test this assumption — with artifacts structured tightly enough that a PM returning six months later can reconstruct why the team believed what it believed.

Transcripts are raw material. Decisions are the product. The gap between them is a system: capture during the call, preserve in a durable snapshot, structure on an opportunity tree, and close with a decision memo that names an owner, a date, and the evidence threshold that would reverse the call.

Transcripts are archives, not artifacts

A forty-minute transcript captures everything said. It helps nobody six weeks later find the quote that justified deprioritizing onboarding redesign. Searching transcripts produces paragraphs; decisions need sentences. The failure mode is familiar: energetic interview, shared notes in a doc titled "Customer call — Acme Corp," then gradual fade until someone asks "didn't a customer mention something about exports?" and three people remember three different versions.

Transcripts still matter — for exact quotes, for compliance, for training models that summarize. They belong in the archive layer, not the decision layer. The decision layer needs compressed, structured artifacts designed for comparison across interviews and for presentation to stakeholders who will not read forty minutes of prose.

An interview without a decision memo is a calendar event, not discovery.

The weekly discovery cadence from continuous discovery practice sets a minimum bar: at least one customer touchpoint per week, one update to the opportunity tree, one assumption selected for testing. The cadence fails when touchpoints produce transcripts and the tree stays unchanged. The tree unchanged means the conversation did not surface an opportunity new enough to map, or the team did not know how to map it, or nobody owned the synthesis step.

The interview snapshot preserves signal across months

An interview snapshot is a one-page summary with two jobs: keep the interview accessible to the interviewer months later, and put the customer's voice in front of stakeholders during prioritization debates.

A practical snapshot structure:

Context facts — six to twelve quick facts that situate the story: segment, company size, tenure, plan tier, use case, team size. Facts vary by product; consistency within a product matters more than universal templates.

Key moments — three to five timestamped or sequenced beats where the customer revealed constraint, workaround, or emotional weight. Not everything said — the moments that would change a prioritization argument.

Verbatim quotes — two to four direct quotes attached to specific moments. Quotes are evidence in roadmap meetings; paraphrase is forgettable.

Opportunities surfaced — explicit problems or unmet needs stated or strongly implied, phrased as customer outcomes not feature requests. "I need a CSV export" becomes "cannot share pipeline data with finance without manual copy-paste."

Open questions — what remains uncertain; which assumptions this interview did not resolve.

Snapshots stack over weeks. Patterns emerge across snapshots faster than across transcripts because the format forces comparable fields. Five snapshots mentioning manual export workarounds is evidence. Five transcripts mentioning "export" somewhere in forty minutes is a search problem.

The opportunity tree turns scattered problems into prioritization

An opportunity solution tree maps customer outcomes at the root, opportunities (unmet needs) as branches, solution ideas as children of opportunities, and assumption tests beneath solutions. Interviews feed the opportunity layer — not the solution layer directly.

The discipline is resisting solution capture during interviews. Customers propose solutions constantly: "you should add an integration with X." The interviewer's job is to excavate the opportunity beneath the solution — what job would that integration do, what happens today without it, what does the workaround cost in time or risk.

When an interview surfaces a new opportunity, it enters the tree with a link to the snapshot that evidenced it. When an opportunity accumulates evidence from multiple snapshots, its priority weight increases in roadmap discussions with the same standing as sales requests or executive opinions — because the evidence is visible, not buried.

Solutions attach to opportunities, not to interviews. One interview might suggest three solutions to one opportunity; the tree holds one opportunity node with three solution branches, each with assumptions to test before engineering commitment. This structure prevents the common failure mode of building MVPs before proof — shipping solution-shaped demos before the underlying opportunity is validated across multiple conversations.

The decision memo closes the loop

Every discovery cycle that matters ends in a written decision — not a Slack message, not a verbal "we agreed in the meeting." A decision memo is short:

• Decision — go, no-go, or pivot on a specific opportunity or assumption test.
• Owner — one person accountable for the next action.
• Date — when the decision takes effect.
• Evidence — links to snapshots, tree nodes, experiment results.
• Reversal criteria — what new evidence would change this call.

Without reversal criteria, decisions fossilize. Without owners, decisions defer. Without dates, decisions float in "we should probably" indefinitely.

A weekly discovery review agenda enforces the loop: new snapshots presented, tree updates walked through, open decisions resolved or explicitly deferred with a date, assumption tests from the prior week reviewed for results. Fifteen to thirty minutes. The agenda is not a status meeting — it is where interviews become commitments or explicit non-commitments.

The connection to product managers writing evals for AI features is direct: discovery produces the examples of correct behavior that specs and evals later encode. An opportunity validated across interviews becomes a constraint in the execution contract. Skipping discovery means specs and evals encode assumptions nobody tested.

What makes discovery interviews produce decisions?

These questions diagnose programs that generate transcripts without changing the roadmap.

How many interviews before a prioritization change?

There is no universal number. There is a evidence threshold defined per decision type. Low-risk UX improvements might move after two consistent snapshots. Billing model changes might require eight conversations across segments. The rule: define the threshold before interviews start, not after results disappoint.

Who synthesizes — the PM, designer, or a researcher?

The product trio — PM, designer, engineer — participates in interviews and synthesis. Centralized research supports methodology and reviews quality; it does not gatekeep every snapshot. Synthesis delayed waiting for a research team queue is synthesis that does not ship decisions on the weekly cadence.

When is a transcript enough without a snapshot?

When the conversation is purely relational — partnership check-in, renewal risk conversation without product implications — skip the snapshot. When the conversation might influence what gets built, snapshot or admit the interview was not discovery. Middle ground produces transcript archives that pretend to be discovery.

A common argument runs the other way

The opposing view holds that structured discovery slows teams that need to ship — that experienced product leaders already know what to build and interviews are theater that delays conviction.

That argument works when the domain is genuinely understood and the customer base is homogeneous. It fails when the team serves multiple segments, when the last launch underperformed expectations, or when AI and automation change user workflows faster than intuition updates. Structured discovery is not infinite research. It is a weekly minimum that prevents expensive conviction in untested assumptions.

The anti-pattern is not skipping interviews. It is running interviews without the artifacts that force decisions — which produces the theater the opposing view correctly criticizes.

Key takeaways

• Discovery interviews that produce decisions end in decision memos — not transcripts in shared drives.
• Interview snapshots compress one conversation into comparable, durable evidence with quotes and opportunities.
• Opportunity solution trees separate customer problems from solution ideas and link evidence to nodes.
• Weekly cadence: one touchpoint, one tree update, one assumption test — or admit discovery paused.
• Decision memos require owner, date, evidence links, and reversal criteria.
• Define evidence thresholds before interviews, not after results fail to persuade.

Conclusion

Customer conversations are expensive in calendar time and cheap in clarity when the output is a transcript. The system that converts conversations into decisions is smaller than most research programs: a snapshot template, a living opportunity tree, a decision memo format, and a weekly review that treats unresolved decisions as debt.

The next interview should answer one question before it starts: what decision will this conversation inform? If the answer is "general learning," schedule a different meeting. If the answer is "whether export automation outranks onboarding redesign this quarter," the snapshot and memo write themselves — and the roadmap meeting has evidence instead of volume.