Over the years, I’ve had countless conversations about product strategy and direction. One topic that always comes up is the product roadmap. It’s a tool that’s become so ingrained in how teams communicate that it’s treated as an unquestioned necessity — a tick-box exercise that stakeholders expect, even demand. But here’s my honest confession: I hate product roadmaps.
Not because I don’t like planning, or because I don’t believe in transparency, but because traditional product roadmaps often do more harm than good. They create illusions, mislead teams, and set false expectations. Today, I want to break down why I think product roadmaps fail us, and what we might do instead.
The Illusion of Certainty
A roadmap, by its very nature, projects certainty into the future. Features are laid out against neat timelines, implying that we know exactly what we’ll be working on six, twelve, or even twenty-four months from now. We’ve all seen those visuals: the four-quater sudo-gannt chart, the now-next-later horizon view and the one I personally love to hate the skeuomorphic roadmap with the image of an actual road.
The problem is, we don’t know exactly what we’ll be working on and we never really can.
Markets shift, customer needs evolve, technology changes, competitors surprise us, and sometimes our own experiments take us in unexpected directions. The reality of product development is one of constant learning and adaptation. Yet roadmaps suggest the opposite: that we’ve already figured out the path and just need to follow it.
This creates two major problems:
-
For teams: Developers and product managers are forced into delivering against an outdated plan, even when data tells them to pivot.
-
For stakeholders: Executives and customers start treating roadmap items as commitments. In the best case, if you deliver something early then it looks like you don’t have control unless you decide to hold it back for the arbitary release deadline. In the worst case things slip, leading to disappointment.
Some product teams adopt the “now-next-later” pattern to avoid some of these committment pitfalls, but this also has it’s own challenges because these become buckets of ideas with no context, no dependencies and no committment to ever deliver.
Instead of pretending we can predict the future, we should acknowledge that we are in a cycle of discovery and delivery. Transparency doesn’t have to come from false promises of timelines, but from honest communication about our priorities and how they’re evolving.
Features Over Outcomes
Another issue with roadmaps is that they almost always prioritise new product or new product features over outcomes. A roadmap is a list: build this, add that new elemenent to the support matrix, roll out the shiny new dashboard by Q3. But features aren’t the end goal. They’re just the means to achieve something bigger — happier customers, reduced churn, improved efficiency, higher revenue.
By reducing product portfolio vision to a checklist of new products and features, we fall into the trap of delivery for the sake of delivery. We create more noise than value. And worst of all, we confuse progress with output rather than impact.
This feature-first mindset can demoralise teams too. Engineers don’t want to just tick boxes; they want to solve real problems. And when the measure of success is “did we deliver what’s on the roadmap?” rather than “did we make life better for our users?”, everyone loses.
The alternative? Anchor discussions not on features, but on problems and outcomes. Instead of saying: “We’ll deliver the dashboard by Q3”, say: “We’ll reduce the time it takes for users to discover X insight by 50%.” This reframing empowers teams to experiment, adapt, and innovate — while giving stakeholders a much clearer picture of the value being delivered.
The Death of Flexibility
Perhaps the most frustrating thing about roadmaps is how rigid they become. Once you’ve published one, it takes on a life of its own. Updates become political. Changes are seen as failures and waste rather than reflections of learning. Things are added based upon opinion or PM influence Before long, teams stop challenging the roadmap altogether and simply march along the path, regardless of whether it still makes sense.
This rigidity is the exact opposite of what agile product development is supposed to be. Agility is about responding to change, embracing uncertainty, and continuously iterating. A static roadmap undermines that philosophy, turning product development into a treadmill of obligations.
To be clear, I’m not advocating for chaos. We do need direction. But there’s a difference between direction and destination. Roadmaps lock us into destinations, while what we really need is a compass — something that points us towards where we want to go, without pretending that the route is fixed.
So What’s the Alternative?
It’s easy to complain about roadmaps; it’s harder to suggest what to do instead. Here are a few approaches that I’ve found healthier and more honest:
1. Theme-Driven Roadmaps
Instead of listing features and dates, group your work into themes tied to business or customer outcomes. For example:
- Improving onboarding experience
- Increasing reliability at scale
- Expanding into new markets
Themes communicate intent without boxing teams into specific solutions. They also help stakeholders see the bigger picture, rather than obsessing over a single feature release.
2. Outcome-Based Planning (Business and Customer)
Anchor your plans on the impact you want to achieve — but make sure to distinguish between business outcomes and customer outcomes.
Business outcomes are the things the organisation cares about: reduced churn, increased revenue, improved operational efficiency.
Customer outcomes are the things that matter directly to users: saving time, feeling more confident, reducing frustration, achieving their goals more easily.
Both are essential. The trap roadmaps fall into is treating outcomes as just another form of prioritisation — essentially a business-only checklist. What’s more powerful is to use outcomes as a way of framing intent rather than locking in commitments. For example:
Business framing: “We want to reduce churn by 10%.”
Customer framing: “We want to help users understand their data in under two minutes.”
When combined, these give clarity on the why — for the organisation and for the customer — and empower teams to decide the how.
3. Rolling Priorities
Alongside outcomes, one of the most powerful things we can do is explain the why behind decisions. Too often teams share the what (features) or the when (timelines) without giving context. Explaining the why — whether it’s rooted in customer pain points, market shifts, or strategic bets — creates understanding rather than blind compliance.
When stakeholders and teams know why a direction was chosen, they are more likely to stay aligned even if the exact path changes. The why acts as a north star: it frames purpose and intent, and it reduces friction when plans evolve.
Instead of treating plans as a queue of outputs, we should use roadmaps as a narrative tool — a way of telling the story of where we’re heading and why. This narrative doesn’t need to be broken into artificial buckets of “now, next, later.” It can instead focus on direction, intent, and dependencies, with the flexibility to adapt as learning emerges.
Closing Thoughts
I know that some people will say: “But roadmaps are what executives and customers expect.” And they’re not wrong. There’s a comfort in seeing a plan neatly laid out, even if it’s an illusion. But comfort is not the same as clarity, and illusion is not the same as truth.
Product development is complex, messy, and full of surprises. We don’t need roadmaps that promise certainty we can’t deliver. We need frameworks that give us direction while leaving space for discovery. We need to be transparent not just about what we’re doing, but about what we don’t know yet.
So yes, I hate product roadmaps. But not because I hate planning. I hate them because we can do better — for our teams, for our stakeholders, and most importantly, for our customers.