"Users said they want this."
That sentence, offered as evidence in a roadmap review, is almost useless. It doesn't tell your CPO which users. It doesn't tell engineering how many. It doesn't tell the data team whether this is a signal from your highest-value segment or your most vocal churned accounts. And when someone pushes back — "are you sure that's broadly true?" — you have nothing to return to.
The sentence sounds like evidence. It has the grammatical shape of evidence. It is not evidence.
What Makes Research Evidence Citable
Evidence in a roadmap context is citable when it has four properties: source, scope, specificity, and a decision-relevant frame.
Source means there's a traceable origin — a participant identifier, a session date, a timestamp in the transcript. Not a name (participant privacy matters), but a stable ID that lets anyone retrieve the original utterance if they want to. P-004, Session 2025-Q3-03, 14:32 is a source. "Users in our last round of interviews" is not.
Scope means you've been explicit about the sample. Eight interviews. Six enterprise customers, two mid-market. Conducted over two weeks in September. Not a nationally representative survey — a deliberately scoped qualitative study aimed at a specific question.
Specificity means you're quoting what was actually said, not what you interpreted it to mean. "I've given up trying to pull the report myself — I just wait for ops to send it to me on Monday" is specific. "Users don't find the reporting feature intuitive" is an interpretation.
Decision-relevant frame means the evidence is connected to something your roadmap is asking. It's not floating in a report — it's attached to a job, a hypothesis, a prioritized problem statement. "This quote maps to Job #2 in our framework — cross-team coordination — and it's the third participant this quarter to describe abandonment at the reporting handoff step" tells the roadmap team something actionable.
Tomer Sharon, who wrote Validating Product Ideas and spent years at Goldman Sachs building research practice, describes this as the difference between evidence and information. Information is collected. Evidence is organized around a question. The same interview data can produce either, depending on how you synthesize it.
Before the Review: Prepare the Evidence Layer
Roadmap review prep is where most PMs lose the evidence thread. They pull together the deck, they know research happened, but the research lives in a Miro board or a Notion page that requires navigation. By the time they're building slides at 10pm the night before, they're summarizing rather than citing.
The discipline here is treating synthesis output as a reference document, not a one-time deliverable. Every quote you might want to cite should exist in a form that includes its source, the session context, and the job it maps to. If you're working from transcript exports, this means building that structure into your note-taking. If you're working with a synthesis tool, it means your tool's output needs to carry that metadata — not just the quote text.
The practical test: can you, at any point during the roadmap review, retrieve the exact transcript segment that generated the quote you're presenting? If the answer is no — if the quote exists only as a sticky note label or a slide bullet — you're citing from memory, not from evidence.
During the Review: How to Present Research Claims
In the meeting itself, the language you use signals whether your evidence will hold up or get dismissed. There's a spectrum, and the position you occupy affects how seriously your citations are taken.
Weak: "Users told us they want better notifications." No source, no scope, no job connection.
Stronger: "In our Q3 discovery round — eight interviews, all enterprise accounts — four participants mentioned notification failures as a factor in missed coordination. Here's a representative quote from P-004: 'I find out about blockers from Slack, not from the product. The product tells me after the fact.'"
Strongest: "That quote maps to Job #3 in our framework — staying ahead of blockers in coordinated work. P-004 is our third participant this quarter to describe that specific pattern. We have two other quotes from different sessions that describe the same job-obstacle. This is our highest-evidence job this quarter."
The third version is defensible under any follow-up question. How many people said this? Three, this quarter, with two more from a previous round. Who are they? P-004 is a senior ops lead at an enterprise account — I can pull the session profile. Is it just a vocal minority? It's five distinct participants across two study rounds, all in the enterprise segment we're targeting.
The Attribution Format That Holds Up
For the quote card you actually put in the review deck, a format that research-credible PMs use consistently looks like this:
- Participant ID (e.g.,
P-004) — not a name, not a company - Session descriptor (e.g., "Q3 discovery, Session 3, Enterprise segment")
- Timestamp or section reference (e.g., "14:32" or "onboarding discussion")
- Verbatim quote, clearly marked as verbatim
- JTBD job tag (e.g., "Job #3 — Staying ahead of blockers")
- Evidence weight (e.g., "3 of 8 participants in this study; 5 across last two rounds")
That last item — evidence weight — is what separates a compelling citation from an anecdote. An anecdote is one person who said an interesting thing. Evidence weight shows that the pattern holds across multiple sessions and isn't being driven by a single articulate participant.
When you run synthesis through GetWhys, this structure is what comes out. Each quote card carries the participant ID, session date, transcript timestamp, JTBD job tag, and a confidence score. The export goes into your roadmap doc formatted for citation — no post-synthesis cleanup required.
After the Review: Maintaining the Evidence Thread
The most common failure mode post-review is that research evidence gets consumed but not archived with decision context. The decision gets made, the roadmap item gets prioritized, the slide deck goes stale, and six months later nobody knows what evidence backed the decision or whether it still holds.
Building a lightweight evidence log addresses this. For each significant roadmap decision, record: the job it maps to, the evidence that supported it (with participant IDs and session references), the date of the decision, and the study round the evidence came from. When the question comes up again — or when a similar question surfaces for a different feature — you can query against real evidence rather than reconstructing from memory.
This is not a significant administrative burden if the synthesis process already produced structured, traceable output. It's a significant burden if synthesis produced an affinity diagram, because you have to reverse-engineer the traceability retroactively.
The Skeptical Stakeholder Problem
Some roadmap reviews have a stakeholder who is constitutionally skeptical of qualitative research. "Eight interviews isn't statistically significant." "You only talked to people who agreed to talk to you." Both observations are true. Neither means the research has no value.
The right response isn't to defensively justify qualitative methods — it's to be honest about what the evidence can and can't support. Eight job-mapped interviews can tell you that a specific obstacle exists and is meaningfully common among a specific segment of your user base. They cannot tell you the exact percentage of users who experience it. They can generate hypotheses for quantitative validation. They can surface the specificity of the problem in ways that survey data rarely can.
We're not saying qualitative research is sufficient on its own for all roadmap decisions. We're saying it's credible evidence when it's properly cited — and that the bar for "properly cited" is a lot higher than "users said they want this." Stakeholders who push back on qualitative research are usually pushing back on weak citation practices, not on the research itself. Give them a quote with a participant ID, a session reference, and a JTBD job mapping, and the conversation changes.