It's Thursday afternoon. The leadership team is in a conference room with sticky notes, a whiteboard, and ambitious intentions. By hour three, you've mapped out Q3 and Q4. Features, milestones, dependencies, all colour-coded.
Six weeks later, you're looking at last quarter's roadmap for the first time since you made it. You don't remember what half the items were supposed to mean. The ones you do remember didn't happen. You close the tab.
Everyone in that planning session knew this would happen. The CEO knew. The CTO knew. The product managers definitely knew. But no one said it out loud, because the roadmap was never really a plan. It was a ritual. A way to create the feeling of control without actually having it.
The problem isn't execution. The problem is that detailed long-range roadmaps are institutionalised fiction. And the longer the range, the more fictional they become.
Why we keep writing roadmaps nobody believes
Roadmaps persist because they solve real problems. Just not the ones they claim to solve.
Stakeholder appeasement. Investors want "visibility." Boards want to see a plan. Enterprise customers want to know when Feature X is coming before they sign. A 12-month roadmap is the easiest answer to "what are you building?" even when the honest answer is "we'll know more in six weeks."
Psychological comfort. Uncertainty is painful. A detailed roadmap makes the future feel manageable. Writing down "Q4: Launch marketplace" creates the sensation of having decided something, even though you've committed to nothing except the words on a slide.
CYA culture. If it's on the roadmap, someone committed to it. When it slips, there's a document to point at. Roadmaps become accountability theatre: artefacts that let everyone claim alignment while protecting no one from actually being held accountable for outcomes.
The planning-industrial complex. There's an entire ecosystem that profits from elaborate planning: tools, frameworks, consultants, offsites. Jira timelines. Aha! roadmaps. Quarterly OKR workshops. Every layer of sophistication sells the promise that this time the plan will hold.
These forces reinforce each other. Stakeholders demand visibility, so you build roadmaps. Roadmaps create the illusion of certainty, so people get comfortable. Comfort breeds process. Process breeds consultants. And no one questions the roadmap because everyone's job depends on pretending it's real.
The roadmap isn't a plan. It's organisational anxiety, crystallised into a spreadsheet.
The hidden cost of fiction
If roadmaps were just harmless theatre, you could ignore them. But fiction has costs.
Time burned. A 50-person engineering org spending one week per quarter on planning ceremonies (roadmap creation, alignment meetings, dependency mapping, stakeholder reviews) burns 200 person-days per year. That's nearly a full engineer-year spent on documents that will be obsolete within weeks.
Opportunity cost. Every hour spent debating Q4 priorities in July is an hour not spent shipping Q3. While you're planning what you might build in six months, a competitor is releasing what they built last month.
Planning feels productive. Shipping is productive.
Trust erosion. When the roadmap says "Q3: New onboarding flow" and Q3 comes and goes without it, people notice. Do this enough times and roadmap announcements become background noise. I've watched engineering teams openly laugh when leadership presents "this quarter's priorities", not because they're cynical by nature, but because they've been burned too many times. "We're prioritising X" starts to mean "we're saying we're prioritising X."
Decision paralysis. The roadmap becomes a weapon against action. "We can't do that, it's not on the roadmap." "Let's add it to next quarter's planning." The document designed to enable decisions starts blocking them. Obvious wins get deferred because they weren't predicted six months ago.
Meta-work. The more detailed your roadmap, the more work goes into maintaining it. Dependencies get tracked. Gantt charts get updated. Status meetings get scheduled. When reality diverges from the plan (and it will) you now have two jobs: handling the actual change, and updating all the roadmap artefacts. The plan becomes its own project, staffed by people who could be building the product.
The cruelest cost is invisible: the good ideas that never got tried because they weren't on a slide deck created before anyone knew they were possible.
What actually works
The answer isn't "no planning." It's planning at the right altitude.
The 6-week horizon. Plan in detail only what you can actually see. Six weeks is far enough to coordinate meaningful work, close enough that your predictions might actually hold. Beyond that horizon, stay directional. "We're going after enterprise customers" is useful. "Q4: SSO, SAML, audit logs, role-based permissions" is fiction.
Bets, not feature lists. A roadmap full of features assumes you know the solution before you've understood the problem. Instead, frame your direction as bets: "We believe improving onboarding will increase activation by 20%." That's testable. "Build new onboarding flow" is just a task. Bets give you permission to change course when you learn something. Feature lists lock you into outputs regardless of outcomes.
Weekly reprioritisation. Treat your backlog as alive. Every week, look at what you learned and ask: "Given what we know now, is this still the most important thing?"
This isn't thrashing. It's steering.
A ship that adjusts course by one degree every day stays on target. A ship that "locks in the plan" and checks course once a quarter ends up somewhere else entirely.
Kill the roadmap deck. Replace your quarterly roadmap presentation with a one-page document that answers three questions: What are we working on right now? Why does it matter? What's the next decision point? Update it weekly. Anyone in the company should be able to read it in two minutes and understand where you're headed. If your "roadmap" can't fit on one page, it's not a communication tool. It's a filing cabinet.
The first six weeks
An 80-person B2B SaaS company I worked with had run 12-month roadmaps for years. Annual planning consumed six weeks. Quarterly "adjustments" took another week each. Features regularly shipped 2-3 quarters late, and by the time they launched, market conditions had changed. The CTO knew the roadmap was fiction. So did the engineering leads. But no one had an alternative.
We replaced the entire system in one week. Not without resistance: two engineering leads thought we were abandoning structure for chaos. But the CTO was willing to run the experiment. Here's what we built.
The weekly prioritisation meeting. Every Wednesday, 30 minutes. The CTO, three engineering leads, head of product, and one rotating engineer from each team. One question on the wall: "Given what we learned this week, what's most important now?"
The first meeting was chaos. People kept reverting to status updates. "We're 60% done with the API refactor." I stopped them. "That's not the question. The question is: should you still be doing the API refactor? What did you learn this week that confirms or challenges that?"
Silence. Then the head of product said: "Actually, three customers told us this week that the API isn't their problem. Onboarding is. They're churning before they ever hit the API."
That one sentence killed a six-week project that was "on the roadmap." In the old system, they would have finished the refactor, shipped it, and then discovered it didn't move any needle. Instead, they pivoted the next day.
The one-page document. Every Friday, one page went out to the whole company. Three sections:
What we shipped this week.
Bullet points. No fluff. "Reduced onboarding steps from 7 to 4. Deployed new billing integration to 20% of accounts."
What we're working on now.
Current bets, not features. "Bet: Simplifying onboarding will reduce week-1 churn by 15%. Test: A/B test with new accounts starting Monday."
What we're deciding next.
The open question for the following week's prioritisation. "If the onboarding bet works, do we double down or move to activation emails?"
The first few Fridays felt awkward. The document was short. People asked, "Is that it?" Yes. That's it. If you can't fit your focus on one page, you don't have focus.
The mid-cycle surprise. Week three, their largest customer called. They wanted a custom analytics dashboard, immediately, or they'd evaluate competitors. In the old system, this would have triggered a two-week planning scramble. Roadmap review, dependency analysis, resource reallocation, stakeholder alignment meetings.
Instead, it took one conversation. Wednesday's prioritisation meeting. The question: "Is this more important than what we're currently doing?" Product laid out the stakes: $400K ARR account, 18-month relationship, clear requirements. Engineering estimated three weeks with two people. The onboarding bet was already showing early positive signal and could continue with the remaining team.
Decision made in 15 minutes: split the team temporarily, build the dashboard, revisit in three weeks. No roadmap update. No Gantt chart revision. No alignment meetings. Just a decision and immediate action.
The dashboard shipped in two and a half weeks. The customer signed a two-year extension.
Six months later. They'd shipped three major features that weren't on the original 12-month roadmap: the onboarding simplification, the customer dashboard, and a billing overhaul that emerged from week-8 customer interviews. Features that would have been invisible inside a long-range plan because the information that made them obvious didn't exist when the plan was written.
The team was faster. But more importantly, they'd stopped building things that didn't matter.
How to sell this internally
Changing how your organisation plans means getting buy-in from multiple directions. The objections you'll face depend on who you're talking to.
Selling up: boards, investors, your CEO
"This makes sense, but my board will never accept it."
I hear this often. Sometimes it's true. But more often, leaders assume their stakeholders want elaborate roadmaps when what they actually want is confidence. Those aren't the same thing.
Don't say "we're abandoning roadmaps." Say "we're increasing predictability by shrinking the prediction window." Boards and investors don't actually want a 12-month roadmap. They want confidence that you know what you're doing. Short-term clarity with honest uncertainty beats long-term fiction. Frame it as a maturity upgrade, not a retreat from planning.
Most experienced investors have seen enough roadmaps turn to dust that they're sceptical of them anyway. One founder I worked with dreaded telling his board about the shift to shorter cycles. In the actual meeting, the lead investor said: "Thank god. I never believed those 12-month plans anyway. Just tell me what you're learning." The people who think their board demands elaborate roadmaps are often projecting their own anxiety onto stakeholders who share it.
Selling sideways: sales, marketing, customer success
"How am I supposed to sell without knowing when features are coming?"
Sales teams have been using the roadmap as a closing tool for years. Marketing has built launch campaigns around predicted release dates. Customer success has been setting expectations based on "Q3 commitments." When you tell them the roadmap is gone, they hear: "You're on your own."
They're not wrong to worry. But the problem isn't that you're taking something away. It's that what they had was never real. Sales has been closing deals on dates that slip. Marketing has been scrambling to adjust campaigns when features miss their windows. Customer success has been apologising for broken promises they didn't make.
What they actually need isn't a 12-month feature list. It's answers to three questions: What can we confidently promise right now? What direction are we heading? How quickly will we know more?
Give them a "now, next, later" framework:
Now: What's shipping in the next six weeks. High confidence.
Next: What we're likely to prioritise after that. Moderate confidence.
Later: Directional. No dates.
Sales can use this language with customers. Marketing can plan launches around "now" instead of chasing moving targets. Customer success can explain what you're building instead of apologising for what slipped. It's more honest than a fictional Q4 commitment, and honest timelines build more trust than broken promises.
Selling down: your engineering team and product managers
"We tried working without a roadmap before. It was chaos."
This objection is the most important one to take seriously, because it often comes from experience. Many teams have lived through "agile transformations" that meant constant reprioritisation, half-finished projects, and whoever shouted loudest getting their way. If your team has that trauma, they'll resist anything that sounds similar.
The key distinction: this isn't "no planning." It's planning at a different altitude. The 6-week horizon actually creates more stability than a 12-month roadmap, because the commitments are real. When you say "we're building this for the next six weeks," you mean it. No one's going to walk in on week three and blow it up for a shiny new idea. The weekly prioritisation meeting is for deciding what comes next, not for disrupting what's in progress.
Engineers who've been burned by chaos usually want two things: uninterrupted time to do deep work, and confidence that what they're building matters. The 6-week cycle gives them both. They get a protected window to focus. And because priorities are based on what you learned last week, not what someone guessed six months ago, the work stays relevant.
Product managers often have a different worry: "How do I do my job without a roadmap?" The answer is that their job gets better, not harder. Instead of spending half their time updating Gantt charts and negotiating fictional dates with stakeholders, they spend that time learning from customers and shaping what gets built next. That's the actual job. The roadmap was overhead.
One PM told me, six months after the switch: "I used to spend 40% of my time on roadmap administration. Now I spend that time talking to customers. I'm not going back."
Some people will remain sceptical even after seeing results. That's worth paying attention to. Sometimes they're seeing a real problem you've missed. But sometimes it means they valued the theatre more than the outcomes, and that's information about fit.
Start small, let results speak
Don't announce a company-wide planning revolution. Pick one team. Run them on 6-week cycles for a quarter. Measure what ships. When they outperform teams running on the old model, the case makes itself. Resistance to change melts when the results are visible.
The hardest stakeholder to convince is usually yourself. If you've spent years building elaborate roadmaps, admitting they were theatre feels like admitting failure. It's not. Recognising what doesn't work is the first step to finding what does.
Stop writing fiction
Your roadmap isn't a plan. It's a story you tell to avoid harder conversations.
The harder conversation sounds like this: "We don't know what Q4 looks like. We have strong hypotheses about where we're headed, but the honest answer is we'll know more in six weeks than we know today. What we can tell you is exactly what we're building right now, why it matters, and how we'll decide what comes next."
That conversation feels risky. It's actually safer. Because when Q4 arrives and reality has shifted (and it will) you're not explaining why the roadmap was wrong. You're showing what you learned and how you adapted. One of those is a failure story. The other is a leadership story.
Here's your move: open your 12-month roadmap. Delete everything past the 6-week mark. Replace it with one question: "What's the most important thing we can ship in the next six weeks?"
Answer that question well, repeat it every six weeks, and watch your team start shipping things that matter.
If you're struggling to get there, if the roadmap theatre is too entrenched, or you need help having the hard conversation with your board, let's talk. Sometimes an outside voice cuts through faster than another internal debate.