Your roadmap should know what your product already does

I have sat through a lot of roadmap planning. It usually goes the same way. Someone opens a slide with the company objectives. The room lists the features that might serve them. Dates get attached. The slide becomes the roadmap.

Three things go wrong with a roadmap made this way, and AI-assisted development has made all three worse.

Three ways a roadmap fails

It is a feature list with dates. Items are on it because someone asked for them, and the reason did not travel with them. Six months later a feature exists and nobody can say why. With coding agents, the feature gets built before anyone has worked out why it exists, so the roadmap fills with output faster than it fills with reasons.

It starts from objectives invented in a room. The objectives are written first, then the team looks for work to fit them. Nothing in that process asks what the product can actually do today. So the roadmap describes wishes, and the gap between the wishes and the product is discovered during the build, one surprise at a time.

It goes stale the moment code changes. The roadmap lives in one tool and the product lives in a repository. The roadmap is true on the day it was written. Now that the code changes several times a day, it is out of date by lunchtime, and nobody updates it because nobody is watching the code and the roadmap at the same time.

Start from two facts, not one wish

A roadmap should start from two things you can write down and check.

Where you want to go. One page. Where you win today, for whom, and the two or three strengths worth building on. If the page does not contain at least one thing the team did not already believe, it is a summary, not a strategy.

Where you are. Not the last roadmap, the product itself. What it can do, capability by capability, and how mature each one is. This is the part almost nobody writes down, because until recently the only way to know was to ask the engineers. Feature1 reads it from the repository.

Put the two side by side and the roadmap's raw material appears on its own: for each capability, the difference between what it does today and what the strategy needs it to do. We call each of those a delta. The roadmap is the deltas, in an order, with a reason.

Gaps into bets

Deltas are too small to plan a quarter around, so they get bundled. An initiative is one bet made of several deltas. Take "enterprise-ready". It is not a feature. It is four gaps closed together: single sign-on, an audit log, admin roles, and a service-level agreement. One bet, four deltas, and every feature underneath it can be traced back up to the bet and from the bet to the strategy.

Objectives do not disappear in this model. Their job changes. An objective says "we have decided this gap matters more than the others". A key result says "this is how we will know closing it worked". Objectives commit and measure. They stop being the place where work is invented.

Time and order

Then, and only then, the roadmap becomes a picture across time. Initiatives sit in lanes the team names, in an order that comes from priority, effort and dependencies, and features are scheduled into sprints by what fits and what is blocked. This is the part every roadmap tool does well, so I will not spend long on it. The point is what feeds it: bets made from measured gaps, not features made from requests.

A roadmap that notices when the code moved

Here is the part that changes with AI. If the roadmap is derived from what the product does, it can be re-derived when the product changes. A pull request merges, the capability picture updates, and the deltas are recomputed. If a commitment no longer matches reality, that shows up as a signal, not as a surprise in the next planning meeting.

The same thing happens in the other direction. Change an objective or an initiative and the implied gaps are proposed again. The roadmap stops being a document that was true once and becomes a view that is true now.

What it looks like when it works

One team we work with runs their product this way. Two objectives. Six initiatives. Twenty-nine capabilities. One hundred and ninety-eight features. Seven hundred and forty-four user stories, over six months, with two product managers and two developers. Every one of those stories links back to one of the two objectives, so when a developer picks one up, the why is already there. When the code changes, the picture changes with it.

That is a roadmap that knows what the product already does. The other kind is a slide.