The AI Roadmap at a Glance

Most AI roadmaps fail in the same way. They are organised by technology rather than by decision, so nobody can tell what has to be true before the next step is allowed to start. This is the version we run: nine workstreams, three horizons, and a defined answer to what done looks like at every intersection.

Two things make it work. The first is that every workstream starts in week one, in a small way, rather than waiting its turn. Governance written after the pilot is a post-mortem. Data work started before a use case exists is a project without an owner. The second is that the first horizon is deliberately cheap, because the point of week one is to earn the right to spend money in month two.

What the Standard Roadmap Gets Wrong

There is a version of this map that circulates widely: seven domains, an arrow from initial activities to advanced activities, two or three named activities in each row. It is a reasonable inventory of subject areas and we have used it as a checklist ourselves. As a plan it has six problems, and every one of them shows up in the same place, which is the gap between having an AI strategy and having AI value.

It reads as sequential when the failure is simultaneous. The arrow implies you finish the initial column and progress. In practice organisations stall between strategy and value indefinitely, and they stall for reasons the map treats as later-stage concerns: data quality, an operating model nobody redesigned, governance that arrived after the fact, adoption that never happened, and a return that cannot be evidenced. Those are not advanced activities. They are the reason the first use case did not land.

It is additive, and the hard decisions are subtractive. Every row tells you what to add. None tells you what to stop, refuse, or postpone. The hardest work in the first quarter is deciding what not to do, what genuinely has to come first, and where the organisation is actually willing to change how work gets done. A roadmap that only accumulates gives a steering committee no language for saying no, so nothing gets killed and everything gets slower.

There is no row for testing. This is the most concrete omission. Quality assurance for a system with a language model in it is not a solved problem, and the methods most engineering teams reach for do not fit: a unit test asserts a fixed output, and the thing you are testing does not have one. What you need instead is an evaluation set, the failure cases kept and re-run, and a sample of live output read by a person every week. If that is not on the roadmap it is not resourced, and the first serious error becomes a governance incident rather than a caught defect.

Design is missing entirely. With conventional software, design is a layer over known controls. With these systems you are designing turn taking, ambiguity, confidence, what happens when the answer is wrong, and how a person recovers from it. That is not decoration, it is how the system behaves and how anyone makes sense of it. Voice and conversational interfaces make this obvious, because none of the usual screen conventions are available. Leave design off the map and you get a technically working system that people quietly route around.

It treats culture as a workstream rather than the constraint. The technology can work perfectly and still produce almost no value if the people, the process and the accountability around it are not ready. Habits are the expensive part. A workforce plan and a community of practice, which is what the standard map offers here, are artefacts. Neither of them answers whether the team will actually change what they do on Monday, and that question deserves a test rather than a document.

It ignores what you inherit. Choose a platform and you are also choosing an operating model, a set of dependencies, a skills profile, and a question of who owns the thing in two years. Those inherited commitments outlive the use case that justified them. The difference between an organisation that builds a durable capability and one that accumulates complexity is usually a decision made in month two that nobody wrote down.

Our map is organised to answer those six. Every workstream starts in week one, including governance, testing and design. Testing and assurance and interaction design are rows in their own right, not sub-bullets of engineering. And the second column deliberately commits to two use cases, so that saying no is the default rather than an intervention.

How to Read the Map

The columns are not a schedule, they are levels of commitment. Week one is cheap and reversible: reading, counting, writing things down. The first 90 days commit real money to two use cases and no more than two. The third column only exists for the ones that passed, which in our experience is not all of them, and a roadmap that assumes otherwise is a budget request rather than a plan.

Baseline and value case

Nothing else on this roadmap can be judged without it. Cost the process as it runs today, in money and in hours, then size the opportunity against that number rather than against a vendor benchmark. Get finance to agree the measure in week one, because a saving they did not define is a saving they will not sign off later.

Done looks like: one page with today’s cost per transaction, the assumptions behind it, and the person in finance who agreed them.

Use-case portfolio

