The Pilot, the Proof and the Patience

If you'd asked me twenty years ago what a pilot was for, I'd have told you it was to prove that the technology worked. Test the software, iron out the bugs, confirm it doesn't fall over under real conditions. That's a necessary part of the answer, but it misses the part I now watch most closely. A pilot's actual job is something quieter and, frankly, more important. It's there to prove that people will change their behaviour because of it. Technical reliability still matters, of course. It just cannot tell you whether anyone finds the thing useful.

That distinction matters more than it sounds like it should. Technical proof and behavioural proof look similar from a distance, but they're answering entirely different questions. Technical proof asks, does this work? Behavioural proof asks, will anyone actually let it change how they operate? You can pass the first test and fail the second one completely, and in my experience, that's exactly where most well-built systems go to die, unloved on a server somewhere, technically flawless and operationally invisible.

So the pilots we run now are deliberately small, and deliberately patient, in a way that used to make me uncomfortable. We start in one location. We watch, closely, for signs that are easy to miss if you're not looking for them specifically. Does someone check the tool without being reminded to? Does it come up naturally in a conversation between two managers who have no idea we're listening? Does someone, unprompted, ask if their site can have it too?

Those three things matter more to me now than almost any usage statistic I could pull from a system log. A login count tells you someone opened a screen. It doesn't tell you they believed what they saw, or that it changed a single decision they made that day. I've learned to be quite suspicious of metrics that are easy to measure and slightly less certain of what they're actually proving.

There's a particular approach to pilot store selection I've settled on over the years, mostly through trial and error. As the pilot expands, I try to include somewhere that's honestly a bit difficult, rather than only the easiest sites with enthusiastic managers and calm operations. A site with more turnover, more pressure, a manager who's sceptical rather than eager. It's less comfortable, and it's far more truthful. A pilot that only ever gets tested somewhere easy tells you what's possible in ideal conditions, which is a piece of information you'll rarely get to use again once you're rolling out across thirty sites that are anything but ideal.

Patience is the part I find hardest to defend to people who haven't lived through a failed rollout. Everyone, myself included on my more impatient days, wants to move from one successful store to the whole estate as quickly as possible. But I've watched what happens when that jump is made too early, and it isn't pretty. Instability that would have been a minor footnote in one location becomes a full crisis of confidence across thirty of them, all at once, and confidence, once it collapses at scale, is brutally expensive to rebuild.

So the sequence I've made peace with looks something like this. Prove it in one place. Watch for the quiet, unglamorous signs that people actually trust it. Expand to a small handful of sites that are different enough from each other to tell you something new. Once that's held up, you have something worth taking to leadership alongside the documentation and controls the work already needs. The leadership summary, when it finally arrives, isn't the beginning of the story. It's practically the epilogue, because by that point the story has already proven itself where it actually mattered.

The other thing a small pilot gives you is permission to be honest. When thirty sites are waiting for a rollout, every problem starts feeling political. In one or two sites, a problem is still just a problem. You can admit the screen is confusing, change the workflow and try again without writing an incident update or defending the original design. That freedom is worth protecting for as long as you can.

It also gives the people in the pilot a different relationship with the work. They are not passive recipients of a finished system. They are helping shape it. That does not mean every suggestion becomes a feature, which would be another reliable route to disaster, but it means the final thing carries evidence of real use inside it. By the time you scale, you are no longer asking the rest of the business to trust your theory. You are asking them to try something their colleagues have already tried and tested in the real world.