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

> In this field note, veridive explains what belongs in an AI roadmap: a sequence of workflows, each with an owner, baseline measures, acceptance criteria, a go/no-go gate and its dependencies, arranged as now, next and later. It shows where shared foundations fit, why a stop at a gate counts as progress, and an illustrative one-page roadmap.

A useful AI roadmap is a sequence of workflows, 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.

## Key takeaways

- Build the roadmap from workflows, each with an owner, baseline measures, acceptance criteria, a gate and its dependencies.
- Arrange it as now, next and later; lines move when a gate is passed, not when a date arrives.
- Attach foundations such as data access and evaluation practice to the workflows that need them, never as projects without a user.
- A stop at a gate is progress: record why, and review the roadmap each quarter against measured results.

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:

| Field | What to write |
|---|---|
| Workflow | Who does what, for which cases, in one sentence |
| Owner | A named person who decides and stays after launch |
| Baseline measures | Volume, time per case, error rate and cost per case, or “to measure” |
| Acceptance criteria | What good enough means, including errors never accepted |
| Gate | The next go/no-go decision and the evidence it needs |
| Dependencies | Data, access, security review, training |

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](https://veridive.com/approach/): 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](https://veridive.com/services/data-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.

| Horizon | Workflow · owner | Next gate | Dependencies |
|---|---|---|---|
| Now | Supplier confirmations checked against orders · procurement lead | Pilot acceptance on the evaluation set | Mailbox access (done) |
| Now | Return decisions prepared with evidence · returns lead | Discovery: baseline, reference answers signed | Policy library consolidated |
| Next | Delivery-status reply drafts · service manager | Pilot start | Order-data access built for returns |
| Next | Month-end variance commentary · controller | Discovery | Finance data access; training |
| Later | Sales contract clause checks · legal counsel | Contracts in one repository | Document migration |
| Later | Employee policy assistant · no owner yet | An owner named | Policy library (shared) |

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](https://veridive.com/insights/ai-use-case-prioritization-matrix/). Whoever owns the portfolio, often a small [central team](https://veridive.com/insights/ai-center-of-excellence/), 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](https://veridive.com/services/ai-strategy/) ends with a scoped roadmap built on a measured baseline, and a clear go/no-go.

## Frequently asked questions

### What should an AI roadmap include?

A short list of workflows rather than technologies. Each line names the workflow, its owner, its baseline measures, the acceptance criteria that define success, the next go/no-go gate and its dependencies, such as data access, security review or training. Lines are grouped as now, next and later, and stopped items stay on the page with the reason.

### Should an AI roadmap have dates?

Only for the step in progress. A discovery or a pilot has a planned end, and its gate has a date. Beyond that, arrange work as now, next and later, and move items when evidence arrives rather than when a quarter ends. Date-driven roadmaps slip quietly; gate-driven roadmaps make every move a decision someone can explain.