Most organisations have twenty ideas and no register. Put all of them in one place with a value estimate, a data dependency and an owner, then rank them. Charter two. The discipline that matters is writing the kill criteria at the start, so stopping is a decision rather than an embarrassment.

Done looks like: a ranked register, two chartered use cases, and a written condition under which each one stops.

Data readiness

Data work expands to fill whatever time you give it, so scope it to the two use cases you chartered and no further. The question is narrow: does the data exist, is it accurate enough, is it labelled, and are you allowed to use it this way. Everything else is documented and left alone until a use case needs it.

Done looks like: a per-use-case data verdict, and a fix list limited to what blocks the first two.

Build, buy or extend

Before evaluating anything, check what your existing vendors already ship, because a surprising amount of this is included in software you have already bought. Then score two genuine options against the same scenarios, and settle exit terms before signature rather than after. Cost per transaction at real volume is the number that decides it, not licence price.

Done looks like: a scored comparison on identical scenarios, a modelled cost per transaction, and agreed exit terms.

Delivery and engineering

Pilot one workflow, with a success threshold agreed before the work starts. The purpose of a pilot is to produce a decision, so it needs a baseline to be measured against and a date on which the decision gets made. Productionise only what passed, and hand it over with documentation, because a pilot nobody but the builder can run is not a result.

Done looks like: a live pilot measured against baseline, a dated go or no-go, and a clean handover.

Governance and guardrails

Write the guardrails before the pilot, not after the incident. Two things need to be on paper: what the model may not do, and who is accountable when it does something wrong anyway. Then decide where a person stays in the loop and what they are actually deciding, and log every error and escalation from the first day so you have evidence rather than anecdote.

Done looks like: a one-page policy, named accountability, defined human checkpoints, and an error log that is being used.

People, roles and adoption

Tools do not adopt themselves. Name an owner per use case, tell the affected teams plainly what changes for them, and train the people who will use it rather than the people who sponsored it. Where work genuinely left a role, redesign the role and reallocate the time, otherwise the saving stays theoretical and the headcount stays where it was.

Done looks like: an owner per use case, trained users, and a decision about the time that was freed.

Testing and assurance

Start by writing down the ten cases the system must get right, in the words a user would use, before anything is built. Those become an evaluation set, which is not a unit test suite: you are not asserting one correct string, you are checking that behaviour holds across cases you care about. Keep every failure you find, because the failures are the asset. Then re-run the whole set on every prompt change, model version and vendor update, and have a person read a sample of live output each week. Teams that skip this do not find out they have a quality problem until a customer does.

Done looks like: an evaluation set under version control, a kept library of failures, and a named person reading live output weekly.

Interaction design

Decide early what a user sees when the system is unsure, and what it is never allowed to answer on its own. Most of the design work in these systems is not the answer, it is everything around the answer: how confidence is shown, how a person disagrees with it, how they get back on track when it is wrong, and what the system does with a question it should refuse. Test that with the people who will actually use it rather than with the team that built it, then watch override and abandonment rates once it is live. People rarely complain about a bad AI interface, they just stop using it and go back to the spreadsheet.

Done looks like: a defined behaviour for uncertainty, a designed recovery path, and override and abandonment tracked as measures.

Where This Usually Goes Wrong

• The pilot has no baseline, so it produces a demo and an argument rather than a decision.
• Six use cases run at once, none with an owner senior enough to stop it.
• Data readiness becomes a programme of its own and outlives the use case that justified it.
• Governance arrives after the first incident, at which point it reads as blame.
• The saving is reported in effort rather than in money, so finance never books it.
• Nobody redesigns the role the work left, so the cost stays exactly where it was.
• Quality is assumed rather than evaluated, so the first bad answer becomes an incident.
• The interface is never designed, so people quietly go back to the spreadsheet.

What We Do With It

The free Baseline Findings Report covers the week-one column: the process costed as it runs today, the opportunity sized against it, the leaks ranked, peer benchmarks and a costed plan with owners. From there the AI use-case sprint charters the first two, and the pilot-to-production engagement takes one workflow into live use against a measured baseline. Prices for all three are published.