An AI roadmap is a short, ranked plan of what a business should automate first, and why. It is written in four steps: list the operational pain before naming any technology, map each pain to one specific capability, check the data, its owner and the cost of access, then sequence by impact so the first item is delivered within weeks.
Many AI roadmaps are already dead a few weeks after they are delivered. They contain twenty initiatives, four pillars, a glossary, and an executive summary that ages like warm milk. Here is how to write one that does not.
Start from the pain, not the trend
The bad roadmap starts with what AI can do. 'Generative AI, RAG, agents.' Then it goes looking for a place to put these things inside the business. By the time it lands on a real problem, it has lost three months and most of its credibility.
The good roadmap starts on the operations floor. Where is work being repeated? Which decisions depend on the one person nobody can afford to lose? Which questions does management ask weekly that take two days to answer? List these before the word AI appears anywhere.
Map each pain to a specific capability
For each pain, write the smallest possible AI capability that would reduce it. Not 'AI for sales', which is too abstract to commit to. 'A lead-scoring model that reads inbound forms and a year of email replies, scores them, and routes hot ones to sales within five minutes.' That is a capability.
If you cannot write the capability in one sentence with concrete inputs and outputs, you have not thought hard enough. The clarity exercise alone kills half the weak ideas on the list.
The constraint check
For each pain-capability pair, ask three questions: what data does this need, who owns it, what does it cost to access? Most ideas die here, and that is the point.
The data lives in six systems and nobody has API access. The owner is on parental leave. The field that matters has only been collected for three months. A roadmap that ignores these realities is theatre. A roadmap that lists them transparently next to each initiative is something an operator can actually plan against.
Sequence by impact, not ambition
The instinct is to put the most exciting item first. Resist it. The first item should be the one where data is ready, cost is low, and the team that has to use it actively wants it.
Early wins buy organisational trust for the bigger plays. A roadmap that begins with a six-month moonshot tends to be reviewed at month three by a CFO who has lost patience. A roadmap that begins with a useful four-week tool tends to be expanded at month two by the same CFO.
A roadmap that survives is short, specific, grounded in the actual state of the data, and sequenced so the first item is delivered within weeks. Three concrete bets beat twelve abstract pillars. The ones that work share another property: they are written with the operating team, not handed to them.