Building an AI roadmap that survives the first quarter
How do you build an AI roadmap that does not fall apart in the first quarter?
A good roadmap sequences foundations before features, has stop points, an owner per phase and running costs alongside build costs. It is short enough to fit on two pages, honest about what is unknown, and it is reviewed against evidence every month rather than defended against it.
An AI roadmap survives its first quarter when it is built to change. That means foundations such as data access, evaluation and platform come before the features that depend on them; each phase has a stop point where the company can decide not to continue; every phase has a named owner who is measured on its outcome; and the running cost of each system appears next to its build cost from the start. Most roadmaps fail on one of those four points, and this article works through each, drawing on our AI product strategy engagements where the roadmap is the main deliverable.
Why most AI roadmaps die in the first quarter
The typical roadmap is a slide with twelve initiatives spread across four quarters, produced after a strategy workshop. It dies for boring reasons. The first initiative depends on data that is not accessible, so it slips, and everything behind it slips too. Nobody owns the roadmap as a whole, so when the sponsor's attention moves, the plan stops being updated. Costs were estimated for building but not for running, so the second initiative is delayed by an argument about the first one's monthly bill. And there is no defined moment to stop, so a pilot that should have been killed in week six limps on, consuming the budget for the next one. A roadmap that anticipates these failures looks different from one that assumes they will not happen.
What an AI strategy roadmap should contain
| Element | What it is | What happens without it |
|---|---|---|
| Foundations phase | Data access, evaluation harness, platform, governance basics, done before the first feature | Every feature project rediscovers the same blockers |
| Sequenced use cases | Ranked list with the first two fully scoped and the rest held loosely | Twelve initiatives planned in detail, none delivered |
| Stop points | A dated review per phase with the evidence needed to continue | Failing work continues because nobody decided to stop it |
| Owner per phase | A named person measured on the outcome, not a committee | The plan stops being updated when attention moves |
| Build and run costs | Both lines per system, with the run line reviewed monthly | Surprise bills delay the next phase |
| Assumptions register | What must be true for each phase, checked at each stop point | Assumptions become facts by repetition |
Foundations before features
The foundations phase is the least exciting and the most important. It usually contains four things: getting the required data accessible through an API, export or replica with an owner who can vouch for it; building an evaluation harness so that every model or prompt change can be measured against a fixed set of real examples; standing up the platform, whether that is an API-first stack with model-agnostic routing or a private deployment; and writing the two-page governance document that says what the systems may and may not do. Our AI readiness assessment covers how to find out which of these you already have. A foundations phase of four to six weeks is normal, and it makes every subsequent phase shorter.
Choosing the first feature
The first feature after foundations should be one that scores well on data readiness and model risk, has a named owner who wants it, and can be measured within a quarter. It is chosen by the prioritisation exercise, not by the sponsor's preference, and it exists partly to prove that the foundations work. Resist the urge to run two first features in parallel; a second team competing for the same data owner and the same evaluation harness slows both, and a single visible success in the first quarter buys more support than two half-finished ones.
Stop points and the courage to use them
A stop point is a dated review at the end of each phase with the evidence required to continue written down in advance: the evaluation score the pilot must reach, the adoption the feature must show, the running cost it must stay under. The value of writing the criteria beforehand is that the decision becomes a comparison rather than an argument. Stopping is a normal outcome, not a failure of the roadmap; it frees budget for the next item on the ranked list and it prevents the pilot purgatory described in why AI pilots never reach production. The stop point also has a third option besides continue and stop: return to foundations, because the phase revealed a data or integration gap.
An AI implementation plan with owners and costs
Each phase needs one owner, usually the person whose team will use the system, not the IT lead and not a steering committee. The owner is measured on the phase outcome and is the one who presents at the stop point. Alongside the owner sits the cost line, and here the roadmap must show two numbers: what the phase costs to build, and what the system costs per month once live, including inference, retrieval infrastructure, monitoring, evaluation upkeep and the people who maintain it. The second number is compared against the value the owner committed to. When both are on the same page, the finance conversation happens once, at planning, rather than every month afterwards. The total cost of ownership breakdown lists what belongs in the run line.
Keeping the enterprise AI roadmap alive
The roadmap is reviewed monthly in a thirty-minute meeting: what did the evidence say, which assumptions changed, what moves. Changes are made in the document, dated, with a one-line reason, so that anyone can see how the plan evolved. The ranked list of later use cases is expected to change as the company learns what its data and its people can do; only the current phase and the next one are scoped in detail. A roadmap that has not changed in three months is not a stable roadmap; it is an abandoned one. Frameworks such as the NIST AI Risk Management Framework are useful here as a checklist for the governance items to keep on the plan without turning it into a compliance exercise.
A worked example
A university with a large, ageing ERP wanted an AI roadmap that started with a student-facing chatbot. The foundations review found that the data the chatbot needed was locked in the ERP with no reliable interface, so the roadmap was resequenced: phase one exposed the ERP's data through a clean API layer and built the evaluation harness, phase two was an internal assistant for the registrar's staff, who could tolerate early errors, and the student-facing assistant came third. Each phase had an owner in the relevant office, a stop point with adoption and accuracy criteria, and a running-cost line the finance office had approved. The first quarter was spent almost entirely on the API layer, which felt slow, but it meant the assistant phases were delivered on schedule and the ERP itself was modernised without a rewrite. The engagement is described in our university ERP modernisation case study.
Team and timeline
We produce the roadmap within a Sprint Zero, ten working days at $3,250 or ₹2,00,000, credited to the next build. It includes the readiness check, the ranked use cases, the foundations plan, owners and stop points, and build and run costs for the first two phases. Your side provides the sponsor, the process owners and a finance contact for two workshops and a review. The foundations phase and the first feature then run as a Launch 6 build or a ProofRun, and later phases are scoped at each stop point. Program prices and Care Plan costs for the run line are on the pricing page, and the roadmap itself is a document you own and update.
Before you start: a checklist
- A sponsor who will attend the monthly review, not just the kick-off
- A ranked list of use cases scored in the open
- Honest answers on data access, evaluation and platform readiness
- One named owner per phase, measured on the outcome
- Stop-point criteria written before each phase starts
- Build and run costs side by side for the first two phases
- An assumptions register with a date each assumption is checked
- A two-page format, so the roadmap is read rather than filed
Questions clients ask
- How far ahead should the roadmap go? Twelve months in outline, with only the current and next phase scoped in detail. Anything beyond that is a ranked list, not a plan.
- What if leadership wants the exciting use case first? Show the scores and the dependency on foundations. If they still insist, scope it as a time-boxed proof of concept with a stop point rather than a build.
- Who should own the roadmap as a whole? One person with budget authority, usually a COO, CPO or CIO, supported by the phase owners. Not a committee.
- How often should we change it? Monthly at the review, and at every stop point. Change is expected; the record of changes is the evidence the roadmap is alive.
Related reading
How much does AI development cost in 2026, what a six-week AI MVP actually contains, and build vs buy vs integrate.
Sequence foundations first, give every phase an owner and a stop point, and put running cost next to build cost; a roadmap built that way changes often and survives.
Frequently asked questions
What should an AI roadmap include?
▾
A foundations phase for data, evaluation, platform and governance; a ranked list of use cases with the first two scoped in detail; a named owner and a dated stop point per phase; and build and monthly running costs side by side.
How long should the first phase of an AI roadmap take?
▾
A foundations phase of four to six weeks is typical, followed by a first feature of six weeks or less. Longer first phases usually mean data or integration gaps that should be scoped separately.
Why do AI roadmaps fail?
▾
Features are planned before the data and platform they depend on, nobody owns the plan, running costs are omitted, and there is no defined point at which failing work is stopped.