The Prototype-to-Product Decision Gate

Why prototypes stall

Most industrial AI pilots stall before production, and the common explanation — the model was not accurate enough — is almost never the reason. A prototype is judged on whether it works. A product is judged on what it does when things are not as the prototype assumed: the network is gone, the light is wrong, the operator disagrees, the hardware revision changed, the certification body asks who signed the safety case. None of those are model problems. All of them are decisions, and every one is cheaper to make before the prototype exists than after it works.

The five gates

Ordered by when the decision becomes irreversible, not by when teams usually get to it. Most teams reach gate 1 last.

1. Gate 1

   Degraded mode ownership

   When the system cannot do the smart thing, what does it do — and who decided that?

   Why it is first

   This is first because it is the only gate whose answer shapes the architecture. Retrofitting a degraded mode means changing where authority lives, which touches everything. Deciding it on day one costs a conversation.

   The test

   Name the person who owns the degraded behaviour and the document it is written in. If the answer is 'it falls back to manual' with no owner, the decision has not been made — it has been deferred to whoever is on shift when it happens.

   What it prevents

   A connected service that is excellent with signal and undefined without it. The product is not the feature; the product is the feature plus its absence.

2. Gate 2

   The variant decision

   Is your hardware and market variant count a decision, or an accumulation?

   Why it is first

   Variants multiply silently: a market, a trim, a hardware revision, a regulatory regime. Each one is defensible alone. The total is what kills the release train, and nobody ever chose the total.

   The test

   Write the number down. If nobody in the room can state it within one, the count is an accumulation and the roadmap is already fiction.

   What it prevents

   A validation matrix that grows faster than the team, so the last variant is always the one that slips — and it is always someone's primary market.

3. Gate 3

   Field survival, not demo survival

   What breaks when the environment is not what the demo assumed?

   Why it is first

   A demo is run by someone who wants it to work, in conditions chosen because it works there. Every one of those conditions is a hidden requirement, and they surface as field failures rather than as requirements.

   The test

   List the demo's implicit conditions — lighting, cleanliness, connectivity, operator skill, temperature — and ask which are guaranteed in the field. The ones that are not are your actual backlog.

   What it prevents

   A perception system validated indoors and deployed outdoors; a connector that works clean and fails dirty. Both pass their acceptance test.

4. Gate 4

   The scale delta

   What must be true at full deployment that is not true at pilot scale?

   Why it is first

   Some assumptions hold at ten units and break at ten thousand: manual intervention, per-unit configuration, anything requiring a person to look. They do not degrade gradually — they work until they do not.

   The test

   For each operational step, ask what it costs at target fleet size. Any step whose cost scales linearly with units is a launch blocker, not an optimisation.

   What it prevents

   A fleet you cannot recall, cannot update in one wave, and cannot diagnose remotely — discovered after the units are in the field.

5. Gate 5

   The signature

   Who signs the safety and compliance case, and when did they start?

   Why it is first

   Certification is a lead time, not a step. Under the Machinery Regulation, AI performing a safety function requires third-party assessment by a notified body rather than self-declaration — and that applies from 11 December 2027, fifteen months before the EU AI Act's Annex I deadline it is usually planned against.

   The test

   Name the assessor and the date they were engaged. If the answer is 'we will handle compliance later', the launch date is not real.

   What it prevents

   A finished product that cannot be placed on the market, discovered when the schedule has no slack left to absorb it.

Scoring your own programme

Not a maturity score. Each row is a signal you can check this week without instrumenting anything.

Where this comes from

These are the decisions that recurred across shipping software inside physical products: Deputy General Manager, Connected Car Services at the Renault-Nissan-Mitsubishi Alliance — product leadership on connected-services programs (Renault OpenR Link, NissanConnect), technology now deployed in 7M+ connected vehicles; and NDS/Cisco video platforms deployed at 100M+ scale. Different industries, the same five questions, and the same pattern of which one gets asked too late.

What this framework does not do

It does not tell you whether to build the product, and it will not rescue one whose value proposition is wrong — a well-governed programme can ship something nobody wants. It assumes a working prototype already exists. It is a set of questions, not a methodology or a certification, and it is deliberately short enough to use in a single meeting.