Before the pilot, write the decision

A pilot can be technically successful and commercially inconclusive. The system worked, the champion liked it, and the organization still has no reason—or no authority—to buy.

Before starting, I would write down the decision the pilot is meant to inform. Who will make it? What evidence do they need? Which resources would a deployment require? What other approval can still stop the project after the technical result is positive?

Three endings¶

For a hypothetical sensor trial, there are at least three useful endings. The measurement fails under representative conditions, and the team stops or redesigns it. The measurement works but cannot improve the workflow enough to justify adoption. Or the result clears both hurdles and supports a defined next commitment.

All three can be useful. A fourth ending—everyone agrees the technology is interesting and no one knows what to do next—is the one I would try to prevent.

I would not demand a purchase promise before every experiment. Sometimes the uncertainty is too fundamental. I would demand clarity about what remains unknown after success. If the pilot answers only a technical question, call it a technical evaluation and plan the commercial work separately.

The overlooked participant¶

The implementation owner often matters as much as the enthusiastic sponsor. Someone must make room in the operating schedule, train people, maintain the equipment, and own the result after the startup leaves.

Include that person before defining success. Otherwise the trial may optimize for a demonstration that the eventual operation cannot sustain. This is the smallest practical version of evaluating the whole workflow.