Most AI roadmaps are documents about the future. They contain phases, horizons, and a maturity curve. They get presented once and never referenced again.
A roadmap your team uses looks different. It is shorter, it names people, and every item on it has a number attached.
Short answer: a usable AI roadmap has five components. A ranked list of candidate workflows with current costs, a named owner for each, a sequence based on dependency rather than excitement, a decision gate after the first build, and a defined stopping condition. Anything longer than two pages is a strategy document, not a roadmap.
Start with the inventory, not the ambition
Before you sequence anything, you need a list of candidates with real numbers attached.
Go department by department and ask two questions. What repetitive work happens here every week, and what does it cost us in hours, delay, or lost opportunity.
You are looking for eight to fifteen candidates. Fewer means you have not looked hard enough. More means you are listing tasks rather than processes.
For each one, write down the current cost in whatever unit is honest. Hours per week. Average days to turn around. Enquiries that go unanswered. Error rate. If you cannot state a number, note that too, because “we do not measure this” is itself a finding worth acting on.
Rank before you sequence
Ranking and sequencing are different operations and most roadmaps collapse them.
Ranking is about value. Score each candidate on four dimensions, one to five.
| Dimension | The question |
|---|---|
| Value | What does changing this save or earn in a year |
| Feasibility | How clean is the data and how connectable are the systems |
| Risk | What is the worst outcome if the system gets it wrong |
| Adoption readiness | Will the people whose work changes support it |
Multiply rather than add. A candidate scoring 5 on value and 1 on adoption readiness should not outrank one scoring 4 across the board, and addition will let it.
Sequencing is about order. That depends on dependency, not score.
The sequencing rules
Rule one. First project is a proving project. Its job is to demonstrate the method and give the organization a picture. Choose the highest-ranked candidate that is also low risk and self-contained, even if a riskier one scores higher.
Rule two. Data foundations come before anything that depends on them. If three of your candidates all read from the same messy customer records, the cleanup is the first project, not the fourth.
Rule three. Do not run two builds simultaneously in your first quarter. Attention is the scarce resource in a mid-market company, not money.
Rule four. Governance precedes anything customer-facing. Approval thresholds and logging need to exist before a system talks to a client.
Rule five. Sequence by team, not just by process. Two projects landing on the same department in the same month will fail on adoption regardless of technical quality.
The 90-day shape
This is what the first quarter looks like when it works.
Days 1 to 15. Inventory and ranking. Baselines captured for the top three candidates. Owner named for the first project. Readiness scored across data, systems, people, and governance.
Days 16 to 30. Process mapping for the chosen workflow, including the exceptions your experienced staff handle by instinct. Approval rules defined. Success metric agreed and written down.
Days 31 to 60. Build and internal testing. The system drafts, a human approves everything. No autonomy in this phase.
Days 61 to 90. Live operation with the approval model in place. Log reviewed weekly. Comparison against the baseline number.
Day 90. The gate. Expand, adjust, or stop.
That last one matters. A roadmap without a stopping condition is a commitment, and commitments make people defend projects that are not working.
What belongs on the roadmap and what does not
Belongs: workflows, owners, baselines, target metrics, dependencies, decision gates, and dates.
Does not belong: tool names, vendor selections, model choices, or platform decisions. Those are implementation details that will change, and putting them on the roadmap invites the organization to debate them instead of debating what matters.
The moment a roadmap conversation becomes a discussion about which platform to standardize on, the roadmap has failed at its actual job.
Ownership, which is where these die
Every item needs a named person with allocated time. Not a department. Not a committee. A person, with hours.
The most reliable predictor of a stalled AI project in a Canadian mid-market company is an enthusiastic executive sponsor and no operational owner. The sponsor approves. The owner notices when the output goes strange in week seven.
If you cannot name an owner for a roadmap item, remove the item. Carrying unownable work makes the whole document less credible to the people reading it.
Reviewing without rewriting
Review the roadmap monthly against three questions.
- Did the current project hit its gate, and what did we learn
- Has anything changed the ranking, such as a new data source or a departure
- Is the next item still the right next item
Roadmaps that get rewritten every quarter were too detailed to begin with. Roadmaps that never change were not being used.
The version that fails
Worth naming so you can recognize it. The failed roadmap has three phases named foundation, expansion, and transformation. It covers eighteen months. It contains no numbers, no names, and no stopping conditions. It was produced by an outside firm and presented to a board.
It is not useless. It is a communication artifact, and sometimes that is what a company needs. It is just not a plan, and treating it as one is how organizations spend a year without producing a working system.
FAQ
How long should an AI roadmap be?
Two pages. If it needs an appendix, the appendix is the strategy document and the two pages are the roadmap.
Should the roadmap cover more than a year?
No. The technology and your own understanding will both change enough to make anything past two quarters speculative. Sequence the next two quarters properly and revisit.
Who should build it?
Whoever will own delivery, with input from the departments affected. An external advisor can facilitate and challenge the ranking, but a roadmap handed over rather than built with you rarely gets followed.
What if leadership wants a bigger ambition on paper?
Write the ambition separately as a position statement. Keep the roadmap operational. Mixing the two produces a document that serves neither purpose.
How do we know the ranking was right?
You do not, until after the first project. That is what the gate is for. Ranking is a starting hypothesis, not a conclusion.
Where to go next: Build the inventory first. Eight to fifteen candidates with real numbers takes about a week of asking, and it is the input everything else depends on.
