Build an AI roadmap around release decisions
In short: An AI roadmap should fund the next release decision, not a feature list: four gates, each with named evidence, an accountable owner and a stop-or-go rule.
Google Cloud's guide to AI strategy, published 9 October 2024, rests on three fundamentals — vision, prioritisation and measurement — and sorts candidate use cases by value, actionability and feasibility. Sixteen months later, on 26 February 2026, the same company published what it had learned from moving its own go-to-market teams past pilots: the shift that worked was toward guided task completion inside work people already do. That account is vendor-reported experience, not evidence for every organisation.
The roadmap most teams write sits between them and belongs to neither: a list of model features with quarters attached. The claim here is that an AI roadmap should fund the next uncertainty-reducing release decision, not a feature list. Build it as four gates — discovery, bounded prototype, supervised pilot, rollout — each naming the evidence it needs, the person accountable for it, and the stop-or-go rule. What advances is whichever capability the evidence says deserves scale.
Score candidates on what you can measure today
Before any gate, a scorecard. It is deliberately short, and every cell you cannot fill is marked unmeasured rather than guessed; an unmeasured cell is a discovery task, not a reason to pick the loudest request.
| Criterion | What to record | Unmeasured means |
|---|---|---|
| Baseline task volume | tasks per week, from logs | you do not know the prize |
| User pain | time or error cost per task, observed | the value is a story |
| Accessible data | what exists, who owns it, what it may be used for | discovery first |
| Evaluation feasibility | can "accepted" be checked, and how | you cannot gate it |
| Consequence of a wrong output | reversible, costly, or regulated | sets the pilot's supervision |
| Adoption owner | the named person whose team changes how it works | nobody will use it |
| Total cost | build, run, review, exit — with assumptions stated | the number is a quote |
Prioritise on the filled rows. A candidate with three unmeasured cells is an argument for a two-week discovery, not a quarter of engineering.
The sourcing question — buy, configure, build — is a sub-decision inside the cost row, and it has its own method: one acceptance suite run against every option, exit cost included.
Four gates, each with evidence, owner and rule
Discovery ends when the scorecard rows are filled or honestly marked. Its owner is the adoption owner, because the people who will change their work are the ones who know the baseline. The bounded prototype ends when one end-to-end behaviour passes a held-out evaluation — the one described in evaluating an LLM feature before production — behind a stable interface, so the prototype's internals can be thrown away without the contract changing. The supervised pilot ends on two numbers: the share of tasks users actually accepted, and the cost of the failures a reviewer caught, both against a rule written before the pilot started. Rollout proceeds slice by slice, with a rehearsed rollback.
No gate carries a date. Each carries a stop-or-go criterion, and a roadmap that schedules the pilot before discovery has produced its evidence is a plan to be surprised on time.
Prototype fast without the debt following you into production
Fast prototyping and uncontrolled technical debt share one cause: shortcuts without an owner. Three rules keep the speed. Prototype one behaviour end to end behind the interface the product will keep; the model, the prompt and the retrieval can be crude, the boundary cannot. Retain the test fixtures, the logs and a teardown path from the first day, because a prototype you cannot remove is already production. And timebox every shortcut — a hard-coded prompt, a copied dataset, a skipped permission check — with a named owner and the condition under which it is removed.
This is the delivery counterpart to two earlier pieces: Minsky's two problem lists for choosing what to work on, and keeping one project running for a personal learning roadmap. This one is for a team with a budget.
The one-page roadmap I would write
No customer roadmap, delivery duration or return-on-investment case stands behind this; it is a planning exercise, labelled as such. Take a hypothetical request from a support team: "an AI that answers warranty questions". Discovery: pull last quarter's warranty-ticket volume and handling time from the help desk, list the policy documents and who owns them, and check whether a correct answer can be verified against the policy text. Bounded prototype: one behaviour — answer from the current policy with a citation, or decline — behind an API the help desk could call, with a dozen held-out tickets as the eval. Supervised pilot: four weeks, every answer reviewed before sending, rule written in advance: advance if reviewers accept most answers unchanged and no unsupported claim reaches a customer; stop if either fails. Kill condition stated on the page: if discovery cannot produce the baseline, the roadmap ends there and the team keeps its quarter.
Where this holds and where it breaks
It holds for teams funding AI inside an existing product or operation, where a baseline exists to be measured and an adoption owner can be named. It is weaker for genuinely new products with no baseline, where discovery is customer research and the first gate is longer. It breaks when leadership wants dates before evidence; then the roadmap becomes a feature list again, and the honest move is to show the unmeasured cells and ask which one they would like to fund.
FAQ
How is this different from an ordinary product roadmap?
Ordinary roadmaps schedule features. This one schedules decisions, because with AI features the main unknown — whether outputs will be accepted at acceptable failure cost — cannot be designed away, only measured.
Who owns a gate?
The adoption owner for discovery and pilot, engineering for the prototype, and whoever carries the failure cost for rollout.
What if the prototype is great but adoption is low?
Then the pilot has produced its evidence. Re-scope toward the task users actually accepted, or stop; the quarter saved is the roadmap working.
What's in it for you
- A seven-row prioritisation scorecard in which "unmeasured" is a legitimate, visible value.
- Four release gates with the evidence, owner and stop-or-go rule each must carry, and no invented dates.
- Three prototyping rules that keep the speed while giving every shortcut an owner and an exit.
Fund the next release decision, not the next feature: a roadmap is four gates with evidence, an owner and a stop rule, and the evidence decides what scales.
