AI Roadmap Development

Sequence and dependency. A list says what you want; a roadmap says what order makes each subsequent item cheaper and why. The distinction is not academic. If initiative three requires a clean customer record, and initiative one happens to clean the customer record as a side effect, then doing one before three costs you nothing extra and doing three first costs you a data project. Most AI project lists are sorted by enthusiasm, which is why the second and third items always come in over budget — they are quietly paying for foundations that a different order would have delivered for free.

Twelve months of real detail, with a directional view beyond that and no pretence of precision past it. Anyone selling you a costed three-year AI roadmap in the current market is selling you fiction: the capability, the pricing and the vendor landscape have all moved substantially within twelve-month windows for several years running, and there is no sign of that settling. We plan the first two quarters tightly, the next two loosely, and set explicit review points where the plan is expected to change. A roadmap that has not changed in a year has not been used.

Four factors, weighed openly. Value, obviously. Feasibility on the systems and data you have today, not the ones in the architecture diagram. Dependency — does this build create an asset that later builds need, like a clean integration to your system of record or a document store worth querying. And organisational learning: the first build should be one your team can absorb, because its real job is teaching your organisation how to run AI in production. That last factor is why we frequently recommend a smaller first initiative than the client expects. The largest opportunity is rarely the right thing to attempt while nobody has done this before.

A kill criterion is a written statement of what would make you stop an initiative, agreed before it starts. For example: if accuracy on our historical test set does not exceed 90 per cent by week six, we stop and reassess. Without one, projects do not die — they linger, absorbing budget and credibility, because no individual has the standing to declare the thing a failure. Writing the criterion in advance removes the politics. Nobody has to be the person who killed it; the plan already said so. Every initiative on a roadmap we write has one, and it is the most-skipped step in the industry.

A named person in your business, or it will not survive contact with the next quarter. Every initiative gets a named internal owner, not a department — departments do not make decisions, people do. The roadmap also names who has authority to reprioritise it and when that review happens, typically quarterly. If you do not have anyone with the seniority and capacity to hold it, that is a genuine finding and we will say so; a fractional AI officer arrangement is one way to cover the gap, but hiring or promoting internally is usually the better long-term answer.

Parts of it will be, and the roadmap is written to expect that. We separate the durable layer from the volatile one. Durable: your data being accessible, your integrations existing, your governance being defined, your team knowing how to evaluate an AI system. Those investments pay off regardless of which model or vendor wins. Volatile: the specific model, the specific product, the specific technique. We deliberately avoid deep commitments in the volatile layer and design so those pieces can be swapped. If a capability you planned to build ships as a $30-a-month feature next quarter — which happens regularly — the roadmap should let you drop the build and take the feature, and ours is structured to make that a small decision rather than a sunk-cost argument.