Why We Killed the Six-Month Roadmap
The six-month engineering roadmap is a corporate ritual. Every Q4, every Q2, the same exercise: a director gathers stakeholder input, an architect drafts a delivery sequence, a PM grooms it into Gantt-shaped optimism, and the executive team signs off on a document everyone agrees will be wrong by February.
We do not do this anymore. Not because we became disorganized. Because the half-life of a software roadmap in 2026 is roughly six weeks, and pretending otherwise is the most expensive form of organizational theater there is.
The Old Math
The six-month roadmap was a reasonable forecasting tool when implementation was the dominant cost. If a feature took six engineers four months to build, then a six-month window contained two or three features, end to end. You could plan the sequence because the sequence was load-bearing: every feature blocked the next by occupying scarce implementation capacity.
The roadmap was, in effect, a queueing model. Its accuracy was bounded by the predictability of how long each feature took to implement, and implementation had grown predictable. Engineers knew their stacks. Managers knew their engineers. Estimation was imperfect but not chaotic.
That math has changed in two ways.
What Changed
Implementation is no longer the rate-limiting step. A feature that used to take four months can be specified, generated, reviewed, and shipped in two to three weeks. The slow step is no longer “build it.” The slow step is “decide what to build, specify it precisely, and validate that the build is correct.” Those are judgment activities, and judgment activities do not slot neatly into Gantt cells.
The cost of changing direction has collapsed. When implementation was expensive, the cost of pivoting six weeks into a build was enormous – you threw away engineer-months. With agent-assisted delivery, the same pivot costs days. The roadmap’s main historical function – “stay the course, switching is expensive” – has lost its economic backing. There is nothing to defend against.
Combine these two and you get a structural mismatch: the planning horizon hasn’t shrunk, but the appropriate planning unit has. We are using a tool from the era of months-per-feature to plan work that ships in weeks.
What We Replaced It With
We did not replace the roadmap with sprint chaos. We replaced it with three layered horizons, each with its own cadence and its own contract.
Strategic horizon (12-24 months). What the business is trying to become. The product categories we are committing to. The markets we are entering or exiting. The technical bets we are placing – platforms, partnerships, capabilities. This horizon is qualitative, deliberately vague, and updated twice a year. It is not a delivery plan. It is a direction.
Outcome horizon (6-12 weeks). What outcome we are trying to produce next. Not features. Not tickets. Outcomes – the user behavior, business metric, or operational capability we expect to see. “Reduce time-to-quote for new clients from 12 hours to under 1 hour” is an outcome. “Build a quote-generation API” is a feature that may or may not produce that outcome. Outcomes are written down. They have owners. They are reviewed every six weeks. They survive the loss of any single feature in their plan.
Delivery horizon (1-2 weeks). What is shipping. Specifications written, agents executing, reviewers reviewing, code merging. This is the only horizon where we maintain a precise sequence. It is the only horizon where dates are commitments rather than estimates.
The strategic horizon says where we are going. The outcome horizon says what we are buying with the next few weeks of effort. The delivery horizon says what is currently being built. None of these is a six-month roadmap. All of them are useful.
What the Customer Notices
We tell clients up front. We do not promise feature delivery six months out. We commit to outcomes – agreed in writing – over a six- to twelve-week window, and we commit to specific delivery within a two-week one. The longer the horizon, the less specific the commitment. This is honest. It is also more accurate than the roadmaps they were used to.
The first reaction is sometimes nervous. The roadmap, however unreliable, was a comfort object. Some procurement teams want a feature list with dates next to it because that is what their internal templates require. We provide one if we have to. We mark it “directional, refreshed every six weeks.” We do not let it become the contract.
The second reaction, after a quarter, is relief. The team stops spending the first week of each quarter arguing about what slipped from the roadmap. The reviews are about whether the outcomes were achieved, not whether the Gantt chart held. The Gantt chart is a tool. The outcomes are the work.
What We Lost (and Did Not Miss)
We lost the long-horizon planning ritual itself, and a particular flavor of executive theater that came with it. Some leaders genuinely miss the document. They miss being able to point at a printout and say “this is the plan.” The plan was always a fiction; the printout was the comfort. We have replaced the comfort with shorter cycles of honest commitment, and so far no one has asked for the printout back.
We lost the illusion of certainty. We did not lose certainty itself, because we did not have any to begin with. We just stopped paying for the illusion.
What Replaced the Roadmap Conversation
The conversation we used to have about the roadmap – which features, which order, which quarter – has been replaced by a conversation about which outcomes matter and why. That conversation is harder. It requires the stakeholder to articulate the business problem rather than dictate a solution. It requires engineering to push back on outcomes that sound good but cannot be measured. It produces fewer artifacts and more decisions.
This is the right trade. Outcomes are durable; features are negotiable. Outcomes tell us why; features tell us what. In a world where the cost of “what” has collapsed, the only conversation worth having is “why.”
The Honest Statement
The six-month roadmap was built for an era of expensive implementation and slow change. The era is over. Killing the roadmap is not radical. It is reading the room.
If your roadmap document is still 30 pages long, still reviewed quarterly, and still the artifact your stakeholders argue over – the document is doing more work than the team is. Replace it with outcomes you can defend, delivery you can date, and a strategic direction you are willing to revisit when reality changes. You will plan less and ship more.
