A roadmap is not a plan. It's a commitment dressed up as one. And the difference matters more than most product teams are willing to admit.
I've seen roadmaps that stretch 18 months into the future, colour-coded by quarter, complete with feature names and delivery dates. They look authoritative. They look like evidence of rigour. They are, almost always, fiction — and expensive fiction at that.
The problem with date-based roadmaps
The core issue isn't that teams can't predict the future. It's that date-based roadmaps create the illusion that they can — and then everyone builds decisions on top of that illusion.
Sales promises Q3 delivery to close a deal. Engineering signs off on a timeline before the problem is properly understood. Leadership treats the roadmap as a contract rather than a hypothesis. And when reality diverges from the plan — which it always does — the question becomes "why are we behind?" rather than "what did we learn?"
The roadmap has reframed the work. Instead of asking whether we're building the right things, we're asking whether we're building things fast enough. That's the wrong question.
Why stakeholders want them anyway
Stakeholders ask for roadmaps because they want certainty. They want to know what's coming, when it's arriving, and how to plan around it. That's a reasonable need.
The mistake is confusing the need for certainty with the ability to provide it. When product teams produce a 12-month roadmap to satisfy that need, they're not reducing uncertainty — they're hiding it. The uncertainty is still there. It's just been given a spreadsheet and a set of dates.
The right response to "when will this be done?" is often "we don't know yet, and here's what we need to learn before we can say." That's harder to say. It's also more honest, and ultimately more useful.
Roadmaps vs. strategy
A roadmap answers "what are we building?" A strategy answers "why, and in what order, and what are we not building." Most teams have roadmaps. Far fewer have strategies.
Strategy is about choosing. It's about saying: given our position, our constraints, and our goals, here's where we're placing our bets and why. A good strategy makes the roadmap obvious — or at least defensible. A bad strategy makes the roadmap arbitrary, which is why so many roadmaps feel like a random collection of things people asked for.
If you can't explain why item three is above item four in terms of user outcomes and business impact, you don't have a strategy. You have a backlog with dates attached.
What actually works
Outcome-based planning with shorter horizons. Instead of "ship feature X in Q2," you say "increase activation by 15% in the next 6 weeks." The outcome is the commitment. The method is a hypothesis.
This approach forces clarity about what success looks like before you've decided how to achieve it. It creates space to learn and adapt without the roadmap becoming a liability. And it makes it easier to have honest conversations with stakeholders — because you're not defending a schedule, you're reporting on progress toward an outcome.
The horizon matters too. Six weeks is meaningful. Twelve months is speculation. Build with enough confidence to act, and enough humility to change course.
None of this means abandoning planning. It means planning honestly — acknowledging what you know, what you don't, and what you're going to do next to close that gap. That's harder than a Gantt chart. It's also how good products get built.