How to create a product roadmap in the AI era, step by step

Yesterday I argued that a roadmap should start from the gap between what you set out to build and what you have built. This is the practical version: the six steps we use, in order, and what changes about each one when a team ships with coding agents.

1. Write the strategy on one page

Where you win, for whom, the two or three strengths to build on, what you will not do. If you do not have this page, write it first. A roadmap without it is a list of requests with dates.

2. Read what the product can do today

Not the last roadmap. The product. List its capabilities and how mature each one is: what works, what is half built, what exists in code but nobody uses. Until recently this meant asking the engineers and trusting the answer. Feature1 reads it from the repository, which matters because with AI coding the answer changes weekly.

3. Name the gaps

Put the strategy next to the capability list. For each capability, the difference between what it does today and what the strategy needs it to do is a gap. Write them down as plain sentences: "customers can export data, but not on a schedule, and the strategy says we win on being the system of record." Most teams find ten to thirty. That list is the roadmap's raw material.

4. Bundle the gaps into bets

Gaps are too small to plan a quarter around. Group the ones that close together into initiatives. "Enterprise-ready" is not a feature, it is four gaps closed as one bet: single sign-on, an audit log, admin roles and a service-level agreement. Each initiative gets an objective, which is the commitment, and a key result, which is how you will know it worked. Objectives commit and measure. They do not invent the work.

5. Order the bets

Now, and only now, put them across time. Two to five lanes the team names. Priority, effort and dependencies decide the order within a lane. Features under each initiative get scheduled into sprints by what fits and what is blocked. This is the part every roadmap tool does well, so spend the least time here.

6. Let the code update the roadmap

This is the step that did not exist before. 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, the gaps are recomputed, and a commitment that no longer matches reality shows up as a signal instead of a surprise. Change an objective and the implied gaps are proposed again. The roadmap stops being a document that was true once.

What it looks like

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, and every story traceable back to one of the two objectives. When a developer picks up a story, the why is already there.