The Half-Life of a Roadmap Is Shrinking · Bearing Forward

Sales asks a perfectly reasonable question:

“When will this be done?”

Sometimes the work hasn’t started yet. We may not know the architecture. We may not have validated the solution. Engineering may not have decomposed the work. Dependencies may still be unclear. And in AI right now, there is one more variable layered on top of all of that: the technical approach itself may change before we ever start building.

And yet someone still needs a date. Sales needs to talk to a customer. Marketing needs to plan. Finance needs to forecast. Leadership needs to make tradeoffs. Most importantly, customers need to make decisions about their own roadmaps and offerings.

Product has always lived inside this tension. But lately, it feels different.

The half-life of a roadmap is shrinking.

The question is fair

For years, product leaders have been asked to create certainty from ambiguity. We build roadmaps, estimate sequencing, communicate priorities, and try to make the future legible enough for the rest of the business to operate. That part is not new.

What is changing is the speed at which the assumptions underneath those plans become obsolete. A capability that would require months of custom development today may be available from a model provider next quarter. Something that seemed impractical six months ago may suddenly be straightforward. An architectural approach that looked reasonable when planning began may no longer make sense by the time engineering is ready to execute. And something we thought would be strategically differentiating may become table stakes faster than anyone expected.

When we decided to put ScopeAccord’s change-order workflow in front of AI assistants, we assumed that meant two integrations: a ChatGPT plugin and a separate Claude connector. By the time we scoped it, OpenAI had retired the plugin manifest format and moved third-party integrations to MCP, the same protocol Claude connectors use. So we never started the plugin project. We planned a single MCP server on the Cloudflare Workers setup we already run, one build that ChatGPT, Claude, Copilot or an insurer’s agent can all call.

That does not mean planning is useless. It means we need to get much more disciplined about what kind of certainty we are offering.

Four things we call “the roadmap”

Too often, we collapse several very different things into one artifact.

Strategy is what problems we intend to own, for whom, and why we believe they matter.

A roadmap is our current best view of how we might advance that strategy.

A forecast is what we believe is likely, given what we know today.

A commitment is what we are prepared to organize the business around and be held accountable for delivering.

Those things are not interchangeable. But inside organizations, they become interchangeable very quickly. A tentative forecast gets put on a slide. The slide reaches Sales. The date reaches a customer. And suddenly, a hypothesis has become a promise.

That is not an AI problem. Product organizations have been doing this forever. AI just makes the consequences harder to ignore, because the uncertainty is no longer only in execution. It is in the underlying technological landscape itself.

That creates a strange tension for Product. I understand why businesses want more certainty, not less. “We’ll know when we know” is not a strategy. Sales cannot sell entirely in probabilities. Finance cannot forecast entirely in ranges. Customers cannot plan around perpetual ambiguity.

But the answer cannot be to manufacture precision we do not have.

False precision may be one of the most expensive habits Product carries into the AI era.

Commit to the problem, not the mechanism

I am increasingly convinced that the more useful skill is not predicting farther into the future. It is knowing which parts of the future deserve commitment and which should remain deliberately unresolved.

That changes how I think about roadmaps. I want to commit hard to the problem and stay flexible about the solution.

“We need to reduce the time it takes a customer to accomplish this outcome” may remain strategically sound even if the mechanism changes three times. “We will build this exact feature in Q3 using this exact architecture” is a much more fragile statement.

The first is strategy. The second is a theory dressed up as a commitment. And theories should be allowed to change when the evidence changes.

Building ScopeAccord has made this much harder for me to ignore. When the time and money are yours, changing direction doesn’t feel like failure. Continuing to build after the assumptions have changed does. There is very little emotional reward in saying, “Well, this is what we said we were going to build six months ago.” You care about whether it is still the right thing to build now.

That founder mindset is following me back into my day job, the same way it has already changed how I think about engineering. I am becoming less interested in whether a team “stayed on roadmap” and more interested in whether the roadmap remained the best expression of the strategy as reality changed.

That does not mean changing direction every week. A roadmap that changes with every new model release, customer request, or executive opinion is not adaptive. It is simply unstable. Strategy still needs conviction. But conviction and rigidity are not the same thing.

Maybe the better operating model is to be very clear about what is fixed and what is not. Firm about the customer problem we intend to solve. Firm about the business outcome we need to create. Firm about the market we want to serve. Firm about the principles and constraints that matter. And much more willing to revisit the mechanism.

Say the uncertainty out loud

We also need to become more comfortable exposing uncertainty instead of quietly removing it from our communication. If I say something is likely in Q2, that should not mean the same thing as saying the company is committed to delivering it in Q2.

There should be room to say:

Here is our current forecast.

Here are the assumptions underneath it.

Here are the dependencies that could move it.

Here is our current confidence.

Here is when we expect to know more.

That is less satisfying than a single date. But it is more honest, and I think it is also more useful, including to the customers who are trying to plan around us.

The irony is that AI may eventually make some things much easier to estimate. Development cycles may shrink. Prototyping may become dramatically faster. Teams may be able to validate approaches before committing large amounts of engineering capacity. But during this transition, we are going to live with an uncomfortable combination of faster execution and less stable assumptions.

That makes planning more important, not less. It just changes what good planning looks like.

Changing the route

So when Sales asks me, “When will this be done?” I do not want to reject the question. It is a fair question. I just want us to become more precise about the answer: what we are committed to, what we are forecasting, what remains unknown, what would change the answer, and what we expect to learn next.

AI is not making roadmaps obsolete. It may be making false certainty obsolete.

The roadmap was never supposed to be a prediction of the future. It is our current best theory for how we move through it.