A roadmap is what separates AI adoption from a series of enthusiastic experiments. It sequences the work, names who owns each part, sets the gates that must be passed before anything scales, and defines how the business will know whether it is working.
This guide covers how to build one that fits on a page: the phases, the gates, the sequencing logic, and the mistakes that turn a roadmap into a document nobody opens. It is the companion to How to Adopt AI in a Small Business.
A roadmap is not a list of everything you might do with AI. It is the order in which you will do a small number of things, and what has to be true before each one starts.
What belongs on a roadmap
Five elements, and nothing else.
- The use cases, in sequence, with one starting now.
- The owner for each, by name.
- The gates — policy, data rules, verification — that must hold before a use case scales.
- The measurement for each use case, defined before it starts.
- The review dates, so continuing is a decision rather than a default.
Anything more ambitious than this becomes a plan, and plans for AI adoption have a poor record because they assume a certainty about outcomes that does not exist.
The phases
A workable sequence has four phases.
| Phase | Focus | Typical duration | Exit condition |
|---|---|---|---|
| Foundation | Readiness, policy, data rules, one chosen use case | 3–4 weeks | Rules published; use case chosen and owned |
| Pilot | One contained workflow, run for real, measured | 6–8 weeks | Baseline beaten; corrections understood |
| Scale | Second and third use cases; playbooks and training | 1–2 quarters | Two workflows adopted without prompting |
| Sustain | Maintenance, refreshers, retiring what does not work | Ongoing | Measures reported monthly |
The Foundation phase is the one businesses skip, and it is the reason pilots fail. It is also the cheapest phase: a policy, a data rule, a chosen use case and a baseline.
The gates
Gates are what stop the roadmap from outrunning the controls.
- Gate 1 — Policy before scale. No use case spreads beyond its pilot team until an acceptable-use policy exists and has been circulated.
- Gate 2 — Data rules before real data. No confidential information enters a tool until the data rule is agreed and staff have been told it.
- Gate 3 — Verification before external output. Nothing drafted with AI reaches a client, a filing or a decision until a named person has verified it and recorded the check.
- Gate 4 — Measurement before continuation. A use case is only extended if the measures show a result, or if the failure is understood and worth another attempt.
Four gates, each a sentence. They are what make the roadmap defensible rather than merely optimistic.
Sequencing the use cases
Sequence matters more than selection once more than one use case is in play.
- Do the function with the clearest verification first. Correctness that is easy to establish produces confidence fast.
- Do the function with the most willing owner second. Voluntary adoption is faster than mandated adoption.
- Delay anything cross-functional. A use case spanning two teams and three systems is a third-phase project.
- Repeat the pattern. Each use case should reuse the previous one’s playbook format, data rule and check.
A typical small-business sequence: recurring document production, then one function-specific use case such as sales research or support drafting, then marketing content at volume, then research and analysis.
Putting it on a page
A roadmap that fits on a page tends to look like this.
| Quarter | Use case | Owner | Gate status | Measure |
|---|---|---|---|---|
| Q1 | Draft monthly client report commentary | Client lead | Policy published | Cycle time, corrections |
| Q2 | Research briefs for new prospects | Sales lead | Data rule agreed | Briefs per week, citation errors |
| Q3 | Support response drafting | Support lead | Verification recorded | Response time, escalation rate |
| Q4 | Marketing content at volume | Marketing lead | Disclosure position set | Assets per week, claim corrections |
Four rows, one page, and a document that gets used. Each row carries the same four fields, which is what makes progress visible at a glance.
Keeping the roadmap honest
Three practices keep a roadmap from becoming a wish list.
- Review monthly, and change the plan when the evidence says so.
- Report failures alongside successes, including the use case that was stopped and why.
- Keep the gates visible, so no one is surprised when a scale-up is paused for a missing policy.
A roadmap that never changes is not evidence of discipline; it is evidence that nobody is reading the results.
A worked roadmap for a services firm
A fourteen-person consultancy adopting AI over its first year.
Q1 — Foundation and pilot. Readiness assessment scores workable except on policy (a one-page policy is published in week two). The first use case is drafting the narrative commentary in the monthly client report from frozen figures. Owner: the client delivery lead. Baseline captured: fourteen hours per report cycle, of which five are narrative drafting. Measure: cycle time and corrections per report.
Q2 — Second use case. Research briefs for new prospects, bounded to eight named sources per brief, with every citation opened. Owner: the business development lead. Gate passed: the data rule for client names has been agreed. Measure: briefs produced, citation errors, proposal win rate over two quarters.
Q3 — Third use case and training. Meeting notes into structured actions, plus the six-week training curriculum delivered to both teams. Owner: the operations manager. Gate passed: verification is now recorded on client-facing output.
Q4 — Sustain and review. Monthly measures reported; prompts refreshed; the two use cases that did not work are documented and retired. The roadmap for year two is built from what was learned.
Four rows of a page, one gate closed per quarter, and a program that produces evidence rather than a slide.
Who does the work
A roadmap names the work; the work needs people. At small-business scale, four roles cover it.
- The sponsor — accountable overall, approves the policy and the exceptions, asks for the measures.
- The program owner — keeps the roadmap current, closes the gates, reports monthly.
- The use-case owners — one per use case, accountable for the workflow and the output.
- The champions — practitioners who help their colleagues run the workflow.
Two anti-patterns to avoid. First, the sponsor who delegates everything, including the questions that require their authority: policy approval and exception handling are not delegable. Second, the program owner who is also every use-case owner, which creates a bottleneck at the first absence.
Common mistakes
- Skipping the Foundation phase. The pilot then fails for reasons unrelated to AI.
- No gates. Use cases spread before the controls exist.
- No owners by name. Each use case belongs to everyone, which means no one.
- No measurement defined up front. Continuation decisions become arguments.
- Too many parallel use cases. Three half-built workflows teach less than one working one.
- A roadmap nobody reviews. The plan and the reality diverge quietly.
Frequently asked questions
What should an AI adoption roadmap contain?
The use cases in sequence with a named owner each, the gates that must hold before scaling, the measurement for each, and the review dates. One page is enough.
How long should an AI adoption roadmap cover?
Twelve months, reviewed monthly. A longer horizon assumes a certainty about AI outcomes that does not exist.
What are the gates in an AI roadmap?
Policy before scale, data rules before real data, verification before external output, and measurement before continuation.
Should we plan to adopt AI across the whole business?
Eventually, perhaps. The roadmap should sequence it: one contained use case at a time, each reusing the previous one’s playbook, data rule and check.
Who owns the roadmap?
One accountable person, usually the executive sponsor or the transformation lead, with a named owner per use case. A committee produces discussion rather than a schedule.
How do we handle a use case that fails?
Report it, identify whether the cause was the choice, the workflow, the data or the training, and adjust the roadmap. A stopped use case with a documented cause is the program working, not failing.
How many use cases should run at once?
One in pilot, one being planned. Running three in parallel produces three half-adopted workflows and no reliable evidence about which approach works.
Do we need a formal program office?
No. At small-business scale a sponsor, a program owner and a use-case owner per workflow are sufficient. The formality that matters is the gates, not the governance chart.
Next step
Write the four-row roadmap, agree the gates, and start the Foundation phase this month. See A 90-Day AI Adoption Plan for the delivery detail, or book an AI adoption call to build the roadmap with you.
Sources
- Roadmap structure reflects standard program-delivery practice applied to AI adoption: phased sequence, named owners, gating controls, and measurement defined before change.
No statistic in this article is invented; where figures appear in the linked guides, they are cited there with their source and date.