The Minimum Viable Pilot
Start with the decision, not the model.
Most AI initiatives don’t fail outright. They stall. They start wide, take months to reach a verdict, and stay far from the people who make the decisions.
The fastest route to a full implementation is the narrowest real start: one decision, or a small set of closely related ones, in front of the people who make them, judged honestly within weeks. Quick feedback builds momentum. Momentum, more than ambition, is what carries a pilot into operations.
The problem: big pilots, slow verdicts
The typical AI pilot is scoped to impress. It promises to transform disruption recovery, or claims handling, or network planning. It takes a quarter to build and another to evaluate. By the time a verdict arrives, the sponsor has moved on and the budget cycle has closed.
Worse, these pilots are usually judged in the boardroom, not on the operations floor. The demo looks good. The people who would have to trust the system every day never see it until it is nearly finished.
The pattern has a shape. A model-first pilot climbs quickly, then flattens at a ceiling: the logic still lives in experienced people, nobody has defined what the system may decide, and no single system sees the whole decision. The cruel part is timing. The funding decision is usually made early, while the model-first path still looks better than the slower, architecture-first alternative.
Redefining the minimum viable pilot
In 2011, Eric Ries’s The Lean Startup taught founders to stop building finished products in the dark: release a minimum viable product, watch how real customers respond, and learn before building more. Build, measure, learn replaced the big up-front plan.
The same discipline is overdue in operational AI, with one change. Not a minimum viable product, but a minimum viable pilot, built around a minimum viable decision set. Not the smallest model. Not the smallest platform. The smallest real set of decisions that matters.
The test of scope is not a number. It is whether the set is the smallest that teaches you how the operation decides. Sometimes that is one decision. Often it is two or three that share the same data, rules and people.
A minimum viable pilot has four parts:
- A narrow decision set: one decision, or a few closely related ones, that operators make often enough to generate feedback.
- A deliberately narrow right. Usually “recommend,” never “execute.”
- Explicit bounds and a named person who commits the decision.
- A baseline that the results will be judged against.
The difference is easiest to see in an example. “AI for disruption recovery” is a program. “Recommend how to rebook passengers after a missed connection, and whether to put them in a hotel when nothing leaves the same day, with the duty manager committing every decision” is a pilot. One takes a year to prove. The other can show you something real in weeks. The rest of this essay follows that rebooking pilot.
Choosing the decision set
The choice of decisions does most of the work. A good first set passes five tests.
It happens often. A decision made a few times a year cannot generate feedback fast enough to learn from; one made dozens of times a day can. It matters. If nobody cares whether it improves, nobody will notice when it does. The data already exists. A pilot that first needs a new data platform is not minimum. It has an owner: a named person who makes the decisions today and is willing to commit, or override, every recommendation. And the decisions belong together. If they don’t share data, rules and an owner, they are two pilots, not one.
Missed-connection rebooking passes all five. It happens every day, it costs real money and goodwill when it goes wrong, the booking and schedule data is already there, the duty manager already owns it, and the flight choice and the hotel choice draw on the same information and the same judgment.
Why narrow wins
Narrow sounds unambitious. In practice it is the most ambitious choice available, because it is the one most likely to reach production.
A narrow decision set can be in front of users in weeks and judged within weeks more; wide pilots often take six months or more to reach a verdict. For the rebooking pilot, that might mean the decisions mapped in five weeks, live with duty managers by week ten, and a verdict by week fifteen.
Because the system can only recommend, a bad recommendation costs almost nothing: the duty manager still commits, and the operation never depends on an unproven system. With one decision or a tight set, success is measurable and failure is diagnosable. With ten unrelated ones, every result is arguable. And the people who make the decision help shape the system instead of receiving it, which is the difference between adoption and resistance.
Narrow is also cheap, and that is not a compromise. It is the point. A narrow pilot costs a fraction of a platform program, so if the idea is wrong you have bought a lesson, not a write-off. Spend can follow evidence: a small first tranche, with the next released only when the results earn it. The CFO funds proof, not promises. A small investment also avoids the sunk-cost trap, leaving you free to stop or change course without losing face. And it keeps you clear of premature commitments: no platform purchase, multi-year license or reorganization before the first decisions have proved the value.
Users are the architecture’s best source
The most valuable output of a narrow pilot is not the model’s accuracy. It is what the users teach you.
Every override, every objection, every “it doesn’t know that” reveals something the design was missing. In the rebooking pilot, it might be a rule nobody wrote down (never split a family across flights), an exception only the night shift knows (one terminal’s connections run long after 10 p.m.), or a boundary of authority that was assumed rather than defined (who may approve a rebooking into a higher cabin). That is logic mapping, happening under live conditions instead of in a workshop.
The counterintuitive lesson is that you learn more from where users reject a recommendation than from where they accept it. Acceptance confirms what you already knew. Rejection shows you where the real operation lives, and it turns tacit judgment into explicit design.
Judging the results
A narrow pilot is only useful if it is judged honestly. Measure the decision, not the model. For the rebooking pilot:
- Acceptance rate: how often the duty manager accepted the recommended flight or hotel, and why it was overridden when it wasn’t.
- Time to decision: minutes from missed connection to confirmed rebooking, before and after.
- Outcome against the baseline: passengers reaching their destination on time, hotel and compensation costs, complaints.
- Escalations: did the hard cases, such as large groups, unaccompanied minors and the last flight of the day, come back to a person?
- Operator trust, through a short, structured check-in rather than a survey.
- Cost per lesson learned. A pilot that answers a big question cheaply is a success, even when the answer is no.
Agree on the go, adjust and stop criteria before the pilot starts, not after the results are in. A clear stop is also a good outcome: it was fast, it was cheap, and it saved you from a much larger mistake.
Feedback as momentum
Short feedback cycles compound. Each one builds trust, because users see their input change the system and lean in rather than work around it. Each one builds evidence, as real operating data replaces the assumptions the business case was built on. And each one builds sponsor confidence: early, defensible results a sponsor can point to.
Momentum is the real asset of a pilot. A small, visible win makes the next tranche easier to approve than any business case could. A narrow success funds the next decision far more easily than a broad promise funds the first.
From a narrow start to a full implementation
A successful minimum viable pilot is not the end state. It is the foundation, and it widens in deliberate steps. First come adjacent decisions that share the same data, rules and people: rebooking after a missed connection leads naturally to proactive rebooking before the connection is missed, and then to compensation. Next come wider bounds where the evidence supports them: a decision that has earned trust can move from “recommend” to “execute in bounds,” with monitoring and a clear path back to a person. Then come more integrations and controls as the stakes rise: audit trails, escalation paths, and performance measured against the baseline.
The architecture built for the first decisions becomes the scaffolding for many. This is how the architecture-first path breaks through the ceiling that stops model-first pilots: slower at the very start, then steadily ahead.
Two mistakes worth naming
The first is running the pilot away from its owners. A pilot built in an innovation lab and handed to operations at the end has skipped the part that matters most. The second is granting execute rights too early. Autonomy should be earned by evidence, not granted by enthusiasm.
Start narrow
Ambition is where you are going. Narrowness is how you get there quickly. Spend small to learn fast, and spend big only on what has already proved itself.
The organizations that get AI into operations are rarely the ones with the boldest programs. They are the ones that put a few real decisions, sometimes just one, in front of the people who make them, listened carefully, and built from there.
If you have a decision that matters, bring it to us. We will help you find the narrowest real place to start.