The Roadmap Trap
The most detailed planning artefact in the organisation is often the one doing the most damage to its strategy. And the people who build it sense this, somewhere.
There’s a particular slide I’ve seen in dozens of quarterly roadmap reviews. It has swimlanes, usually four or five, colour-coded by team or theme. There are little diamond milestones scattered along a timeline that stretches confidently into Q3 and Q4. The features are named precisely. The sequencing looks deliberate. And the PM presenting it is doing so with the kind of calm authority that would be impressive if anyone in the room actually believed what was on the screen.
I’ve sat in those rooms many times now, and what I’ve noticed is that the room performs a kind of collective agreement that I’ve come to think of as the roadmap contract. The CEO nods because the slide gives them something to show the board. The VP of Sales is already mentally packaging two of those Q3 items into a customer pitch. Engineering is running quiet mental arithmetic on how wrong the estimates are, but they won’t say so, because last time someone questioned a timeline in this meeting it didn’t go well. And the PM, who built this thing over the course of a week, pulling in estimates from engineers who were guessing and priorities from stakeholders who were lobbying, presents it as though it represents a strategic plan. What it actually represents is the output of a negotiation. Nobody will look at this slide again until the next quarterly review, when the whole performance will repeat with new dates and many of the same features shuffled into different quarters.
I understand why organisations demand detailed roadmaps. More than understand, actually, I’ve been the person demanding them. If you’re a CEO reporting to a board, “we’re running discovery on three hypotheses and we’ll know more in six weeks” is a sentence that doesn’t survive the boardroom. Boards want predictability. Sales needs delivery windows to close deals. Engineering needs to plan capacity and hiring. Cross-functional teams need sequencing so they can coordinate launches and marketing and support documentation. The detailed roadmap answers all of those needs at once, and if you’ve ever been the product leader who stood in front of a board and said “we’re not sure what we’ll build in Q4,” you know how badly that lands. The demand for a detailed roadmap isn’t irrational. It’s a rational response to organisational anxiety. And I don’t think the people who ask for it are wrong to want it. The problem isn’t the want. It’s what the roadmap actually delivers versus what everyone believes it delivers.
The thing is, I’m not sure the detailed roadmap does what people think it does. What it resolves isn’t the uncertainty about the product’s future. The uncertainty remains exactly where it was. What the roadmap resolves is the feeling of uncertainty, the organisational discomfort of not knowing what’s coming next. And those two things, the actual uncertainty and the felt uncertainty, are much further apart than most leadership teams realise. Daniel Kahneman’s planning fallacy research demonstrated this decades ago: the act of creating a plan generates confidence in the plan regardless of the plan’s accuracy. When students were asked to give 99% confidence intervals for how long their thesis would take, only 45% finished within those intervals. The plan didn’t make the outcome more predictable. It made the planners feel more confident about an outcome that was just as unpredictable as before. I think most detailed roadmaps are doing something very similar. They’re not reducing risk. They’re reducing the feeling of risk. And those are very different services.
I should back up though because I have a specific experience that made this real for me in a way that the research alone wouldn’t have. A few years ago I was leading product for a business that had always operated with detailed twelve-month roadmaps. It was cultural, almost liturgical. Every quarter the roadmaps would be assembled, presented, debated, adjusted, and then quietly filed away while people got on with whatever actually needed doing. The roadmap and the work existed in parallel but largely independent tracks, like two conversations about the same company that rarely acknowledged each other.
I didn’t set out to challenge this. What happened was simpler. We hit a quarter where three of the four major roadmap items turned out to be wrong. Not wrong in the sense that we couldn’t build them, but wrong in the sense that by the time we got to them, the market had shifted enough that they were no longer the right things to build. A competitor had launched something that made two of our assumptions obsolete overnight. A key customer segment had started asking for something we hadn’t anticipated. And one of the items had been on the roadmap for two quarters already, surviving each review through a kind of institutional momentum where nobody wanted to be the person who killed it.
What I noticed, and this is the part that stayed with me, is that the roadmap had actually made us slower to respond, not faster. Because the roadmap existed, because it had been presented and agreed and committed to, changing direction felt like failure rather than intelligence. The sunk cost wasn’t just the engineering time already invested. It was the organisational credibility that had been attached to the plan. To say “we’re not doing this anymore” meant admitting the plan was wrong, and that created a political cost that was separate from, and often larger than, the strategic cost of continuing down the wrong path.
Barry Staw published research on this in 1976 that still holds up uncomfortably well. Once plans are made public, people continue pursuing them even as evidence mounts that they’re wrong. He called it escalation of commitment. The very act that makes a roadmap feel useful, sharing it widely so everyone can align around it, is the act that removes your ability to change it without consequence. The roadmap becomes a commitment the moment it’s shared. And once it’s a commitment, it stops being a tool for thinking and starts being a thing you’re defending.
Which brings me to what I actually mean when I say the detailed roadmap is a trap. The roadmap isn’t bad in itself. Some form of communicating product direction is obviously necessary, and I’m not naive enough to pretend otherwise. The trap is what happens when the roadmap becomes the primary artefact of product strategy rather than a downstream expression of it. When you pour that much organisational energy into specifying what you’re going to build and when, something gets displaced. The conversations about why you’re building it, about what problem it solves, about whether the problem is still the right problem, those conversations get thinner because the roadmap has already answered them. Or rather, the roadmap has made the question feel already answered, which isn’t the same thing at all. Goodhart’s Law tends to get quoted in metrics conversations and not applied where it might matter most. When a measure becomes a target, it ceases to be a good measure. When roadmap adherence becomes how product teams are evaluated, teams optimise for shipping what was planned over solving what matters. You end up with organisations that hit their roadmap commitments and miss their market.
The companies that seem to have figured this out, or at least figured out something different, all did something counterintuitive: they deliberately separated the question of what they’re trying to achieve from the question of what specifically they’re going to build. Basecamp has operated for over twenty years without a traditional roadmap. Their position is almost comically direct: “No matter how you try to hedge it, a roadmap communicates a plan, a series of commitments, to other people.” Instead, every product idea is an option they might exercise in their next six-week cycle, or might never exercise at all. They don’t plan the next six cycles. They plan one. Spotify discovered early on that high delivery velocity just meant building the wrong things faster, which led them to decouple their planning from fixed timelines entirely. Amazon’s Working Backwards process starts from the customer problem and works toward whatever solution fits, which might not be anything anyone would have put on a roadmap six months ago. None of these organisations lack direction. They just don’t confuse direction with a detailed delivery schedule.
The ProductPlan 2024 State of Product Management report found something that confirmed what I’ve suspected for years. 76% of product managers said product strategy was essential. 58% said roadmapping was essential. But 31% said their roadmap was primarily influenced by senior leadership rather than customer evidence. And product managers reported dramatically lower confidence when roadmap items came from executives rather than from discovery. There’s something telling in that gap. The very people building the roadmap know that a meaningful portion of it isn’t grounded in evidence. They know, and they build it anyway, because the organisation requires the artefact regardless of what’s inside it.
Rich Mironov, whose writing on product leadership I consistently find the most honest in the field, has a line about sales-driven development that applies equally well here. He calls sales one-offs “crack cocaine: pleasure-inducing, habit-forming, and generating barely-plausible explanations of why every deal is the last one we’ll do custom work for.” Roadmap commitments work the same way. Each one feels reasonable in isolation. The cumulative effect is a product organisation that has committed its way out of the capacity to think strategically, because every quarter is already spoken for before anyone has asked whether the right questions are even being addressed.
I should be clear, though, because I’m not arguing that roadmaps are inherently harmful. I’ve worked in businesses where a clear, time-bound roadmap was genuinely necessary, where the regulatory environment or the contractual obligations or the market dynamics made it irresponsible not to have one. The trap isn’t the roadmap itself. It’s when the roadmap is filling a strategy gap rather than expressing a strategy. When the CEO demands a detailed twelve-month plan not because the business requires that level of specificity, but because they haven’t articulated a clear enough strategic direction for teams to operate without one. In those organisations, the roadmap isn’t downstream of strategy. It’s a substitute for it.
The irony, and I think about this more often than is probably healthy, is that the organisations demanding the most detailed roadmaps are usually the ones with the least clear strategy. If you had a strategy that was specific enough to guide decisions, the roadmap would be short. It would say: here’s the problem we’re solving, here’s the bet we’re making, here’s what we’re building first and here’s why. Instead, what you get is a long roadmap, every swimlane full, every quarter spoken for, because nobody has done the harder work of deciding what not to do. I’ve started to notice that the longer the roadmap, the less strategic thinking has actually happened. More detail usually means fewer hard decisions were made, not more.
I don’t think this changes overnight. The organisational anxiety that drives the demand for detailed roadmaps is deep, and it’s reinforced by every board meeting, every investor update, every sales review where someone asks “when is feature X shipping.” But I do think it’s worth naming what the detailed roadmap actually costs, not in theory but in the specific, recognisable ways it plays out. There’s the pivot you didn’t make because Q3 was already committed. The discovery work that got squeezed out because the team was delivering roadmap items nobody had validated since they were first proposed. A strategic bet you never placed because it couldn’t be expressed as a feature with a timeline and a milestone. And then there’s the thing I keep coming back to, which is the conversation you didn’t have. The one where someone in the room says “I don’t think this is the right thing to build” and everyone takes that seriously instead of pointing at the slide and saying it’s already been decided.
Reference links:
Why Product Roadmaps Are Destroying Strategic Thinking — ProductArt Substack
Bridging the Gap Between Marty Cagan and Reality — SeventyOne Consulting
Six Common Traps That Undermine Strategic Product Management — Matt LeMay, Mind the Product