I've sat in a lot of roadmap reviews. At startups, at enterprise companies, at UN working groups planning policy timelines. And I've noticed something: the roadmaps that look the most polished are usually the ones most disconnected from reality.
The color-coded Gantt charts. The quarterly themes with names like "Delight" or "Scale." The slide that shows confident delivery dates for features nobody has actually scoped. These aren't plans. They're performance.
A roadmap should be a *hypothesis*, not a commitment. The moment you treat it as a commitment, you've broken it.
The problem with most roadmaps
Here's how roadmaps usually get built: someone senior says "we need to do X." A PM writes it down. Engineering estimates. Design mocks it up. The item gets a quarter and a color. Everyone nods.
What's missing is the question that should come before all of that: What signal are we responding to?
I've seen teams spend a full quarter building a feature that appeared on the roadmap because a single enterprise customer mentioned it on a sales call 18 months ago. By the time it shipped, that customer had churned. The feature sat unused.
A roadmap item with no signal behind it is a guess. And guesses have a way of surviving a lot longer than they should when nobody has written down why they were added.
The 3 signals that should override any roadmap item
When I audit a roadmap — mine or anyone else's — I look for three types of signal. If a roadmap item can't be traced back to at least one of them, it shouldn't be there.
1. Churn signal
When users leave, they tell you exactly what the product failed to do. Not in exit surveys, which are almost always too late and too polite — but in their behavior. What was the last feature they used before going quiet? What support ticket did they open and never see resolved? What workflow did they start and abandon?
I built a churn dashboard at a previous company that assigned each at-risk account a weekly risk score based on behavioral signals. The top churn predictor wasn't price. It wasn't competition. It was one specific step in the onboarding flow where 34% of users dropped off and never came back. That finding moved a roadmap item from Q4 to Q1 in a single meeting.
2. Friction signal
Friction is the gap between what a user is trying to do and what the product lets them do. It shows up as support tickets, session recordings where users click the same button three times, workarounds people invent that you never intended (a sure sign they needed something you didn't build), and features that exist but have <20% adoption.
When I took a feature from 23% to 61% adoption in six weeks, we didn't build anything new. We removed friction at three specific points in the flow. The roadmap item that drove results wasn't "build better onboarding." It was "remove the confirmation modal on step 2 and add a contextual tooltip at step 4." Specificity is what makes a roadmap item executable.
3. Revenue signal
Not all revenue signal is obvious. The obvious version is "enterprise customer asks for X, and they're worth $2M ARR." Fine — but that's also how you build a product that only works for one customer.
The subtler version: which features correlate with expansion revenue? Which ones correlate with conversion from trial to paid? At a company I worked with, we discovered that users who used a specific reporting feature within their first 14 days converted at 3x the rate of those who didn't. That feature wasn't prominently on the roadmap. After that finding, it was the roadmap.
How to say no to a VP without losing the relationship
Every PM eventually faces the same situation: a senior stakeholder wants something on the roadmap that you know shouldn't be there. They're not wrong to want it — they have business context you might not have. But they also don't have the signal data you do.
The mistake is treating this as a power struggle. It isn't. It's a translation problem.
What they're really saying is: "I believe this will create value, and I don't trust that the roadmap reflects that belief." Your job is to either show them the data that changes their mind, or to understand the belief well enough that you can find a better way to address it.
My default script: *"I want to understand the outcome you're trying to drive. Can you help me see what signal you're seeing that I might be missing? Because if we're getting customer signal that I'm not seeing, I need to know about it."*
This does three things: it shows you take them seriously, it invites them to be specific (which often reveals that the "signal" is actually a gut feeling), and it repositions you as a collaborator rather than a gatekeeper.
If their signal is real and you were missing it, update the roadmap. That's a win. If the signal doesn't hold up under scrutiny, you've now had that conversation with them, not in a review meeting in front of ten people.
What a confident roadmap actually looks like
A confident roadmap is not one that has dates for everything. It's one where every item has:
- →The signal that put it there (1 sentence — churn, friction, or revenue)
- →The hypothesis ("If we do X, we expect Y to change by Z")
- →The owner (one person, not a team)
- →The success metric (not a delivery date — an outcome)
That's it. Four fields. If you can't fill in all four, the item isn't ready to be on the roadmap.
The teams I've seen ship the most consistently aren't the ones with the prettiest roadmap decks. They're the ones who can tell you, without looking anything up, exactly *why* the next item is the next item.
That's the whole game.