Table of Contents
- When the Evidence Tells Two Different Stories
- Why Product Teams Build the Wrong Thing Despite Doing Discovery
- The Discovery Evidence Audit Framework
- Scoring Your Evidence: The Three Dimensions
- Real-World Application: Two Teams, Same Data, Different Outcomes
- How to Run Your First Evidence Audit This Week
- FAQ
Every product manager has been in this meeting. You have interview transcripts, survey data, analytics dashboards, a competitor teardown, and three Slack threads from your sales team. All of it points to a clear answer, except that the interview data says one thing and the usage metrics say another. The product discovery evidence you have collected is contradicting itself, and someone in the room wants a decision by Friday.
This is the moment where good discovery work either pays off or collapses. Not because the research was sloppy, but because nobody stopped to ask which evidence should actually carry weight in this decision.
When the Evidence Tells Two Different Stories
Nadia ran product for a B2B collaboration platform. Her team had spent six weeks in continuous discovery, conducting weekly customer interviews, running a 400 person survey, and pulling behavioral data from the product analytics stack.
The interviews were compelling. Eight of twelve customers described the same frustration: they wanted a way to tag conversations by project, not just by channel. The quotes were vivid. The pain was real.
But the behavioral data told a different story. When the team looked at how customers actually organized their work in the product, fewer than 15% ever created more than two channels. Most users never touched the existing organization features at all.
Nadia’s instinct was to trust the interviews. The customers were articulate, specific, and consistent. Her engineering lead pushed back: “They’re telling you what sounds logical, not what they actually do.” The survey data, meanwhile, was inconclusive. Tagging ranked fourth on a list of requested features, behind three items the team had already shipped.
She had evidence. She did not have clarity. And she was not alone.
Why Product Teams Build the Wrong Thing Despite Doing Discovery
The problem is rarely that teams skip discovery. According to a 2023 study from Pendo and Product Collective, 74% of product teams report conducting some form of user research before committing to a build. Yet nearly 80% of new features see low adoption after launch. The gap between doing research and making good decisions from that research is where most product work breaks down.
The root cause is that product teams treat all product discovery evidence as equal. A quote from a customer interview carries the same weight as a data point from an analytics dashboard. A feature request from the VP of Sales lands with the same authority as a pattern found across fifty support tickets.
This is the equivalent of a doctor giving equal weight to a patient’s self-reported symptoms, a blood panel, and a neighbor’s opinion. Some evidence is closer to the truth. Some carries more commitment behind it. Some is simply more recent than the rest.
Tim Herbig, a product discovery coach and author, frames this well: the two dimensions that matter most when evaluating discovery evidence are proximity (how close the evidence is to actual user behavior) and commitment (how much the person providing the evidence had at stake when they provided it). First-hand behavioral data where a user made a real choice is more reliable than a survey response where a user imagined what they might do.
Without a structured way to evaluate these dimensions, product managers default to whichever evidence is most vivid, most recent, or most loudly advocated by a stakeholder with organizational power.
The Discovery Evidence Audit Framework
The Discovery Evidence Audit is a structured review you run before any build decision. It forces you to lay out every piece of evidence your team has gathered, score each piece on three dimensions, and use those scores to see where your confidence is actually strong and where it is weaker than it feels.
Here is how it works.
Step 1: List Every Piece of Evidence
Before your next product roadmap planning session or feature commitment meeting, create a simple table. Each row is one piece of evidence your team is relying on to justify the decision. Be specific. Not “customer interviews” but “12 interviews conducted March 3 through March 21, targeting mid-market ops managers.”
Step 2: Categorize the Source Type
Label each piece as one of four types:
- Behavioral: What users actually did. Analytics, usage logs, A/B test results, purchase patterns.
- Attitudinal: What users said they want or feel. Interviews, surveys, NPS comments, feedback forms.
- Proxy: Evidence from people who are not the end user. Sales team requests, support ticket themes, competitor analysis, analyst reports.
- Assumed: Things the team believes but has not tested. Internal hypotheses, executive opinions, “everyone knows” statements.
Step 3: Score on Three Dimensions
Rate each piece of evidence on a 1 to 5 scale across three dimensions.
Scoring Your Evidence: The Three Dimensions
Proximity (1 to 5): How close is this evidence to actual user behavior in your product? A score of 5 means you observed real users making real choices in the product. A score of 1 means someone told you about something they heard from someone else.
Commitment (1 to 5): How much did the person providing this evidence have at stake? A customer who paid for a workaround (5) is more credible than a customer who said “yeah, that would be nice” in an interview (2). A user who churned over a missing feature (5) carries more weight than one who mentioned it on a feedback form (2).
Recency (1 to 5): How fresh is this evidence? Data from last week (5) versus a study from eighteen months ago (2). Markets move. User behavior shifts. Evidence decays.
Step 4: Find the Gaps
Multiply the three scores for each piece of evidence to get a composite score (max 125). Then sort your table. What you will usually find is revealing:
- The evidence your team talks about most often scores lower than expected (vivid interview quotes with low commitment, low proximity).
- The evidence nobody mentions scores higher than expected (behavioral data that nobody has reviewed in context).
- Entire quadrants are missing. You have plenty of attitudinal data and zero behavioral validation, or vice versa.
This is the audit. It does not tell you what to build. It tells you how much confidence you should actually have in your current evidence, and where you need to do more work before committing.
Real-World Application: Two Teams, Same Data, Different Outcomes
Consider two product managers at a SaaS company that sells project management software. Both teams received the same inputs: a quarterly customer feedback report showing that “better reporting” was the number one requested feature, along with usage data showing that only 22% of customers had ever opened the existing reports tab.
Olakunle, the first PM, took the feedback report at face value. “Better reporting” was the top request. He scoped a three month project to rebuild the reporting module with customizable dashboards, scheduled delivery milestones, and committed engineering resources.
Sienna, the second PM, ran a Discovery Evidence Audit first. She scored the feedback report: attitudinal evidence, moderate commitment (customers filled out a form but did not pay for it or churn over it), moderate recency. She scored the usage data: behavioral evidence, high proximity, high recency. The composite scores told a clear story. The behavioral evidence was stronger, and it said most customers did not use what they already had.
So Sienna ran five targeted interviews, this time asking customers to walk through their last reporting workflow in the product. What she found was that customers wanted “better reporting” but did not mean better dashboards. They wanted a one click way to export the data they already saw on their main screen into a format they could paste into a slide deck. The feature was a two week build, not a three month rebuild.
Olakunle’s team shipped a beautiful reporting module. Adoption was 18%. Sienna’s team shipped an export button. Adoption was 61% in the first month.
The difference was not talent or instinct. It was that Sienna knew which evidence to trust and which evidence needed more investigation before it could carry a build decision.
How to Run Your First Evidence Audit This Week
Pick one feature or initiative your team is currently debating. Before your next planning meeting, spend thirty minutes building the evidence table.
Open a spreadsheet. List every input that has been mentioned in the discussion: the interview that keeps getting quoted, the dashboard metric someone cited, the competitor feature your CEO flagged, the support tickets your head of CS forwarded. For each one, label the source type (behavioral, attitudinal, proxy, assumed) and score it on proximity, commitment, and recency.
Bring the table to the meeting. Do not present it as a verdict. Present it as a map: “Here is every piece of evidence we have, here is how it scores, and here is where we have gaps.”
You will find that the conversation shifts. Instead of debating whose evidence is more compelling, the team starts asking where the evidence is weakest and what it would take to fill those gaps. That question, “what would it take to get higher confidence evidence before we commit?” is the single most valuable question a product discovery team can ask.
In your next 1 on 1 with your engineering lead, walk through the audit together. When engineers see that a build decision rests on a single survey question and an executive’s intuition, they become allies in pushing for better evidence rather than skeptics who doubt the entire discovery process.
FAQ
What is a Discovery Evidence Audit in product management?
A Discovery Evidence Audit is a structured practice where product managers list every piece of evidence supporting a build decision, categorize each by source type (behavioral, attitudinal, proxy, or assumed), and score each on proximity to real user behavior, commitment level from the source, and recency. The audit reveals which evidence is strong enough to justify a build commitment and where gaps demand more research.
How do I know which type of product discovery evidence to trust most?
Behavioral evidence (what users actually did in your product) almost always outranks attitudinal evidence (what users said they want). Within each type, prioritize evidence where the source had something at stake: a customer who paid for a workaround or churned over a missing feature provides stronger signal than one who answered a survey question. Recency matters too, as evidence older than six months should be re-validated before driving major decisions.
How often should product teams run an evidence audit?
Run a Discovery Evidence Audit before any decision that commits more than two weeks of engineering time. For teams practicing continuous discovery, a lightweight version of the audit (categorize and score in ten minutes) should become a standing part of your weekly planning rhythm. The goal is not to add process; it is to catch the moments when your team is about to commit resources based on weaker evidence than they realize.
Can I use the Discovery Evidence Audit for existing features, not just new ones?
Yes. The audit is especially useful when deciding whether to invest in improving an existing feature versus building something new. Score the evidence supporting each option. Teams often discover that the case for a feature rebuild rests on proxy evidence (competitor analysis, executive opinion) while the case for improving what exists is supported by stronger behavioral data.
What is the difference between the Discovery Evidence Audit and assumption mapping?
Assumption mapping identifies what your team believes but has not validated, typically done early in discovery to decide what to test. The Discovery Evidence Audit happens later, after you have collected evidence, to evaluate the strength and reliability of what you found. Assumption mapping asks “what do we need to learn?” The evidence audit asks “how much should we trust what we learned?”