Your roadmap is fiction.
Not maliciously — nobody sat down and decided to lie. But trace most line items back to their origin and you'll find a conversation someone half-remembers, a competitor feature nobody validated, or a VP's gut feeling that got repeated until it calcified into "strategy."
Call it what it is: a wishlist with deadlines.
The cost is real. Engineering teams spend months building features that don't move the metrics that matter. The features that would have moved them sit unbuilt in a backlog nobody reads. And every quarter the cycle repeats — new opinions, new politics, same process.
This isn't about adopting a new framework or a prettier template. It's about one discipline: every item on your roadmap should trace to customer evidence, and when it doesn't, you should know that and account for it.
The wishlist antipattern
The most common failure mode in product management isn't building the wrong thing. It's building the right thing for the wrong reason — which means you can't learn from it, reproduce it, or defend it when priorities shift.
Four flavors:
- The HiPPO feature. Highest-paid person's opinion becomes a roadmap item. Nobody asks what customer problem it solves because the question feels political.
- The competitor copy. A competitor ships something, sales panics, and "competitive parity" lands on the roadmap. Nobody checks whether your customers actually want it.
- The squeaky wheel. One enterprise customer threatens to churn. Their request jumps the queue, displacing work that would benefit hundreds of other users.
- The pet project. An engineer or designer has a strong vision. Probably good! But it enters the roadmap without validation, and when it underperforms, the team loses confidence in future bets.
None of these are inherently wrong. Executive intuition is valuable. Competitive awareness matters. Retention is critical. The problem is when these inputs arrive without evidence and leave without scrutiny.
Why evidence changes the game
Ship a feature backed by clear evidence — interview quotes, usage data, support ticket patterns — and one of two things happens. Either it works and you understand why, or it doesn't and you understand why. Both outcomes are valuable because they update your model of the customer.
Ship a feature backed by intuition alone? Neither outcome teaches you much. Success feels like vindication but offers no transferable insight. Failure feels like bad luck.
This is the core argument for evidence-driven roadmaps: they're not just more accurate, they're more learnable. Every bet becomes a testable hypothesis. Over time, your product org gets better at predicting what will work — not because people get smarter, but because the system accumulates evidence.
The numbers aren't great for intuition either. Research consistently shows 60-80% of features ship with low or no measurable impact on the metrics they targeted. Most weren't bad ideas. They were untested ideas that happened to be wrong.
How to audit your roadmap (2 hours, one-time)
You don't need to throw out your roadmap. You need to audit it.
Step 1: List every committed item
Everything planned for the next two quarters. Large bets, small improvements, tech debt, experiments. Flat list — don't group by theme or team. Grouping hides the volume.
Step 2: Tag each item with its evidence source
For every item, ask: what customer evidence supports this?
- Direct evidence. Interview quotes, survey responses, support tickets where customers describe the problem. You can point to specific humans who said specific things.
- Behavioral evidence. Usage analytics show a pattern — funnel drop-off, feature underuse, correlation with retention.
- Inferred evidence. Reasonable hypothesis, no direct signal. Customers ask for something adjacent, or churn surveys mention a related theme.
- No evidence. Someone important wanted it, a competitor has it, or the team believes it's right. Nothing wrong with this — but name it.
Step 3: Count the distribution
Most teams find 40-60% of roadmap items fall into "inferred" or "no evidence." This isn't failure — it's a baseline. The goal isn't 100% direct evidence. The goal is honesty about where you're making informed bets and where you're guessing.
Step 4: Apply the evidence tax
Every "no evidence" item gets a task: gather evidence before committing engineering resources. Not blocking the work — just running lightweight validation. Five customer conversations. A usage data pull. A prototype test. Before you invest a full sprint.
The reframe: from "should we build this?" to "what would we need to believe for this to be worth building?" That question is almost always answerable in a week.
Step 5: Re-stack based on evidence strength
Items with strong evidence rank above items with weak evidence, all else equal. When two items have similar expected impact, the one with better evidence is the better bet — not because it's guaranteed to work, but because you'll learn more from shipping it.
For how to turn raw customer conversations into usable evidence, see synthesizing customer interviews.
Building a continuous evidence loop
Auditing once is useful. Building a system that continuously feeds evidence into prioritization is transformative.
One evidence repository
Customer evidence lives in six places at most companies: CRM call notes, Zendesk tickets, Google Drive recordings, Typeform surveys, Amplitude dashboards, Slack threads. No single person can synthesize across all of them.
You need one place where evidence is collected, tagged, and searchable. Notion, Airtable, a spreadsheet — the tool matters less than the discipline. Capture three things for every piece of evidence: source (who or where), signal (what problem it reveals), strength (how many independent times you've seen it).
Tools like Mimir automate this — ingesting evidence from multiple sources and surfacing patterns across them — but the principle works regardless.
Monthly evidence review (45 minutes)
Gather PM, eng lead, designer, and someone customer-facing. Three agenda items:
- New signals. What problems surfaced or strengthened since last month?
- Roadmap check. Do current priorities still align with the strongest signals?
- Evidence gaps. Which high-priority items still lack strong evidence? What can we do in two weeks to close the gap?
If this takes longer than 45 minutes, your evidence isn't organized well enough.
Score with evidence weight
Add evidence strength as an explicit dimension alongside impact and effort:
- 3 — Strong. Multiple independent sources, both qualitative and quantitative signal.
- 2 — Moderate. Some signal but thin — a few mentions, one data point, inference.
- 1 — Weak or none. You believe it's important but can't point to specific evidence.
Multiply impact by evidence score. A high-impact feature with strong evidence beats a high-impact feature with no evidence, because the first estimate is grounded and the second is a guess. The evidence-based prioritization guide covers scoring models in more depth.
Close the loop after shipping
The most neglected step. After every launch, ask:
- Did it work? Check the metric it was supposed to move. "Usage is up" is not the same as "it solved the identified problem."
- Was our evidence predictive? Did strong-evidence features outperform weak-evidence ones?
Track this for a few quarters. You'll learn which types of evidence are most predictive for your product. That meta-learning is worth more than any individual feature decision.
The compounding advantage
Teams that build this discipline gain a compounding edge. Each quarter, the evidence base grows. Prediction accuracy improves. Confidence in saying "no" to low-evidence requests increases.
The wishlist roadmap doesn't compound. It resets every quarter — fresh opinions, fresh politics, same guess-and-check cycle. The organization doesn't get smarter because there's nothing to learn from.
Start with the audit. Tag your roadmap items. Run one monthly evidence review. Score your next prioritization with evidence weight. Small changes, large downstream effects.
Your roadmap should be your strongest artifact — where customer reality meets engineering capacity meets business strategy. For most teams, it's the weakest. Fix the evidence gap and everything downstream improves.