What an AI roadmap should actually contain

A roadmap is a sequence of decisions, not a list of features with dates. Each item should name the number it moves, what has to be true before it can start, the decision point where you would stop, and who runs it afterwards. Order by what unblocks the rest rather than by value, because the first project’s real output is the capability the next three depend on.

The test of a roadmap is not whether it is ambitious. It is whether anyone can tell, in six weeks, that an item should be dropped.

Key takeaways

Sequence by dependency, not by excitement. The first project buys the plumbing for the rest.
Every item needs a number it moves and the current value of that number.
Every item needs a stopping rule, or it will run until the budget does.
The list of what you are deliberately not doing is the most useful page in the document.
A roadmap with no named owner per item is a wish list with formatting.

Who this applies to

You have more than one candidate use case, a budget that covers some of them, and a board or an executive asking for a plan. Three adjacent documents are not this one: how to identify candidates is where the hours actually go, how to brief a single project is scoping an AI project that ships, and whether you need a fractional lead at all is fractional AI lead: when it beats hiring.

What most AI roadmaps are

A list of use cases, sorted roughly by how interesting they sounded in the workshop, with quarters attached.

Three things are missing, and each one is why the document stops being used by month four.

No dependencies. Item three cannot start until a data access request clears legal, which nobody has raised. The plan says Q2 anyway.

No capability build. Every item is treated as independent, so the same evaluation, logging and deployment work is implicitly re-bought four times, or done once and credited to nothing.

No stopping rule. Nothing in the document says what would make an item not worth finishing. So items are finished, because stopping requires someone to argue for it without evidence.

Both documents look similar in a board pack. Only one of them survives contact with a delay, because only one says what should happen next.

Six things each item needs

Field	Why it is there
The number it moves, and today’s value	Without a before-number the result is unarguable in both directions
What must be true first	Data access, a content owner, a system that can be read, a decision somebody else owns
The smallest version that proves it	The thing you would build if the budget were a quarter of what it is
The decision point	A date and a named person, at which this continues, changes or stops
Who runs it after launch	If this is blank, you are planning to hand it to whoever is nearest
What it costs to keep running	Model spend, content maintenance, and the review time it will consume every month

The fifth row is the one that most often changes a plan. A team that can build four things and support one has a roadmap of one, and the honest version of that document is a much better conversation than the aspirational one.

Order by what unblocks the rest

The instinct is to sequence by value: biggest prize first. That is usually wrong for the first two items, because the first project’s real output is not the project.

The first delivery establishes the things every later one needs: a way to evaluate quality, a place logs go, a deployment path, a permissions model, and an organisational habit of asking for a number before and after. None of that is visible on a roadmap, and all of it gets paid for by whichever item goes first.

So pick a first item that is small, real, and touches the plumbing you will need again. A high-value second project is then substantially cheaper and faster, and the difference is the capability the first one built.

Two practical consequences. Do not put the hardest, most political use case first, however large the prize, because you will be building the capability and fighting the politics at once. And do not put a throwaway first, because plumbing built for a toy is thrown away with it.

None of what the first project really delivers appears on a roadmap. All of it gets paid for by whichever item goes first, so choose that item for what it unblocks.

The dependencies that are always missed

Data access approval. Frequently the longest lead time in the whole plan and the one nobody schedules. Raise it in week one of the roadmap, not week one of the project.

A content owner. Retrieval systems need someone who owns the accuracy of the documents. If that person does not exist, the system’s quality has an expiry date.

Content that does not exist yet. Half of what an assistant should know is often not written down anywhere. That is a documentation project, and it belongs on the roadmap as its own item rather than hidden inside another.

A measurement habit. The first project should leave behind an evaluation set and the expectation that changes are measured. Without it, item two starts from the same place item one did.

Somebody’s time. Not budget. The subject-matter expert who has to verify labels for three days is the constraint that most often slips a plan, and they have a day job.

Reviewing it, and killing things

A roadmap should be reviewed quarterly against four questions:

What did we learn that changes the order? What has become cheaper or possible since we wrote this? What has changed outside - a provider price, a model capability, a regulation, a vendor’s roadmap? And what should we stop?

The fourth is the one that needs a rule written in advance. An item without a stopping condition is not a plan, it is a commitment, and the difference matters most when the item is going badly. The pattern to avoid is the project that continues because stopping would be embarrassing, which is a decision being made by nobody in particular.

The page that matters most

The list of things you are choosing not to do, with one line each on why.

It is the most useful page in the document for three reasons. It stops the same suggestion returning every quarter with a new sponsor. It shows the board that the plan is a set of choices rather than an inventory of enthusiasm. And when the reason is no longer true - the data arrives, the price falls, the regulation clarifies - the item is already scoped and can be moved into the plan in an afternoon.

Write the reason as a condition rather than a verdict. “Not now, because we have no owner for the content” is a sentence that can expire. “Not a priority” is not.

Both lines reject the same item. Only one of them tells you what would change the answer, which is the whole function of the page.

What we put in ours, including the parts clients dislike

Every item carries a number, an owner after launch, and a stopping rule with a date. If we cannot write the owner, the item goes into the not-doing list until somebody’s name can go in the box, and that conversation is uncomfortable more often than not.

We also put the maintenance line on the same page as the build cost, rather than in an appendix. A roadmap showing four builds and no running costs describes a year that cannot happen, and the client who approved it discovers that in month seven.

The recommendation that costs us: for most companies with one obvious painful workflow, the honest answer is that they do not need a roadmap at all. They need to do the workflow, well, and see what they learn. Producing a twelve-month plan for an organisation that has never shipped one of these is planning in the absence of information, and it usually delays the only thing that would generate any.

Where we have been wrong: we have written roadmaps sequenced by value, and watched the second item stall on an access approval that should have been raised in month one. Now the dependency list is drafted before the order is, and the order is a consequence of it rather than the other way round.

When you do not need one

One workflow. Do the workflow. A roadmap for a single project is a project plan with a longer name.

Nothing shipped yet. Plan the first delivery properly and leave the rest as a candidate list. Everything after item one will be rewritten by what item one teaches you.

No owner for the plan. A roadmap nobody owns is a document that gets presented once. If there is no person whose job includes it, the roadmap is not the missing piece.

Frequently asked questions

How far ahead should it look?

Two quarters in detail, and a candidate list beyond that. Anything more specific than that in this field is fiction, because model capability and price move faster than an annual plan can absorb.

Should it name specific models or vendors?

For the item in flight, yes, with a pinned version. Further out, name the capability rather than the product, because the shortlist will have changed by the time you get there.

Who should own the roadmap?

Someone accountable for an operational number, not for technology. The best of these documents we see are owned by the person who runs the function being improved, with technical input rather than technical ownership.

How do we handle a request from an executive that is not on it?

Cost it, put it on the list with its dependencies, and show what it would displace. A roadmap’s main practical use is making the trade visible rather than making the answer no.

What if the plan changes every quarter?

That is the plan working, provided the changes are driven by what you learned. What matters is whether the not-doing list and the stopping rules are being used, not whether the order held.

Next step

If you have four candidate use cases and no way to order them, the sequencing is a short piece of work and it usually changes what gets built first. A fractional AI lead owns that plan and the decisions inside it, including the ones about stopping.