Your Roadmap Is a Work of Fiction —
And Everyone Knows It

I was sitting with a delivery team not long ago — smart, capable engineers and product people — reviewing what the organisation officially called its product roadmap. It was a well-formatted document. Colours, swim lanes, quarterly columns, RAG statuses. It had the visual grammar of a plan. What struck me, though, was the conversation happening underneath it. While the slides were being walked through, a separate, entirely parallel conversation was taking place in the chat window — about which items were actually possible, which dependencies had never been discussed with the teams involved, and which quarterly commits were, to use the precise technical term that came up more than once, "completely made up." Nobody said that in the room. In the room, everything was on track.

I have spent over twelve years building and recovering complex programmes inside financial institutions, healthcare technology companies, SaaS organisations, and enterprise software businesses. In that time, I have seen more roadmaps than I can count — and I have come to believe that the majority of them have one thing in common: they were designed, consciously or not, to satisfy the people above the room rather than to accurately represent what the people inside the room could actually deliver. That gap — between what is committed upward and what is achievable on the ground — is not a planning problem. It is a leadership and governance problem. And it is costing organisations far more than they acknowledge.

The Numbers Don't Lie — But Roadmaps Often Do

Before we examine why roadmaps become fiction, it is worth establishing how pervasive the problem actually is. Because if we are honest, the data has been telling us this story for years.

These are not outlier numbers from poorly managed organisations. They are consistent findings across industries, geographies, and project types. The McKinsey and Oxford research covered over 5,400 large IT projects and found the same patterns everywhere. The problem is structural, not exceptional. And the most significant driver of that structure is not bad engineers, insufficient tooling, or unrealistic market pressure. It is a governance failure at the point where strategy becomes a roadmap.

How Roadmaps Become Political Documents

The pattern I have watched repeat itself across industries begins not in the planning room but in the boardroom — or, more precisely, in the gap between the boardroom and the planning room. Senior leadership or the board sets a strategic direction. Revenue targets are established. Investor commitments are made. And then, somewhere in the layers between, a set of KPIs and timelines filters down to the product and engineering organisation — not as a proposal, not as a starting point for dialogue, but as an outcome that needs to be reflected in a roadmap.

The request that lands with delivery teams is rarely "what can we build and by when?" It is, far more commonly, some variant of: "We've committed to this in Q3 — make the plan work." And so the plan is made to work. On paper. The quarterly columns are filled. The swim lanes are coloured. The dependencies are marked as "to be confirmed" or quietly omitted. The team's real capacity — which includes the 20% consumed by keeping existing systems running, the engineering debt accumulating from six previous rushed cycles, the key architect who is across three other initiatives simultaneously, the ten days of leave that are not in any estimate — disappears into assumptions that everyone in the room knows are optimistic, but that nobody in the room is willing to say aloud, because the number that needs to be in that box is already decided.

This is not a cynical reading of what happens in organisations. It is a structural observation. The people with the authority to make strategic commitments are often not the people with visibility into delivery reality. And the people with visibility into delivery reality are often not present — or not sufficiently empowered — when those commitments are made. The result is a roadmap that satisfies the room it was built for, not the reality it is supposed to represent.

The Six Gaps That Turn Every Roadmap Into Fiction

After more than a decade of working inside these situations — sometimes inheriting the fiction, sometimes being asked to recover from it — I have come to see the same structural gaps appearing every time. None of them is accidental. Each one is a rational response to an incentive system that rewards looking credible over being honest.

The Capacity Illusion: What Never Gets Counted

Let me be specific about the capacity gap, because in my experience it is the most consistently overlooked and the most reliably damaging. When a roadmap is built with a team of, say, twelve engineers, the plan typically assumes twelve engineers are available, full-time, for the duration of the roadmap cycle. That assumption is almost always wrong, and the people building the plan know it.

