A pilot build gets treated like a checkpoint: schedule it, run it, celebrate that units came out, move on. But a pilot that only proves "we can build one" has wasted most of its value. The reason to do a pilot at all is to answer a harder question — is this process ready to scale? — and that question has to be asked on purpose, before the first unit is kitted.
Before the build, I want to know what we're trying to learn from it. That means writing down the questions in advance: Which steps are we least sure about? Which measurements will tell us the process is capable, not just functional? What would a result look like that says "stop, fix this before volume"? A pilot without those questions is just early production with worse tooling.
If you can't say what would make the pilot fail, you're not running a pilot — you're just building units early.
The single biggest waste in a pilot is building the units and only then realizing you didn't capture the data that would have explained the yield. Traceability, measurements, and defect capture have to be live on day one:
You only get to run the first pilot once. Un-instrumented, it answers almost nothing.
It's easy to fixate on whether the units work. But the pilot is really a test of the process: Did the work instructions survive contact with an operator who didn't design the product? Did the fixtures hold up over a full run? Where did people improvise because the documented step didn't match reality? Those improvisations are gold — each one is a place the process isn't actually defined yet, and every one of them will multiply at volume.
The worst time to define "good enough to ramp" is after the pilot, when there's schedule pressure and a pile of built units arguing for a yes. Set the exit criteria before you build — the yield gate, the capability numbers, the open-issue count you'll accept — and let the pilot data meet them or not. A pilot's real output isn't the units. It's an evidence-based answer to whether you should build ten thousand more.