What belongs in an AI roadmap, and what should stay out of it.

The roadmap slide has quarters across the top and technology in the boxes: a data platform, a model platform, a chatbot, agents. By the second review, most boxes have slid to the right, and nobody can say what changed for the business.

A useful AI roadmap is a sequence of workflows instead, each with an owner, a baseline and a go/no-go gate, arranged as now, next and later rather than by calendar quarter. Technology appears only where a workflow needs it.

Why do most AI roadmaps age so quickly?

Because they plan the fastest-changing part. Models, platforms and vendor features change faster than any plan, so a roadmap built around them is dated the day it is presented. Other habits make it worse:

• dates are promised before there is evidence, such as a baseline or an evaluation;
• boxes have no owners, so nobody answers for them when they slip;
• foundations are planned as projects without a user;
• nothing has a gate, so nothing ever stops. It only moves right.

So keep some things out: model and vendor names, dates for work nobody has measured, lines without owners, and platforms without a user. They belong in architecture notes, contracts and the parked list, not on the page leadership steers by.

What should one line of the roadmap contain?

One workflow, with six fields:

Write the workflow as work, not as technology. “Generative AI for procurement” is a theme. “Read supplier confirmations from the shared mailbox and check dates and quantities against open orders, for the planning team” is a line. The owner is a person, not a department.

A line with an empty field is not ready for “now”. Without an owner, it can’t leave “later”.

Why arrange it as now, next and later instead of by date?

Now holds work in progress with an owner and a funded step, such as a Discovery Sprint or a pilot. Next holds workflows that passed the filter and wait for capacity or one dependency. Later holds ideas that need something first: an owner, data access or a process fix.

Lines move when evidence arrives, not when a quarter ends. That is not a way to avoid commitments. The step in progress has a planned end, and its gate has a date. What you stop doing is promising dates for work nobody has measured, which is where slippage comes from.

When leadership asks “when?”, give the date of the next gate and the condition each later line is waiting for. That answer is more honest than a quarter, and easier to check. Keep “now” short, two or three lines per owning team at most, because each one consumes an owner’s time.

Where do the go/no-go gates belong?

Before each commitment of money or people:

1. After discovery: is there a baseline, an owner and reachable data? Go to a pilot, or stop.
2. After the pilot: were the acceptance criteria met, on the evaluation set and on live cases? Go to production, go with limits, or stop.
3. After the first months live: does the value hold against the baseline? Extend to more teams, or hold.

It is the rhythm of how we work: each step ends with evidence to move forward, or a clear reason not to.

A stop at a gate is progress, as long as the roadmap records why.

Write the reason on the line and leave it visible. “Stopped: review time stayed above the threshold” saves the next team from running the same pilot again.

How do shared foundations fit in?

Data access, evaluation practice, security review and training are real work, and they belong on the roadmap. Attach each one to the workflows that need it: “access to the policy library, needed by lines 2 and 6”, not “data platform, phase 1”.

A foundation built before any workflow uses it is built for imagined needs. Build it for the first workflow that needs it, and generalize when the second needs the same thing. That is the difference between data and AI foundations that get used and a platform waiting for users. Training follows the same rule: the reviewers on line 1 need training before its pilot, not a company-wide course on AI in general.

What does a one-page roadmap look like?

Take an illustrative roadmap for a distributor. The workflows, owners and gates are invented for the example.

Notice what the page leaves out: no model names, no quarters, no platform. Every dependency has a user, and the policy library appears on two lines, so it is built once, for the first of them. Below the table sits one more line: Stopped at the discovery gate: invoice-query chatbot. Volume too low to repay a system; a supplier portal page answers the same questions.

How often should it change?

Its content changes at every gate; its format hardly ever. Review the whole page every quarter against measured results, not against the original plan: which gates were passed, which lines stopped and why, what the baselines and pilots showed. Move lines between now, next and later accordingly, and admit new ideas only through the prioritization matrix. Whoever owns the portfolio, often a small central team, keeps the page current, and each owner keeps their own line honest. Watch for lines that sit in “next” through two reviews: either the dependency needs an owner of its own, or the line belongs back in “later”.

Empty fields are the plan

Rewrite your current roadmap as workflow lines and fill in the six fields. The empty fields are your real plan. A Discovery Sprint in AI strategy and discovery ends with a scoped roadmap built on a measured baseline, and a clear go/no-go.