Discovery interviews need decision logs

Most teams do not have a shortage of customer quotes. They have a shortage of visible decisions.

A founder opens a folder full of interview notes. A product lead points to a spreadsheet of pain points. A designer has recordings, clips, and highlights. Everyone can say they talked to users. Yet the roadmap still gets decided in the same meeting, by the loudest opinion, the biggest customer, or the feature that already had executive momentum.

That is the failure mode. Discovery interviews need decision logs, not transcripts.

Transcripts preserve what was said. A decision log preserves what the team changed because of what was learned. The difference matters because discovery is not a library activity. Product Talk defines continuous discovery as weekly customer touchpoints, by the team building the product, where small research activities are conducted in pursuit of a desired outcome: Product Talk on continuous discovery. The artifact should therefore connect learning to movement.

If the team cannot explain which decision changed after the last five interviews, the research may still be interesting, but it is not yet operating as discovery.

Interviews are not the artifact

Interview notes are useful raw material. They help a team remember language, context, objections, constraints, and examples. They can also become a comforting pile of evidence that nobody uses.

The problem is not that transcripts are bad. The problem is that transcripts are too far away from the product choice. They capture a conversation, not the commitment that followed. A transcript can tell you that three users complained about onboarding, two users asked for integrations, and one buyer did not understand pricing. It does not automatically tell you what the team will do next, what assumption is now weaker, or which risk has become more urgent.

This is why discovery can look busy while decisions remain unchanged. Teams schedule calls, tag insights, share notes in Slack, and add snippets to Notion. Then prioritization happens elsewhere. The roadmap has its own gravity. Sales has its own escalation path. Leadership has its own narrative. Discovery becomes a parallel archive.

A decision log pulls the interview evidence into the place where product work is actually shaped. It forces a simple question after each discovery cycle: what are we willing to decide differently now?

This connects directly to the distinction in Discovery is not asking customers what they want. Customers can describe situations, friction, workarounds, and stakes. They cannot carry the responsibility for product strategy. The team still needs to make the decision. The log makes that responsibility visible.

What should the decision log contain?

A decision log should be boring enough to maintain every week. If it becomes a research database, it will die. If it becomes a governance theater, people will avoid it. The useful version is a lightweight table with seven fields.

First, decision. This is the product choice under review. For example: keep onboarding self-serve for small teams, remove the advanced setup step from the first session, or delay the Salesforce integration until the activation problem is clearer.

Second, assumption. Every decision rests on a belief. The belief might be that new users understand the value proposition, that admins are the right first user, that teams will invite colleagues before seeing value, or that a missing integration is the main blocker. Writing the assumption prevents the team from hiding behind vague insight.

Third, evidence. This is where interview learning belongs, but in compressed form. Not every quote deserves the same weight. Evidence should name the source type and the pattern. For example: five recent trial users abandoned setup after reaching permissions; three sales calls mentioned integration, but only after procurement questions; two activated accounts used a manual workaround without asking for the feature.

Fourth, confidence. This does not need false precision. Low, medium, and high are often enough. The value is not statistical theater. The value is admitting whether the team is acting from signal, from weak pattern, or from a necessary bet.

Fifth, owner. A decision without an owner becomes a note. The owner is not always the person who executes. It is the person responsible for keeping the decision alive, checking whether new evidence changes it, and bringing it back when needed.

Sixth, date. Discovery decays. A strong pattern from six months ago may still matter, but it should not silently govern today’s choices. Dates make evidence age visible.

Seventh, next review. This is the field that turns the log from documentation into operating rhythm. A decision can be reviewed after ten more interviews, after a release, after a pricing test, or after the next cohort reaches activation.

A simple row might read like this: Decision, remove the mandatory team invite step from first-run onboarding. Assumption, users need to experience value alone before inviting colleagues. Evidence, four of six recent trial users stalled at invite, while two activated accounts invited others only after completing a core task. Confidence, medium. Owner, Product Lead. Date, July 13, 2026. Next review, after the next 20 trial signups complete or abandon onboarding.

That row is more useful than a perfect transcript nobody reads.

How does this change weekly product work?

The decision log works best when it becomes part of the team’s existing product cadence. It should not create a new ceremony unless the team genuinely needs one.

A practical rhythm is simple. Before the weekly product review, the product lead updates the log with any new interview evidence. During the review, the team looks only at decisions whose confidence changed, whose review date arrived, or whose evidence contradicts the current plan. After the review, owners update the next action.

This keeps discovery close to prioritization. If a pattern suggests that the wrong users are entering the funnel, the log can connect interview evidence to acquisition and activation choices. That is the same operating problem explored in Your trial is not broken: you are bringing in the wrong users. Feedback is not neutral. A trial user who should never have entered the product can generate noise that looks like insight.

The log also helps separate decision types. Some decisions are reversible and can be made with medium confidence. Others shape architecture, positioning, pricing, or enterprise commitments, and need stronger evidence. This is where product leadership matters. SVPG argues that product teams are accountable for solutions that are valuable, usable, feasible, and viable, and that discovery is used to address those risks before heavy delivery investment: SVPG on the product operating model.

A decision log does not replace judgment. It improves the conditions for judgment. It shows whether the team is learning about value risk, usability risk, feasibility risk, viability risk, or merely collecting opinions.

The counterargument: we already have research notes

Research notes answer a different question. They ask: what did we hear? A decision log asks: what did we change, pause, continue, or review because of what we heard?

The distinction becomes important in growing teams. When the founder is still close to every user conversation, decisions may live in memory. That does not scale. A new product manager cannot reconstruct the reasoning from a folder of recordings. A designer cannot know whether a feature request was rejected because it was invalid, premature, too expensive, or simply forgotten. Engineering cannot tell whether a late change is based on new evidence or renewed anxiety.

The decision log creates a shared trail. It reduces repeated debates because the team can see why a choice was made. It improves onboarding because new team members can inspect the path, not just the current roadmap. It also makes disagreement more productive. Instead of arguing about preference, people can challenge the assumption, the evidence, the confidence level, or the review date.

That is a healthier product culture. Not a culture where every decision is frozen, but one where decisions are explicit enough to be improved.

Where a fractional product lead can help

A fractional product lead often enters when discovery is already happening, but the decision trail is weak. The team has customer calls, sales notes, support tickets, analytics, and founder intuition. What it lacks is a repeatable way to convert that material into product choices.

The first move is not to install a large research system. It is to audit the last ten meaningful product decisions. For each one, ask: what assumption did we make, what evidence supported it, who owned it, when should we review it, and what would change our mind?

If the answers are unclear, the team does not need more transcripts yet. It needs a decision log.

Discovery that does not change a decision is just research inventory. The operational standard is simple: after interviews, the team should be able to point to the decision, the assumption, the evidence, the confidence, the owner, the date, and the next review. Anything less may still feel like listening to customers, but it will not reliably change the product.