Insight
The case against the three-year AI roadmap
Roadmaps built for board approval optimise for looking complete. What you want is something in real use before the assumptions expire.
A three-year AI roadmap is a document designed to survive a board meeting. It has phases, it has dependencies, it has a capability model, and it implies that the organisation writing it knows what AI will be able to do in year three.
Nobody knows what AI will be able to do in year three. That is not a criticism of anyone’s planning — it is the honest state of a field where the capability frontier has moved substantially every few months for several years running.
What the roadmap is really for
Long roadmaps solve a real problem: they get budget approved. The trouble is that the artefact built to unlock funding then becomes the plan of record, and the organisation spends eighteen months executing assumptions that were provisional when they were written.
By the time phase two begins, the tooling that made phase one hard is often free.
The alternative is not “no planning”
The alternative is planning at two different time horizons and being honest about which is which.
- Direction, three years out. Where should AI change how this business works? Which processes, which decisions, which customer experiences? This is strategy, it should be stable, and it should be about a page.
- Commitment, one quarter out. What are we building, who owns it, what does it cost, and how will we know if it worked? This is a plan, and it should be specific enough to be wrong.
What breaks organisations is treating the three-year document as though it were the one-quarter document — committing budget and headcount against a shape of the world that has already moved.
What “fast to start” actually means
It does not mean rushing, and it does not mean skipping the business case. It means the first version is in the hands of real users while the assumptions behind it are still current, so what you learn is still actionable.
In practice that is a first version in weeks, deliberately narrow, deployed to a team small enough to talk to directly. Then a decision, made with evidence, about whether to widen it, change it, or stop.
Stopping is a legitimate outcome, and one of the strongest arguments for building small first: a narrow project you can cancel after ten weeks costs a fraction of a broad one you cannot cancel without an internal reputation event.
The uncomfortable part
This approach produces less impressive documents. There is no capability heat map. There is a thing that works, used by eleven people in the service department, and a number showing what it did to their handling time.
In our experience that is worth considerably more in the second budget conversation than the heat map was in the first.