Preparing a Customer-Driven Demo
In customer control, the customer holds the keyboard and types the inputs they would use in their actual work.
The Instinct to Make the Demo Look Good
When a team prepares for a customer demo, the natural goal is to make the product look good. The presenter knows the product well, knows which screens are impressive, and knows which inputs will produce clean results. It is tempting to sit at the keyboard, move smoothly through the workflow, and narrate each step while the customer watches. This article examines that instinct and the alternative the course favors: the customer drives the demo.
What do you think happens?
In a demo meant to show that the product is trustworthy, who should be typing the inputs?
Reveal answer
The customer, typing the inputs they would use in their actual work.
In customer control, the customer holds the keyboard. The presenter's smooth path shows only the cases the presenter chose, while the customer's own inputs show how the system behaves in real use.
What Customer Control Means
In customer control, the customer holds the keyboard and types the inputs they would use in their actual work.
The definition is precise about who holds the keyboard. Watching the vendor perform the same steps, even very well, does not count as customer control. The inputs must come from the customer's real work. That is what makes the session a test of the system rather than a performance of it. The same product can be shown in either format; what changes is whose hands produce the inputs.
Customer control is defined by the source of the inputs, not by how carefully the customer is watched or how smoothly the session runs.
Tracing Who Does What in Each Format
Follow the keyboard through both formats and watch what each person does. In the narrated walkthrough, the vendor types and the customer watches while the vendor explains what is happening. In a customer-controlled session, the roles reverse: the customer types and the vendor watches what the customer does, answering questions as they come up. The diagram below traces this difference. Notice that the system underneath is identical in both rows; only the hands on the keyboard change.
Why the Polished Walkthrough Misleads
A common belief holds that a narrated walkthrough is an effective way to show a product. The belief is understandable: the walkthrough is controlled, predictable, and easy to keep on schedule. But the course material treats this belief as a misconception. The narrated walkthrough is named as the most common failure mode in a customer-facing demo, and it tends to produce polite applause rather than signed contracts.
The weakness is structural. A scripted path can only show the cases the vendor chose, and those cases were chosen because they work. Smoothness is evidence that the script works, not evidence about how the system handles the inputs a customer will actually bring. The polish hides exactly the failure modes the customer most needs to see.
Common mistake Treating a smooth demo as proof that the system is robust
Why it failsA smooth demo shows only the scripted cases. It says nothing about inputs the presenter did not try.
Do this insteadLet the customer supply the inputs, so the session tests cases the presenter did not choose.
Common mistake Counting customer observation as customer control
Why it failsWatching the vendor perform steps, even very well, is not customer control under the definition.
Do this insteadMove the keyboard to the customer and have them type inputs from their real work.
Common mistake Stopping the session when the customer triggers an error
Why it failsA failure in a controlled session is information, and the source describes it as one of the best things that can happen to the engagement.
Do this insteadTreat the error as a finding to investigate and address while it is still cheap to fix.
Failure Modes Surface Early
When the customer breaks things during a controlled demo, the break reveals information while the engagement is still early. The reason given is timing. Failures found early are cheaper to fix than failures found after a commitment. A session where the customer triggers errors is therefore a source of information rather than a setback.
Tracing a Customer Input Through a Session
Follow one real input from the customer's workflow to the output the customer judges. The diagram shows the path. The customer's input enters the product, and the output that returns is what the customer evaluates. This is the loop the customer-driven session exercises.
A Shift Tool Under Customer Control
A Customer Types an Unexpected Shift
A vendor is demonstrating a shift-planning tool. The presenter's scripted path enters a standard eight-hour shift and shows a clean schedule. The customer then takes the keyboard and types a shift from their own work that crosses midnight. How should the team read the outcome?
- 1Identify the scripted result
The scripted path showed a clean schedule for a standard shift. That shows the tool works for the case the vendor chose.
- 2Identify the customer's input
The customer typed a shift from their actual work that crosses midnight. This is an input the presenter did not choose, so it tests a different case.
- 3Observe the outcome
Suppose the tool mishandles the midnight crossing. The customer sees the failure during the session, while the engagement is still early.
- 4Read the finding
Under the source's reasoning, this failure is information. It was found before a commitment, so it is cheaper to fix, and the customer sees the system handling a real case honestly.
The clean scripted run and the failing customer input tell different stories. The customer-driven input is the stronger signal of real behavior, and the failure is a useful finding rather than a setback.
Practicing the Customer-Driven Setup
You are preparing a demo for a customer. Describe how you would hand over the keyboard, what kinds of inputs you would ask the customer to bring, and what you would do the moment a failure appears. Explain how your plan differs from a narrated walkthrough.
Hints
- Start from the definition: the customer holds the keyboard and types inputs from their actual work.
- Think about what a scripted path can and cannot show.
- Consider when a failure is cheapest to address and how the customer will perceive it.
Key Takeaways
- In customer control, the customer holds the keyboard and types the inputs they would use in their actual work; watching the vendor perform steps does not count.
- A narrated walkthrough looks polished but is named as the most common failure mode, because a scripted path shows only the cases the vendor chose.
- Customer breakage in a controlled session surfaces failure modes early, when fixing them costs less than after a commitment.
- Letting the customer drive shows that the system handles unexpected inputs, including failing ones, which builds trust that it was built to be honest rather than to be sold.