Count the pilots you stopped

Most AI programmes have a pilot problem. Not too few. Too many, all of them alive, none of them finished.

A pilot is supposed to answer one question: is this worth scaling? In practice many pilots answer a different question, which is how long a small team can keep a demo running before anyone asks what it is for. The answer is usually longer than anyone planned.

The exit date comes first

The fix is boring. Before a pilot starts, it gets three things written down:

1. The business problem, in a sentence a plant manager would recognise.
2. The number that has to move, and by how much, for the pilot to scale.
3. The date on which we decide to scale it or stop it.

On that date, there is a decision. Not an extension, not a “phase two discovery”. A decision.

Why stopping counts as progress

Stopping a pilot frees the people, the budget and the GPU allocation for the next idea. It also tells the organisation that the pipeline is real: ideas go in, some come out the other side into production, and the rest are retired without anyone losing face.

That is the logic behind Digit-AI, the framework I built to move use cases from idea to production. Most of its value is in the gates, not in the models. A use case that cannot pass the first gate (name the cost you remove or the revenue you add) does not need a model at all.

The metric

So alongside “use cases in production”, track “pilots stopped on schedule”. When the second number goes to zero, it does not mean everything is working. It means nobody is deciding.

A healthy pipeline has a graveyard. Keep yours tidy.