Instead of slides, the sponsor shows decision-makers a working version, a prototype they can use or a process running on the floor, so the debate starts from something that exists.
An example
Twice, a manufacturing engineering manager at a brake-component plant supplying three automakers had lost the same capital request on slides. She wanted a camera system to inspect caliper castings, and plant leadership kept asking whether it would catch what the human inspectors caught. For the third round she skipped the deck. She bolted a borrowed camera and a used controller to the end of line four, ran it for two weeks alongside the inspectors, and asked the plant manager, the controller, and the quality director to stand at the line during a shift. They fed it castings from the scrap cage. It flagged eleven of twelve porosity defects, and the twelfth was one the inspectors themselves had argued about. The controller asked what a second line would cost. The request passed at the next monthly review, at the amount she had asked for a year earlier.
Why it works
Working versions make a proposal look better because decision-makers judge what they saw it do, and that is harder to discount than a projection. They also make saying yes easier: the question shifts from whether the idea can work to what it would take to scale, and nobody has to take the sponsor's word for anything. The move depends on a demonstration that runs under real conditions, an audience willing to come and look, and a gap between the demo and the full version small enough to state plainly.
The thinking behind it
Everett M. Rogers Everett Rogers's Diffusion of Innovations (1962; the fifth edition of 2003 names the attributes used here) lists characteristics that shape how fast an innovation is adopted, among them observability: innovations whose results are visible to others spread faster. A camera rig catching porosity defects at the end of a real line makes the result observable to the people who decide, which a slide describing the same result cannot do.
John P. Kotter In The Heart of Change: Real-Life Stories of How People Change Their Organizations (2002), Kotter and Dan Cohen argue that people change behavior more readily when shown something that makes them feel the problem than when given analysis alone. Their best-known example is a pile of gloves on a boardroom table. A working demo does the same for a solution: deciders standing at the line feeding it scrap castings feel the result in a way a deck never lets them.
When it fits
Reach for it when the idea is hard to picture, when earlier pitches died on the question of whether it would work, and when you can build something that runs for a modest sum or with parts you already have. It needs a setting that resembles real use and decision-makers who will give it half an hour in person. It helps little where the real dispute is cost or priority.
How to use it well
Build the smallest version that does the one thing skeptics doubt, and run it on real material, real data, or real customers. A staged sample proves nothing to anyone who matters.
- Ask the doubters what would convince them, and make the demo answer that question.
- Bring the decision-makers to it, or put it in their hands, and let them try to break it.
- Say out loud what the demo leaves out: scale, integration, support, and the cost of the full version.
- Have the full proposal ready for the moment someone asks what it would take.
Keep the demo running after the meeting if you can, since people who missed it will ask to see it.
What it costs and where it backfires
Good demos can raise expectations faster than the real program can meet them, and the distance between a prototype and an operating system is where budgets overrun. One that fails in front of the deciders costs you more than a deck would have. Building it uses time and goodwill borrowed from colleagues. The line is what the demo actually does. Hand-picking inputs it will pass, or hiding the manual work behind it, stages the result, and the deciders will find out when it scales.
When it is used on you
Test a rival's prototype on your own terms. Ask to feed it your own cases, ask what runs by hand behind it, and ask what the full version costs and how long it takes. Judge the demo on its hardest case and the proposal on its numbers, and say plainly which questions the demo left unanswered.