We spend hours crafting them, only to watch them turn stale in weeks. It’s time to have an honest conversation about the roadmap problem.
Dear product leads , how many hours have you spent agonizing over your product roadmap, only to watch it become obsolete before the quarter was even over? You’re not alone, and you’re probably not the problem. The format is.
Inspired by conversations with PMs across the tech community and a re-read of Eric Leach’s sharp provocation „Why I Hate Roadmaps“, I want to dig into a topic that remains as hot as ever: the product roadmap. Not to bury it, but to challenge the way most of us use it.
First, let’s define what we’re actually talking about
A product roadmap is typically a visual document outlining the planned development of a product over a given period, often 6 to 18 months, sometimes more. In its classic form it includes:
- A timeline with specific dates or horizons (quarters, annual planning increments, PI cycles)
- Key milestones: launches, major updates, architectural shifts
- Features or projects, colour-coded by theme or strategic objective
The intention is legitimate: align teams, communicate with stakeholders, give the organisation a sense of direction. The problem is the gap between that intention and what roadmaps actually deliver in practice especially in fast-moving tech environments where the ground shifts faster than a planning cycle.
The mirage of predictability 🌵
The deepest flaw of traditional roadmaps is their implicit claim to predictability. By committing to specific features at specific dates, they encourage a fiction: that we know today what will matter six months from now. We don’t. Markets shift. Users surprise us. Competitors move. Technologies change. And yet we present Gantt charts as though we have a crystal ball.
Melissa Perri — Escaping the Build Trap (O’Reilly, 2018)
Perri describes the „build trap“ as the dangerous tendency to equate output with progress — shipping features without measuring their actual impact. Traditional roadmaps, she argues, are the structural enabler of this trap: they reward delivery velocity over outcome quality.
Marty Cagan — INSPIRED: How to Create Tech Products Customers Love (Wiley, 2nd ed.)
Cagan’s central argument is unambiguous: the best product teams organise around outcomes, not features. A roadmap full of features to ship is the opposite of an outcome-based strategy it is, in his words, a „commitment to a particular solution before you understand the problem.“
„Fixed roadmaps communicate false certainty.“— Teresa Torres, Continuous Discovery Habits
The damage isn’t just strategic. Stale roadmaps erode trust. When stakeholders see a roadmap item get dropped, moved, or quietly deprioritised for the third consecutive quarter, they stop believing in the plan — and they stop believing in the team that made it.
Adaptability is the real superpower 🦸
Whether you’re in a hypergrowth startup, a scaling scaleup, or a mid-market company navigating a volatile global market, the capacity to pivot quickly is a genuine competitive advantage. A rigid roadmap undermines that capacity by creating switching costs — political, psychological, and operational — every time priorities need to shift.
So what replaces it? A few models have proven themselves in practice:
Shape Up — Basecamp
Ryan Singer’s Shape Up (available free at basecamp.com) proposes 6-week cycles with no long-term roadmap. Teams work on shaped bets — scoped problems with defined appetite — and every cycle is a fresh prioritisation conversation. The absence of a long roadmap isn’t a weakness; it’s the whole point. It forces honest trade-off decisions instead of letting the roadmap make them by inertia.
The Now / Next / Later format
Pioneered by Janna Bastow (ProdPad) and popularised by Teresa Torres, the Now-Next-Later roadmap replaces fixed dates with outcome-oriented horizons. „Now“ is committed work in progress. „Next“ signals the upcoming problem space — not a solution. „Later“ is a hypothesis about future opportunity. This format gives sales and stakeholders enough visibility while preserving the team’s ability to adapt.
The „Bets“ model at Spotify
Spotify replaced traditional roadmaps with a system of seasonal „bets“ — time-boxed experiments aligned with company strategy. Each squad proposes bets tied to strategic objectives; leadership reviews and allocates resources collectively; squads then execute with full autonomy for a „season“ (roughly two quarters). At the end of each season, results are reviewed and the cycle resets. This connects top-down strategy with bottom-up innovation, while building in accountability without micromanagement.
The GIST framework — Itamar Gilad : Goals · Ideas · Steps · Tasks
Former Google product lead Itamar Gilad developed the GIST framework as a direct replacement for feature roadmaps. In his book Evidence-Guided: Creating High-Impact Products in the Face of Uncertainty (2022), he argues that most planning tools fail because they skip from goals straight to tasks bypassing the critical work of generating and validating ideas.
- Goals — What outcome are we trying to achieve? (Measurable, time-bound)
- Ideas — What hypotheses might get us there? (Many, not one)
- Steps — What experiments validate those ideas at low cost?
- Tasks — What execution work follows once confidence is high enough?
His Confidence Meter adds a layer of epistemic honesty: every idea carries an explicit confidence score, forcing teams to articulate what they know versus what they’re assuming.
This replaces the fake certainty of a dated roadmap with structured, transparent uncertainty.
So… should we just kill the roadmap? 🗣️
Not exactly. The real problem isn’t the roadmap as a concept — it’s the roadmap as a single artefact serving every audience at once. A document that needs to reassure a board, align an engineering team, and enable a sales conversation simultaneously will serve none of them well.
John Cutler, writing in his newsletter The Beautiful Mess, has consistently argued for audience-specific communication tools rather than a universal roadmap. His point: the format should follow the communication need, not the other way around.
Different audiences need different things:
- Leadership and investors need to see how product investments map to strategic goals and KPIs — an objectives timeline or OKR tree, not a feature list.
- Sales and marketing need enough forward visibility to plan campaigns and set customer expectations — a Now-Next-Later with themes, not dates.
- Engineering and design need clarity on the immediate problem to solve and the success criteria — a shaped brief or opportunity framing, not a Gantt chart.
- External customers need to trust that you understand their needs and have a credible direction — a vision narrative and recent learning, not a promise about Q4.
„When I joined as Lead, I replaced our roadmap with a physical and virtual ‚Product Wall‘ — our long-term vision, quarterly goals, and current experiments all visible together. The feedback was unanimous: more transparency, better strategic conversations, and a genuine culture of experimentation.“— Sarah, Product Lead
The importance of continuous learning 📚
What traditional roadmaps systematically crowd out is the most important part of product work: learning from users. When the roadmap is full and the next 12 months are „planned,“ there is no structural space for discovery — only delivery.
Teresa Torres’s Continuous Discovery Habits (2021) remains the sharpest framework for fixing this. Her argument is that discovery shouldn’t be a phase, a sprint, or a quarterly initiative it should be a weekly practice embedded in the team’s rhythm. The Opportunity Solution Tree gives teams a visual way to map the problem space before converging on solutions, making the discovery work transparent to stakeholders rather than hidden behind a feature list.
A word of caution: „dual-track“ models that run Discovery and Delivery as separate parallel tracks can recreate the same handoff problems as waterfall if done badly. Discovery findings need to feed directly into delivery decisions — not land in a backlog to be „picked up“ six weeks later by a team that wasn’t in the room. Continuous discovery is integrated, not parallel.
So how do we actually get out of this? 🧐
Here are practices that have been validated in the field — not as a prescriptive checklist, but as a repertoire to draw from based on your context:
- Switch to outcome-based roadmaps Organise your roadmap around the outcomes you want to achieve for users and the business — not the features you plan to ship. „Increase first-week retention“ is a roadmap item. „Launch onboarding V2“ is not.
- Adopt OKRs as your planning backbone OKRs (Objectives and Key Results) give teams a shared definition of success that transcends any specific feature. When priorities shift mid-quarter, the OKR holds — only the approach changes. This is how you maintain strategic alignment without brittleness.
- Replace your feature backlog with an opportunity backlog A backlog of features is a backlog of solutions in search of problems. An opportunity backlog — borrowing from Torres’s Opportunity Solution Tree — keeps the team anchored to user needs rather than pre-committed implementations.
- Build in regular strategy reviews Schedule explicit moments — monthly, or at the end of each cycle — to re-examine assumptions. Not to rewrite the roadmap from scratch, but to ask: what have we learned, and does it change our next move?
- Add learning milestones alongside delivery milestones „We will have validated our riskiest assumption about user behaviour by week 4“ is a milestone. Make learning visible in your planning, not something that happens in the margins.
- Practise assumption mapping Before committing to a solution, surface and rank your team’s most critical assumptions. Which ones, if wrong, would invalidate the whole approach? Test those first. This is especially powerful in combination with Gilad’s Confidence Meter.
- Make failure a first-class citizen Run „Fail Confs“ — sessions where teams share what didn’t work and what they learned from it. Celebrating instructive failures normalises the kind of fast experimentation that makes outcome-based roadmaps actually work. A team that can’t admit a bet didn’t pay off will quietly pad their roadmap with safe features instead.
The goal isn’t to abolish structure, it’s to make structure serve learning rather than replace it. The best product teams aren’t the ones with the most beautiful roadmap. They’re the ones who know what they’re trying to achieve, who they’re achieving it for, and how they’ll know when they’ve got there.
The roadmap is a communication tool. Treat it as one.
Originally published in French on LinkedIn, July 2024. Expanded and updated in English, 2025.
References: Melissa Perri, Escaping the Build Trap · Marty Cagan, INSPIRED · Teresa Torres, Continuous Discovery Habits · Ryan Singer, Shape Up · Itamar Gilad, Evidence-Guided · John Cutler, The Beautiful Mess
