An AI roadmap should promise quality bars, not features

A feature roadmap makes sense when a feature is either there or not. It was planned for the second quarter, it shipped in the second quarter or it slipped, and everyone understands the status of every line.

In an AI product every line is there almost at once. The contract summary works in week two. What does not exist yet is the version that is right often enough, on the contracts you actually sign, for anyone to rely on it. A roadmap that tracks features shows green for months on things nobody can use, and then the launch date arrives.

What goes wrong with feature lines

Status is binary and quality is not. “Contract summary: done” says nothing about amendments, scanned annexes or the three templates the legal team really uses. The steering committee hears done. The users experience something else, and the gap is found in production.

The date is attached to the predictable part. Building the feature is reasonably predictable. Reaching acceptable quality is not. A roadmap that dates the predictable part pushes all the risk into a phase that is not on the plan — usually called stabilisation, and never given an end date.

Weak results are answered with scope. With nothing to measure against, the response to a feature that is not quite good enough is another feature. The product grows sideways and nothing crosses the line. Every new line comes with a demo, so the report keeps looking better while the product does not.

What a line on a quality roadmap contains

A capability, defined by cases. Not “contract summary” but “summary of standard supply contracts, including amendments”, together with the set of real cases that defines it. If the cases are not written down, the capability is not defined.

A bar, agreed before the build. How often it must be right, which errors are tolerable and which are never acceptable — signed off by the person who owns the outcome rather than the person building it.

The current measured level. From the evaluation set, refreshed on every change. It replaces the status column, and it is the only column anyone needs to read.

A fallback. What the product does below the bar: hand the case to a person, decline, show the sources only. A capability that has not reached its bar can often ship in this narrower form, which is usually the honest version of an early release.

A decision date instead of a delivery date. The date by which you decide whether the bar is reachable at a reasonable cost: continue, narrow or drop. That is a date a team can actually keep.

Infographic

Feature roadmap and quality roadmap

Feature roadmap

• –A line is the name of a feature
• –Status: planned, in progress, done
• –Date promised for delivery
• –Weak results answered with more scope

Quality roadmap

• →A line is a capability defined by real cases
• →Status: measured level against an agreed bar
• →Date set for a continue-or-stop decision
• →Weak results answered by narrowing or a fallback

What “done” means here

Done for a probabilistic feature is not “it works”. It means the bar is met on the agreed cases, the never-list is clean, the fallback is in place, and the person who owns the outcome has looked at the remaining failures and accepted them.

The last condition matters most. Every AI feature ships with known failures. Done means somebody with the authority to do so decided which of them are acceptable, in writing, before users found them — not that the team stopped finding new ones.

How the conversation upstairs changes

Progress reports become numbers that move, or do not. That is uncomfortable for about a month and much easier afterwards, because “this is where we are on contracts with annexes, and the curve has flattened” is a conversation about a decision, while “it is nearly there” is a conversation about trust.

A line whose level has stopped moving for two review cycles is the most useful signal on the roadmap. It means the current approach has reached its limit, and the options are a different approach, a narrower capability or a different product. All of them are decisions. None of them is “more effort”.

It also changes what can be promised outside the team. Commitments to customers and to the rest of the business are made for capabilities that have crossed their bar, not for lines on a plan. The external roadmap gets shorter, and it becomes true.

The prerequisite

None of this works unless the evaluation set exists and runs on every change, which is why it is the first thing we build in AI-native apps engineering — and why, once something is in production, every step that widens it is justified by what the evaluation shows rather than by what the plan said.