Why Your Technical Roadmap Dies by March

The December Ritual

By March, the spreadsheet is fiction. Of twelve committed Q1 deliverables, five shipped, three are half-done, two turned out far harder than anyone estimated, one is blocked by a dependency nobody flagged. The board wants to know why the company is behind. The team feels like they failed. Nobody in the room actually failed, the artifact they were measured against was wrong the day it was signed.

Put yourself in the CTO seat on March 15th, preparing the Q1 review. Most of the miss isn't an execution problem, your team shipped hard things. The list you're reporting against was built before most of what you learned in January and February existed. And yet the only number anyone cares about is the percentage hit.

The Planning Ritual, Not the Plan

Dwight Eisenhower captured the distinction six decades ago: "plans are useless, but planning is indispensable." He was talking about invasions, but the sentence lands harder in an engineering org than almost anywhere else. What matters in December is the argument the spreadsheet forces, which bets matter, which assumptions are load-bearing, which dependencies you haven't scoped. The artifact is a byproduct of the argument.

The problem is that the artifact is what gets carried into the new year. The argument stays in the room. Six weeks later the spreadsheet is what gets pointed at in every status meeting, and the reasoning behind it has evaporated. When March pressure hits, you're defending a list whose logic nobody can reconstruct.

This isn't only an engineering-org problem anymore. As AI reshapes what's possible in a quarter, every company is becoming a technology company whether it planned to or not, and the December-to-March gap now punishes anyone running against a roadmap, tech or not.

The pattern we've watched most often across fractional engagements: the roadmap becomes a performance of certainty. Exact dates. Specific features. Color-coded quarters. It looks like a plan. What's actually happening is subtler, and worth naming precisely, we'll come back to it.

Every Q1 since the invention of the Gantt chart has quietly punished teams for the gap between what December claimed to know and what February actually revealed.

The Constraint That Moves

Eliyahu Goldratt's Theory of Constraints makes a claim that's easy to nod at and hard to internalize: the binding constraint on throughput is rarely where you think it is, and it moves. A December plan optimizes against the constraint you believed was binding then. By February, a customer conversation or a staffing change has shifted it, and the plan is still optimizing the old one.

At Brandfolder, well before the $155M acquisition by Smartsheet, an early roadmap treated search latency as the binding constraint on enterprise usage. It wasn't. The actual constraint was how long it took a marketing team to onboard their existing asset library, a different engineering problem entirely. "Improve search" was defensible on every slide and pointed at the wrong limit. The teams that navigated this well didn't have better forecasts. They had cheaper ways to notice they'd been pointed at the wrong thing and rotate.

That's what a December roadmap can't do on its own. It freezes the constraint as of the day it was written.

The Forecast-Commitment Swap

Here's the pattern, named: the December roadmap is a forecast being treated as a commitment. A forecast says given what we know right now, here's what we expect to build. A commitment says regardless of what we learn, this ships. The two sentences sound almost identical in December. By March they're violently different documents, and the team is being measured against the wrong one.

Every committed deliverable is a stack of assumptions. Our API supports mobile use cases. The second senior hire lands by January. Seventy percent of the web logic is reusable. The customer's IT team will turn around SSO config in two weeks. Strip those assumptions out and the commitment collapses into a wish.

The teams that survive Q1 aren't the ones with better forecasts. They're the ones who make the assumption stack visible, test the two or three that would detonate the plan if wrong, and treat the rest as known exposures. Will Larson writes about this on Irrational Exuberance: plans exist to be changed on the record. When February data contradicts January's assumption, the team can see exactly what needs to shift.

Most December roadmaps fail this test before the new year starts. Assumptions live in people's heads; the spreadsheet shows only the output. By February, nobody can tell whether the plan is off because an assumption was wrong or because execution slipped, and those require opposite responses. Conflating them is how good teams burn a quarter running in the wrong direction.

What a Useful Roadmap Actually Does

The useful move is a different relationship with the artifact, not a better template. Three shifts do most of the work.

1. Write the outcome, not the route

   "Enterprise customers can deploy within their security requirements by end of Q1" is a destination. "Ship SSO, audit logging, and RBAC by March 15" is a route. Routes get invalidated the first time the terrain changes. Destinations survive because they describe why the work exists. Basecamp's Shape Up makes the same move with appetites instead of estimates, the question becomes "how much are we willing to spend to solve this," not "exactly when will this ship."

2. Make the assumptions load-bearing, not decorative

   For every major commitment, write the two or three things that must be true for it to land. Test the riskiest before anyone commits, a customer call, a spike, a prototype. Martin Fowler's writing on evolutionary architecture is a decades-long argument that the cheapest moment to learn an assumption is wrong is before you've built around it.

3. Build in the rotation

   Replace "are we on track" with "what did we learn this month, and does the plan still match reality?" Gergely Orosz at The Pragmatic Engineer has documented this across engineering orgs that ship consistently: replanning is continuous, not annual, and the plan is expected to move. The orgs that ship less consistently treat replanning as an admission of failure, which is exactly how plans ossify into fiction.

Back to March 15th

You're still in the Q1 review. The spreadsheet still says twelve. You still shipped five. "Why are you behind" is the wrong question, but it's the only one that gets asked when the roadmap is framed as a commitment.

The better question, and the one the room should be trained to ask by March of next year, is: what did Q1 teach us that December couldn't have known, and how is the plan different now because of it? If the answer is "nothing, and it isn't," the planning was theater. If the answer is specific, this assumption broke, this customer signal moved the constraint, this dependency shifted, the quarter did its real job.

The December ritual survives. The December artifact doesn't need to.