Building an AI roadmap: from experiment to production

Ask ten small businesses for their AI roadmap and eight of them will hand over a ranked list: chatbot, then CV screening, then a planning tool, then something with invoices. That is not a roadmap. It is a wish list with numbers next to it. A roadmap is a sequence: what starts now, what has to be true before the next thing starts, and what production actually means for the first item before you touch the second.

Why ranked lists fail quietly

A ranked list assumes every item is independent, and that finishing number one has nothing to do with whether number two succeeds. In practice the opposite is almost always true. The CV-screening tool at position two needs clean, structured candidate data, and if the chatbot at position one never got anyone to actually log what customers ask, nothing about position one produced the muscle memory position two depends on. Ranked lists look organised on a slide and fall apart the moment someone asks "what changes on Monday."

AI-roadmap, as we define it elsewhere on the site, sets out which applications an organisation will build, in what order, and what each one requires in people, data and decisions. The order and the requirements are not decoration. They are the actual content of the plan. A roadmap without them is a list.

The rhythm: small first, prove it, then build further

Radical's own working rhythm for every roadmap we help build is the same three-step pattern, applied per item, not once for the whole plan: start small, prove the value, then build further. Not because it is a nice slogan, but because each step answers a question the next step depends on.

Start small means picking one narrow, bounded use inside one team, not "AI for customer service" but "AI drafts the first reply to a returns question, a person still sends it." Narrow enough that it can be running within weeks, not quarters, and narrow enough that if it fails, it fails cheaply and visibly instead of quietly inside a six-month integration project.

Prove the value means measuring something concrete before deciding whether to expand: how many replies did the tool draft, how many needed heavy editing, how much time did the team actually save versus how much time did they spend correcting it. This step is where most roadmaps quietly die, not because the tool failed, but because nobody defined in advance what "it worked" would look like, so nobody can say afterward whether it did.

Build further only starts once the second step has an answer. That might mean widening the same tool to a second team, or it might mean the answer was "it saved four minutes per ticket but broke trust with customers three times," in which case building further means fixing the specific failure, not doubling down on the whole idea.

Two people at a whiteboard. A usable roadmap names an owner and a date per step.

What "production" actually means

Production does not mean impressive. It means the tool runs without someone from Radical, or from your own AI-enthusiast employee, sitting next to it correcting outputs by hand. A demo that works beautifully in a meeting room with the person who built it present is not in production. A tool that a new hire can pick up from documentation, that has a known failure mode with a known fallback, and that keeps running when its builder is on holiday, is in production.

That distinction matters for the roadmap specifically because it defines what counts as "done" for step one before step two is allowed to start. Skipping it is the single most common reason a roadmap has five items listed and zero of them actually running a year later: everything is permanently "almost in production," so nothing ever frees up the attention needed for the next item.

A roadmap entry, written the way it should be

A usable roadmap names an owner and a date per step, not per project. Concretely, one line in a real roadmap looks like this:

"Item: AI-drafted first reply for returns questions. Owner: support team lead. Starts: week of 7 September. Proof required by 5 October: average reply-draft time under 90 seconds, human edit rate under 30 percent, zero customer complaints traceable to the draft. Decision point: 5 October, expand to shipping questions or fix edit rate first."

Compare that to "chatbot for customer service, Q3." The second version cannot be checked, cannot be blocked, and cannot tell anyone in October whether it succeeded. The first version can be checked by anyone, including someone who was not in the room when it was written.

A monitor in a dim office. Production means the tool runs without someone from Radical in the room.

The most common way roadmaps get skipped entirely

The failure mode we see most often is not a badly written roadmap, it is no roadmap at all, replaced by whatever tool a consultant demoed most recently. A business gets shown an impressive chatbot pilot, likes it, and starts building it without ever asking whether a chatbot was the first thing that should have been built, or just the first thing someone happened to pitch. This is the same trap covered in Waarom een adviesrapport geen capability is: a compelling one-off demo is not evidence that an item belongs first on the list, only that it is possible to build.

A roadmap forces the opposite question before any building starts: given everything this business could plausibly automate, what is the one item where starting small costs the least and proves the most? That is a sequencing decision, and it has to happen before any specific tool gets chosen, not after.

Why this differs from a project timeline

A project timeline assumes the work is known and the risk is execution speed. An AI roadmap assumes the opposite: the biggest unknown is whether a given use case will actually deliver value once real users touch it, not how fast a team can build the code. That is why each step ends in a decision point rather than a delivery date. A project plan says "launch on 5 October." A roadmap says "decide on 5 October, based on what we actually measured, whether this expands or gets fixed first." The second framing is less comfortable to present in a slide deck and considerably more likely to be followed, because it does not pretend to know in August what will be true in October.

Wish list versus roadmap entry, side by side

The RAND Corporation's 2024 research on AI project failure found that the majority of AI pilots never reach production, and the root causes it identifies are organisational, not technical: unclear ownership, no agreed definition of success, and no decision process for what happens after a pilot runs. Those are exactly the three gaps a wish list leaves open and a roadmap entry closes by construction. A roadmap does not prevent every failure, but it makes failure visible and specific instead of silent and permanent.

About this page

The roadmap definition referenced above (owner, date, requirement per step) matches the existing AI-roadmap definition page on this site. The small-first, prove-it, build-further rhythm is Radical's own working method, not an external framework. The failure-cause reference is the RAND Corporation report cited below. Written by Radical's own team; no client data was used.