Give the Pilot a Path to an Operating Decision

At XTIUM, during the integration from Chapter 4, we built an automated sales assistant that coached reps by voice. I tested it week after week. In those tests, it worked well. Then the post-launch review came back. Almost no one was using it. The gap surfaced at a routine engineering stand-up, and our CRO, the executive responsible for getting reps to use it, was not on the call, so the people looking at the data were not the people who could act on it. Only a handful of reps had logged in consistently, and the strongest performers were using it. Many of the reps we hoped it would help weren't. The pattern told us who had found a reason to use it. It didn't tell us whether the tool improved a struggling rep's results. Reps had been consulted, managers briefed, the CRO supportive in meetings. But involvement in a build and consistent use afterward are different commitments. We pushed, adoption picked up, and it was still short of where we wanted it when I moved on. The pilot graveyard is the last place key-person dependency hides, and with the sales assistant, the person keeping it alive was me.

At Infrascale, the finance team was moving off NetSuite, a perfectly capable system, because they had over-customized even a SaaS product and built Frankenstein. The CFO swung to the other extreme: a strict out-of-the-box Sage Intacct implementation with no input from her team. She brought the pendulum back toward the middle, got her team involved, and the rollout succeeded. It is a little like the joke that you never plug in a USB cord on the first two tries. It is always the third.

This one is from the public record; I was not in the room at AT&T. In Microsoft's November 2025 account of Ask AT&T, what matters is not the 71 solutions in use but that every new agent went through legal, security, and finance reviews before launch. AT&T described required human checkpoints, logs of agent actions, and access controls in its agent workflows. I would test those arrangements with a failed service update, run with the original builder out of the routine path.

A working tool does not create its own adoption. A leader's agreement to try a useful idea is not an adoption plan. Faster building can create more pilots than the business has capacity to operate, and every launch without an operating owner adds a dependency. So the business case and the rollout plan travel together before the pilot begins: training, use, value, ownership of adoption and the result, controls, and what must be true before the next stage is funded. Before you call nonuse resistance, watch someone try to do the work. If the tool does not improve the work, fix it or stop. Requiring people to log in cannot prove the tool helps them.

Five records, views of one commitment: the Commitments Before Scale Canvas as front page, the Executive Adoption Contract, the Implementation Governance Charter, the Production Workflow Map, and the Production Gate. The book's worked example is the day-90 review record for the support workflow from Module 5: decision and date, evidence, operating commitment, and next step, written before the trial begins.

If the pilot is yours to fund, record the production owner, funded support, evidence of use and customer benefit, necessary controls, and the date the pilot must earn its next stage, and name what would lead you to scale, extend for specific proof, redesign, or stop. If you are the manager who agreed to try the tool, decide whether you agreed to try a tool or to change how your team works, and inspect that. If the tool was built for your work and sits unused, explain what the tool changes in your work and what evidence would show that change is useful.

There is no fifth option called "keep going and hope it works out."