Structure a product demo around the tasks the buyer described to you, instead of around your menu.
Build a product demo as a few short scenes from the buyer's working day, each one taken from a problem they confirmed in discovery. In each scene, show the finished result first, use the buyer's own details, and stop at the end to ask how it compares with what they do now.
Most product demos follow the menu. The seller logs in, starts at the dashboard, clicks through settings, reports and integrations, and narrates what each screen can do. This is a menu-order demo. After twenty minutes of it, the buyer has seen everything but pictured nothing. Ask them afterwards what they remember and they mention the screen that looked nice and the one that looked complicated.
A demo built around the buyer's working day shows a typical day or event, such as a Tuesday, a month-end or a payday, as it would run with the product. The buyer spends the time imagining their week rather than learning the software.
Hafiz sells payroll software and used to demo in menu order. For Rachel, an operations manager at a logistics firm in Tuas, he rewrote the demo as three scenes from her month: a driver's overtime being calculated after a late delivery run, payroll being run at month-end, and a driver asking on a Monday morning why his pay looks wrong.
Start from the problems the buyer confirmed in discovery, the same problems you mapped in lesson 1.1, "Start the presentation with the buyer's own situation". Each confirmed problem points to a task that goes badly today. That task becomes a scene: the task shown as it would run with your product.
Three scenes is usually enough. Most buyers confirm two to four problems in discovery, and a demo that runs much past fifteen minutes eats into the time you need for questions.
Open each scene with a line that puts the buyer in it. Hafiz starts the month-end scene by telling Rachel he will show her how month-end would run for her. Then show only the screens that scene needs. Hafiz keeps the settings page, the leave module and the reporting suite hidden, because none of them is on Rachel's list, and he will show them if she asks. Otherwise they are noise, the same noise lesson 1.1 asks you to cut from the presentation.
Inside each scene, show the result before the steps. This is called outcome first. Buyers care about the outcome, and the clicks matter to them only once they want it. If the steps come first, the buyer watches them without knowing why they matter, and their attention has gone by the time the result appears. When the outcome comes first, every step that follows has a reason to exist.
In the month-end scene, Hafiz opens with the finished payroll report: every driver's pay calculated, overtime included, no lines flagged for correction. Rachel looks at it and thinks about the two days her team spends on corrections today. Then Hafiz goes back and shows the three steps that produced the report. If he had started with the steps, Rachel would have spent four minutes watching uploads and approvals before seeing what they were for.
People picture themselves using a product much more easily when it contains things they recognise. Before the meeting, set up the demo with the buyer's details where you can: their company name, shift pattern, a sample of job titles and a realistic version of their numbers.
In discovery, Hafiz asked Rachel for an anonymised timesheet with a typical week of overtime and loaded it into a demo account. In the overtime scene the names were made up, but the pattern of late runs and weekend shifts was Rachel's own. When it ran, she leaned forward and said it was exactly what a bad week looks like.
If you use real data, ask permission first, use only what the buyer chooses to share, remove personal details where possible, and delete the data afterwards. Never put a buyer's real staff records into a public or shared demo environment.
Products without screens can be demoed by scene too, whether you are a bookkeeper, a consultant or a financial adviser. The same rules apply: the buyer's task, the outcome first, the buyer's details. Priya offers bookkeeping to Joel, who has two outlets and spends his Sunday evenings on his books. She walks him through a sample of the weekly till report she would send him, laid out with his two outlets, and shows him the Sunday evening he would no longer spend on the books.
At the end of each scene, stop and ask how it compares with what the buyer does today. For example, "How does that compare with month-end at the moment?" or "Is that how the overtime would actually be worked out for your drivers?" Keep it to one question, then listen.
The answers tell you whether the scene landed, whether you have misunderstood a detail of their process, and whether a concern is sitting under the surface. A concern that comes up at a pause is one you would otherwise meet at the end of the demo, or never. These pauses are close cousins of the trial closes in lesson 6.1, "Trial closes: check where the buyer stands". Like a trial close, a pause asks the buyer for an opinion rather than a decision.
After the overtime scene, Hafiz asks Rachel how it compares. She says it is great, but her payroll clerk is not very confident with new systems. A hesitant answer like this gives Hafiz useful information and is no setback. If an answer opens up a real issue, note it and agree with the buyer when you will come back to it, so the demo still finishes on time.
When you plan your own scenes in the activity below, start from the buyer's list of problems, not from your product's menu.
Rewrite your standard demo as three scenes from a buyer's working day, and add a check question after each scene.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).