What the plan does not account for: the engineering time consumed by keeping existing systems running — incident response, patching, infrastructure maintenance, compliance updates — which routinely consumes between 20% and 40% of team capacity in any mature product organisation. It does not account for annual leave, sick leave, parental leave, and the inevitable gaps created by attrition. It does not account for the technical debt service that was deferred from the last three roadmap cycles and that is now costing the team meaningful time every sprint. And it does not account for the key person dependencies — the architect who is across three workstreams, the senior engineer who is the only person who understands the integration layer — who become single points of failure the moment any of the parallel assumptions slip.

The result of this invisible capacity drain is entirely predictable and entirely avoidable: the first sprint of a new roadmap cycle typically progresses as planned, because the team has just emerged from a replanning exercise and morale is temporarily high. By the third sprint, the cracks are visible to the people inside the work. By the fifth or sixth sprint, everyone knows the quarterly milestone is not achievable on the committed timeline. The question becomes not "what can we do about it" but "when do we stop pretending, and what will we tell them when we do?"

The Reporting Silence: When Everyone Knows and Nobody Says

One of the most corrosive dynamics in organisations with broken roadmaps is what I think of as the reporting silence — the systematic suppression of accurate delivery information as it travels up the chain of command. It is not usually dishonesty. It is a rational response to a culture that penalises bad news.

The pattern works like this: the team knows, often weeks or months before it becomes visible to leadership, that a milestone is not achievable. The senior engineer knows. The project manager knows. The product lead knows. But each layer of management between the team and the executive has learned — through direct experience or by watching what happened to others — that accurate bad news is not rewarded. Red statuses attract scrutiny, not support. Escalations that surface genuine blockers are treated as performance failures rather than as the information the organisation needs to make good decisions. And so the status report stays green. The can is kicked. The quarterly commit is maintained on paper until it can no longer be maintained, and the inevitable conversation — which should have happened months earlier, with enough time to adjust — happens instead as a crisis.

This is not a team problem. It is an organisational culture problem that has leadership fingerprints all over it. Gallup's research consistently shows that managers account for approximately 70% of the variance in their team's engagement and behaviour. When a reporting culture rewards optimism over honesty, that culture was built by the leaders above it. Teams do not spontaneously develop a fear of red statuses. They learn it.

The Apple Illusion: Why Most Organisations Cannot Build That Way

It is at this point that the argument usually encounters a counterexample. Apple does it. Google does it. Amazon has done it for twenty years. These are companies with roadmaps that are credible, that ship on time, that the market can set its expectations against. So surely the problem is not roadmaps themselves, but simply how other organisations manage them?

This comparison is worth examining directly, because it contains an important truth and a significant misleading assumption. The truth: Apple, Google, and the handful of organisations that consistently deliver on their roadmap commitments do so because they have built genuine delivery capability — not just planning capability. They have engineering organisations that are deeply involved in the commitments made in their name. They have product cycles that are structured around known, repeatable capacity rather than aspirational projections. They have cultures in which the truth about delivery reality is not just tolerated but actively required, because the cost of a public commitment that slips is visible and consequential.

The misleading assumption is that what works at Apple or Google — organisations with decades of investment in delivery capability, deep technical leadership involvement in strategic planning, and product cycles explicitly tied to well-understood market timelines and revenue metrics — can be replicated by adopting their surface vocabulary. Most organisations that try to "do roadmapping like Apple" end up with Apple's aesthetic without Apple's infrastructure. They inherit the quarterly cadence, the polished product narrative, the confident external communication — without the dependency management, the honest internal capacity analysis, or the engineering culture that makes any of it credible.

What most organisations are actually doing is fitting a square peg into a round hole — trying to present the confidence and clarity of a mature product operation without having built the organisational conditions that would make that confidence justified. The result is not Apple. It is a roadmap that looks like Apple's and performs like something else entirely.

The AI Addendum: The Newest Layer of Fiction

There is a new variant of the roadmap fiction problem that I have been watching accelerate over the last eighteen months, and it deserves its own section because it is compounding existing problems at a pace I have not seen before. Boards and executive teams are now routinely adding AI-driven capacity assumptions to their roadmap conversations — treating artificial intelligence as a near-term force multiplier that can close delivery gaps, replace capacity that was cut in the last restructuring, and accelerate timelines that would otherwise require additional headcount.

