Quarterly, annual, weekly planning. Oh, the roadmap. Every organization I have worked in has a season for it. Someone opens the doc. Someone else negotiates for a lane. The quarters get colour-coded. A date lands on a bar and, from that moment, the date is real in a way nothing else in the company is real. Then the work happens but the plan doesn’t, or it sort of does, and next season we do it again, slightly earlier, with a better template.
I want to be careful here, because it is easy and cheap to dunk on planning. Leaders are not stupid for wanting a roadmap. They have budgets to defend, people to hire, contracts with dates in them, a sales team that needs to know what it can promise. That is all real. What is not real is the belief that a colour-coded bar chart drawn in January describes what will happen in September. And with agents in the mix, that belief has gone from a shared professional fiction to an active hazard.
The practice is literally ancient
This isn’t a metaphor. The ancestor of the chart we still stare at was drawn by Henry Gantt, an American mechanical engineer who worked alongside Frederick Winslow Taylor at Midvale Steel and developed his bar chart in the 1910s. A Polish engineer, Karol Adamiecki, had built an earlier version in the 1890s. So the instrument at the centre of modern work planning is an artifact of scientific management, designed for a world of repeatable physical tasks where the whole point was that a competent worker doing a known job took a known amount of time.
Software is not that. Writing is not that. Design is not that. And a coding agent that behaves differently at 4pm than it did at 10am is emphatically not that.
It was already broken before AI
In every organization, there’s a handful of people who know. They know the doc will get roasted by senior leadership, they know that it represents the most optimisitc and professional-sounding version of the work, and they know it will all be meaningless in about three weeks. It’s one of the reasons senior leadership always asks for the roadmap to be socialized so that people see their work represented. It’s built the wrong way round by team or org leaders trying to win some space for their people, some credit, another rung up for themselves.
Henry Mintzberg dismantled the whole enterprise in The Rise and Fall of Strategic Planning in 1994. His “fallacy of prediction” names the hidden premise exactly: strategic planning assumes the world will hold still while you write the plan, and then stay on the predicted course while you execute it. Discontinuities like a technological jump or a price shock are not forecastable, so a long-range plan is an illusion of control, a wolverine wearing a suit.
Marty Cagan has spent twenty years saying a narrower version of this to product teams. In 2009 he wrote that “to lock in specific features at the roadmap level is to effectively skip the most important part of your job…which is product discovery.” In 2013 he named the two inconvenient truths: “at least half of our ideas are just not going to work,” and even the survivors need iteration, because “it typically takes several iterations to get the implementation of this idea to the point where it actually delivers the expected business value.” By 2015 he’d compressed it to five words: “It is all about outcome rather than output.” Half your roadmap is wrong, and the correct half is wrong about when. Everyone in the room knows this. Everyone signs the roadmap anyway. It’s a collective, optimistic delusion.
There’s even a measured version of the honesty we refuse to practise. The cone of uncertainty, observed by Barry Boehm and named by Steve McConnell, says an estimate made at initial concept can be off by a factor of four in either direction resulting in a sixteen-fold spread between the low and high end. Not because the estimator is bad, but because the thing being estimated hasn’t been defined yet. The cone narrows only as you make decisions that remove variability.
To be fair to the field, people have built escapes. Janna Bastow invented the Now-Next-Later roadmap specifically because timeline roadmaps demand deadlines and deadlines strangle discovery. It’s a good idea and it works. It’s also fifteen years old and most organizations still can’t bring themselves to use it, because people love to believe dates enforce accountability.
The forward-looking document that becomes a historical record
A roadmap is sold as a forward-looking instrument. It is the artifact of where we are going. But the instant it’s approved, it stops looking forward and becomes a record of what a particular group of people believed on a particular Thursday in a particular room, most of whom have since learned things that would have changed their minds. Approval is the moment the document changes tense. Everything after that is archaeology, and we keep consulting it as prophecy.
That was survivable when building anything was slow and predictable. Now, experimentation is cheap, building is easy and fast. A prototype that would have taken a team a whole quarter to stand up can be running in front of real users in an afternoon. Which means the learning that invalidates your plan now arrives inside the planning cycle rather than after it.
So the best teams I’ve worked with quietly diverge from the roadmap almost immediately, and they’re right to, because they are adaptin in real time to change and chaos, they are pursuing opportunity and embracing new directions before it is too late. They ship the prototype, see the users hate the flow, and go somewhere better. That divergence is not a failure of discipline or mutiny. It’s the entire value of having built the thing early.
Bad leadership treats the roadmap as a ledger. The team learned the right thing, went the better way, shipped something that worked, and at review time gets marked against a list of features nobody actually wanted. This is where the artifact turns actively toxic: it converts a team’s best judgment into evidence of non-compliance. If you punish divergence, you don’t get adherence. You get teams that build the wrong thing on time and stop telling you what they’ve learned. Make honesty expensive and people stop supplying it.
AI didn’t break the roadmap
Here’s what else changed. The rate at which your assumptions expire is now faster than the rate at which you refresh the plan.
METR’s time-horizon work found that the length of task a frontier agent can complete autonomously with 50% reliability has been doubling roughly every seven months for six years. Whatever you think of the extrapolation, take the direction seriously: the class of work you scoped as requiring three engineers for six weeks in your planning session has a decent chance of being a different size before the quarter ends. Not because your team got better. Because the tool did.
Then there’s the measurement problem, which I find more alarming. METR also ran a randomized controlled trial with experienced open-source developers on repositories they knew well. Before starting, the developers forecast that AI would cut their completion time by 24%. Afterwards, they estimated it had cut it by 20%. Measured, they were 19% slower. It’s a small study of 16 developers, 246 tasks, early-2025 tooling, and METR has since revised the experiment design so don’t treat the number as a law. Treat it as a warning. The gap between what practitioners felt and what actually happened ran to nearly forty points, in the flattering direction. Now consider that roadmaps are built almost entirely out of what practitioners feel, filtered upward through two layers of management who would very much like the optimistic number to be true.
And DORA’s 2025 report puts the ceiling on the whole fantasy: AI adoption among software professionals has “surged to 90%,” with a median of two hours a day spent working with it, and yet the report’s central finding is that AI’s primary role is “as an amplifier, magnifying an organization’s existing strengths and weaknesses.” Google’s own summary calls it “a mirror and a multiplier.” If your planning process is a fiction, AI does not fix it. AI helps you produce the fiction faster, in more detail, with better formatting.
OKRs are the same disease with a better vocabulary
Objectives and Key Results came out of Intel, where Andy Grove adapted Peter Drucker’s management by objectives into something he called iMBO around 1971 and published in High Output Management in 1983. John Doerr learned it there and carried it to Google in 1999. It is a genuinely good idea with a genuinely good pedigree, and in most companies it has curdled into the roadmap’s respectable cousin: the same list of outputs, renamed as outcomes, with a number stapled on so nobody can argue.
The academic case against goal-setting as practised is worth reading in full. In “Goals Gone Wild” (2009), Ordóñez, Schweitzer, Galinsky and Bazerman argue the benefits of goal setting have been overstated and the harms systematically ignored, and they catalogue the side effects: “a narrow focus that neglects nongoal areas, distorted risk preferences, a rise in unethical behavior, inhibited learning, corrosion of organizational culture, and reduced intrinsic motivation.” Read that list and then think about the last quarter you watched a team spend hitting a key result that everybody except maybe senior leadership had privately stopped believing in.
Sitting underneath it is the formulation Marilyn Strathern published in 1997, crediting Keith Hoskin, and which we now call Goodhart’s law: “When a measure becomes a target, it ceases to be a good measure.” An OKR is, definitionally, a measure converted into a target. The gaming isn’t a failure of character. It’s the mechanism working as designed.
To meet always-on building and continuous deployment, we need an always-on forecaster and archive
So here’s the proposal, and it isn’t “stop planning.” It’s that the plan should stop being furniture.
Every organization already emits an enormous, continuous, honest signal about what it is doing. Commits, issues, and PRs. Decisions made in Slack or Teams threads at 11pm. Meeting transcripts where somebody says the integration is going to slip and nobody writes it down. Docs half-written in a shared drive. Tickets, incidents, retros. Agent runs and their outcomes. The roadmap is an attempt to summarize all of that, performed once a quarter, by hand, by people with an incentive to sound confident, who might only be able to find a third of the signal.
Instead, I want to build a system that reads all of it, all the time, and continuously regenerates three views:
- The archive. What actually shipped, how long it actually took, and where the estimate diverged from reality. This is the important diff: plan of record on one side, what the signal says actually happened on the other, and a readable account of where they parted ways and why. Not to shame anyone. To learn the organization’s real distribution, which is the only thing that makes a forecast worth reading and to make divergence a subject you can discuss instead of an accusation you dodge.
- Now. What is genuinely in flight right now, assembled from the signals rather than from the tracker or optimistic guess work. Where we are stalled, where effort silently moved, where two teams are building the same thing, where the decision in the Slack thread contradicts the ticket, where an optimistic deadline gets overturned in a meeting transcript. This is a living document.
-
The future. A forecast expressed as ranges and confidence, not dates on bars, that updates the moment the signal changes, collected from the planning your team actually does during meetings, Slack/Teams discussions, in DMs as the deadline looms.
- It never commits to a date on its own. Humans review and commit.
- Every claim is traceable to the signal that produced it. “Slipping” with a link to the three artifacts that say so, or it doesn’t get said. No confident synthesis floating free of evidence.
- It surfaces disagreement instead of resolving it. When the tracker says green and the commit history says nothing has moved in nine days, the output is these disagree, not an averaged guess on a new date.
- It reports on work, not on people. Team and system level, always. The instant this becomes a productivity surveillance tool it is worse than the roadmap it replaced, because now the incentive to fake the signal reaches all the way down into the commit log.
I’m not claiming this is unprecedented. A whole category of tools engineering intelligence platforms, Jellyfish and LinearB and Axify and a dozen others already pull from Git, tickets, calendars and chat to report on how delivery is going, and some of them forecast from historical patterns. What I haven’t seen is the piece that matters to the argument above: a system that treats the roadmap itself as the output, regenerated continuously, and speaks to leadership in the language leadership actually wants, so that the quarterly ritual becomes reading a live forecast instead of defending a dead plan. Today those tools mostly tell engineering leaders how the engine is running. I want the one that redraws the map.
Pull the window in
There’s a simpler way to say all of this.
Shorten the prediction window. Whatever distance you are currently forecasting confidently, it is too far away. The honest horizon has moved much closer to the present, and it keeps moving closer as the tools get faster. That’s uncomfortable if your whole planning apparatus is built to answer what will we have in Q3, but the discomfort is information. You can still hold a direction at eighteen months. You cannot hold a date there, and pretending otherwise is what turns the roadmap into a liability rather than an aid and best and an optimistic drain on time and engagement at worst. Plan tightly where you can see in the short term, loosely where you can’t, and stop dressing the two up in the same bar colour.
Make revision part of the plan, not an exception to it. Right now, changing the roadmap requires an occasion, manual effort, a re-plan, an escalation, someone’s political capital. That’s backwards. Revision should be the expected behaviour of the artifact, scheduled and unremarkable, because a plan that only changes when someone forces it to change is a plan that will always be behind and likely full of bias. If updating the roadmap costs a meeting, it will happen quarterly. If it costs nothing, it can happen nightly, which is the whole point of having a machine read the signal.
Make divergence visible so it can be discussed. Divergence is not the problem. Hidden divergence is. When a team moves away from the plan, that fact should appear immediately, in plain language, with the evidence attached, and the conversation should be what did we learn, not why didn’t you comply. Visible divergence contributes to a learning organization. Invisible divergence is an organization that finds out it failed at the end of the next quarter.
None of that is a case against having a destination. If anything, pulling the prediction window in makes the destination matter more, because the plan is no longer doing the work of holding everyone together, the vision is. A team with a sharp vision and a two-week plan will beat a team with a fuzzy vision and an eighteen-month chart on a spreadsheet, every time, and the gap widens as the tools get faster.
The ritual is the thing to change
That’s the real proposal, and it’s a leadership one, not a tooling one. If the roadmap regenerates itself every night, the planning meeting stops being a negotiation over who gets a lane and becomes a review of what changed and what we’re going to do about it. The artifact stops being a promise that decays and becomes an instrument you read.
Always-on roadmapping does the planning continuously and holds the plan loosely, because we have machines that can do the reading, that can pull in signals from disparate sources and capture the actual ideas that lead to great outcomes. The failure isn’t that we plan. It’s that we’re doing it with an instrument designed for a steel mill in 1910, at a time when the ground moves every month.