You will be able to structure a product demo around tasks the buyer described rather than around your menu.
Most product demos follow the menu. The seller logs in, starts at the dashboard, clicks through settings, reports and integrations, and narrates each screen: this is where you can do this, and here you can also do that. Twenty minutes later the buyer has seen everything and pictured nothing. Asked afterwards what they remember, they mention the screen that looked nice and the one that looked complicated.
A demo built around the buyer's own working day works differently. It shows them a Tuesday, or a month-end, or a payday, the way it would run with your product. They spend the time imagining their week rather than learning your software.
Start from the problems the buyer confirmed in discovery, the same ones you mapped in lesson 1.1, Start the presentation with the buyer's own situation. Each one points to a task that goes badly today. That task is a scene.
Hafiz, the payroll software seller, used to demo in menu order. For Rachel, the operations manager at the logistics firm in Tuas, he rewrote it as three scenes from her month. Scene one: a driver's overtime is calculated after a late delivery run. Scene two: payroll is run at month-end. Scene three: a driver asks on a Monday morning why his pay looks wrong.
Each scene opens with a line that puts Rachel in it: "Here is how month-end would run for you." Each one shows only the screens that scene needs. The settings page, the leave module and the reporting suite stay hidden, because none of them is on Rachel's list. If she asks, Hafiz can show them. Otherwise they are noise, the same noise lesson 1.1 asked you to cut from the presentation.
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.
Inside each scene, show the result before the steps. Buyers care about the outcome. The clicks matter only once they want it.
In Hafiz's month-end scene, he opens with the finished payroll report: every driver's pay calculated, overtime included, with no lines flagged for correction. Rachel looks at it and thinks about the two days her team spends on corrections today. Only then does Hafiz go back and show the three steps that produced it.
If he did it the other way round, Rachel would spend four minutes watching uploads and approvals without knowing why they mattered. By the time the report appeared, her attention would have gone. Outcome first gives every step that follows a reason to exist.
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, their shift pattern, a sample of their job titles, a realistic version of their numbers.
Hafiz asked Rachel in discovery for an anonymised timesheet with a typical week of overtime. He loaded it into a demo account. When the overtime scene ran, the names were made up but the pattern of late runs and weekend shifts was Rachel's own. She leaned forward and said, "That's exactly what a bad week looks like."
Be careful with real data. Ask permission, use only what the buyer chooses to share, remove personal details where you can, and delete it afterwards. Never put a buyer's real staff records into a public or shared demo environment.
Not every product has screens. A bookkeeper, a consultant or a financial adviser can still demo by scene. Priya walks Joel through a sample of the weekly till report she would send him, laid out with his two outlets, and the Sunday evening that would no longer be spent on the books. The same rules apply: their task, the outcome first, their details.
At the end of each scene, stop and ask how it compares with what the buyer does today. "How does that compare with month-end at the moment?" "Is that how the overtime would actually be worked out for your drivers?"
The answers tell you three things. Whether the scene landed. Whether you have misunderstood some detail of their process. And whether there is a concern sitting under the surface. When Hafiz asks Rachel about the overtime scene, she says, "That's great, but our payroll clerk isn't very confident with new systems." That is a concern he would otherwise have met at the end, or never.
These pauses are close cousins of the trial closes in lesson 6.1, Trial closes: check where the buyer stands. They ask for an opinion, not a decision, and a hesitant answer is useful information rather than a setback.
Keep the pauses short. A single question, then listen. If the answer opens up a real issue, note it and agree 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, with a check question after each scene.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).