This instinct is understandable. The capability demonstrations are genuinely impressive. The productivity claims from early adopters in low-governance environments are real. And the cost pressure created by the same boards now demanding AI adoption makes the magic bullet narrative very appealing. But the assumption that AI can be rapidly deployed to close delivery gaps in a typical enterprise organisation is, for most such organisations, the newest and most sophisticated layer of fiction on top of an existing roadmap that was already struggling with reality.

In regulated industries — financial services, healthcare, insurance, public sector — the realistic timeline from "the board wants AI on the roadmap" to "AI is reliably deployed in production at meaningful scale" is measured in years, not quarters. Security reviews, data governance frameworks, infrastructure uplift, regulatory compliance assessments, and the significant organisational change management required to shift how teams work — none of these disappear because the board is enthusiastic. They are the work. And they take the time they take.

What I see, increasingly, is boards treating AI as the answer to a capacity problem that was itself created by cost-cutting decisions the same boards made in 2022 and 2023. The headcount was reduced on the premise that AI would fill the gap. The AI is not yet filling the gap at the scale required. And the roadmap, which was built assuming it would, is now carrying a second layer of optimistic assumptions on top of the first — without the delivery capacity that either set of assumptions requires.

What Honest Roadmapping Actually Looks Like

I want to be clear about what I am arguing for, because the argument is not that roadmaps are useless or that planning is futile. It is that the organisations I have worked with that consistently deliver — that build and maintain the trust of their boards, their customers, and their teams — do roadmapping differently, and the difference is not a matter of methodology. It is a matter of honesty, and of building the structural conditions that make honesty safe.

Honest roadmapping starts before any tooling decision, before any framework choice, before any quarterly planning cycle. It starts with technical and business subject matter experts in the room during strategic planning — not after the commitments are made, but during the conversations that produce them. It requires a capacity model that reflects actual available capacity, including operational overhead, leave, debt service, and key person dependencies. It requires a governance model in which bad news is genuinely safe to surface — not just philosophically safe, but practically safe, with visible evidence that honesty is rewarded rather than managed away.

And it requires leadership that is willing to have a different kind of conversation with the board — one that presents credible, deliverable commitments rather than aspirational ones, and that treats the board as a partner in understanding delivery reality rather than an audience to be managed with a polished slide. This is harder in the short term. It requires confidence, preparation, and a willingness to say "no" or "not yet" to commitments that feel important but are not achievable with the resources and dependencies as they actually exist. In my experience, it is the only thing that actually builds durable trust.

The Question Worth Sitting With

If you are a CTO whose team is quietly working around the published roadmap, that is a signal worth investigating — not about the team, but about the conditions in which the roadmap was built. If you are a VP of Engineering who is spending meaningful time each week helping people update status reports to stay green, that is not a project management problem. It is a governance and culture problem, and no amount of tool adoption will solve it. If you are a programme leader who has inherited a roadmap that everyone around you knows is not credible, you are not in that position because the previous team failed to plan well enough. You are in that position because an organisation created the structural conditions for a fiction to develop, and then asked someone to manage it.

The organisations that recover from this pattern — that rebuild credibility with their boards, rebuild trust with their teams, and build delivery cultures that actually sustain — do so by naming the problem honestly, which requires leadership courage. They create structured space for the people who know the truth to say it safely. They rebuild the roadmap around what is actually achievable rather than what is politically convenient. And they invest — in the capability, the governance, and the culture — that makes honest planning not just possible, but normal.

That work is not glamorous. It does not produce a shareholder announcement or a press release about AI transformation. It produces something more durable: delivery teams that trust their leadership, executives that trust their delivery teams, and roadmaps that are worth the paper they are written on. After twelve years of watching organisations oscillate between ambition and crisis, I remain convinced that this is the work that actually matters.