5 ways to lose a pilot.

5 ways to lose a pilot.

Every founder makes these. Most of us don’t talk about them, which means the next person gets to discover them at full price.

All five from experience. None of them are the customer’s fault.

1. Run it without an end date.
A pilot with no finish line never fails, it just continues. Nobody has to say no, which means nobody has to say yes. Learning: agree the end date and what happens on it before you start.

2. Build for the user instead of the buyer.
We once built something a user told us they needed. Serious person, specific request, no budget authority. The feature shipped. They didn’t buy. Learning: find out who signs, and meet them early.

3. Succeed at something nobody was measured on.
The results are good and everyone agrees they’re good, but nobody’s objectives this year said “evaluate new software.” So it lands as interesting news rather than evidence for a decision someone needed to make. Learning: understand whose problem this is and what happens to them if it isn’t solved.

4. Leave deployment requirements beyond pilot until the end.
Pilots often run in the cloud because it’s easy for both sides. Full rollout might bring in additional legal, IT, and sometimes an on-prem requirement nobody mentioned while things were going well. Learning: agree on what deployment looks like after the pilot, before the pilot.

5. Prove it works and never prove it’s worth it.
You demonstrate the science beautifully, and nobody converts it into a number a finance function recognizes. Learning: agree upfront what metric this moves and who reports it.

The ones that converted cleanly looked different from day one. Defined timeline, KPIs agreed before we started, checkpoints along the way, and a written report at the end putting a value on what changed.

None of it is clever. It’s just expensive to learn on your own.

‍