The Demo Checklist

A demo is a performance, not a code review. Prep it, run it, and recover from live failure — then follow up while it’s hot.

A demo is a story with a decision at the end, not a tour of features. The audience should leave having seen their own problem solved and knowing exactly what happens next. Everything below serves that goal. Preparation removes the risks you can control (data, environment, network, notifications); structure keeps attention on the one narrative that matters; and a rehearsed recovery plan turns the risks you cannot control into a non-event.

The rows apply to customer demos, internal reviews and launch presentations, with a section for the extra failure modes of AI products.

Before

Use their data: Nothing lands like the customer seeing their own records. Load it in advance.
Rehearse the path: Run the exact click-path 3×. Muscle-memory frees you to talk.
Have a fallback: Record a screen-capture of the happy path. If live breaks, cut to it.
Kill the noise: Close Slack/mail, silence notifications, hide bookmarks, full-screen, big font.
Know the audience: Exec → outcome + ROI. Technical → how + integration. Tailor the first 2 minutes.
Send an agenda: the problem, what they will see and the decision you hope for — shared ahead of time
Define the win: agree internally on the one reaction or next step that makes this demo a success

Environment check

Fresh state: reset demo data before every run; leftovers from rehearsal derail the story
Frozen build: lock the version the day before — no deploys on demo morning
Logged in, tabs ready: sessions authenticated, tabs open in order, no passwords typed on screen
Network plan B: a tested phone hotspot and an offline copy in case the venue Wi-Fi fails
Readable screen: zoom to 125–150% and check legibility from the back of the room

Structure the story

One narrative: a single user with a single problem, start to finish — not a feature tour
Before and after: show the painful current way briefly, then the new way; the contrast is the value
Three moments, max: pick the three things they must remember and cut everything else
Their vocabulary: use the customer’s words for things, not your product’s internal names

During

Open with the problem: Restate their pain in their words before showing anything.
Show, then explain: Do the impressive thing, then say how — not the reverse.
Narrate the "so what": After each step: “which means you save X / catch Y earlier.”
Go slow on the wow: Pause after the key moment. Let it land. Don’t talk over it.
Leave the wow last: End on your strongest capability, not a settings screen.
Check in: every few minutes ask, “Is this how your team would do it?”
Watch the room: when attention drops, skip ahead to the moment they care about

Handling questions

Repeat the question: restate it so everyone hears it and you confirm you understood
Answer, then return: a short answer, park the deep dive, and go back to the story
Don’t know? Say so: “I’ll confirm and get back to you by Thursday” beats a guess every time
Missing feature: ask what problem it would solve; never promise a date on the spot

When it breaks

Stay calm: Don’t apologize five times. “Let me show you this a different way” and move.
Cut to the recording: That’s what it’s for. Keep the momentum.
Never debug live: Note it, move on, follow up. Debugging on stage kills the story.
Name it, scope it: “That’s the export step, not the matching you just saw” — the failure stays small
Bail-out rule: decide in advance: one retry, then switch to the recording

Remote demos

Share one window: not the whole screen — no stray notifications, tabs or private documents
Narrate clicks: video lags behind your mouse, so say what you are about to click
Ask to record: get consent first; the recording becomes the follow-up asset
Second screen: notes and chat on another monitor, so you never switch away on the shared one

AI & LLM demos

Nondeterminism: the same prompt can answer differently — rehearse with the exact inputs you will use
Pre-run slow steps: start long generations before the call or cache them; nobody enjoys watching a spinner
Tested prompts: paste prompts from a prepared document instead of typing them live
Show a guardrail: demonstrate an “I don’t know” or a blocked request — trust beats looking perfect
Privacy-safe data: their data with approval, or realistic synthetic data — never another customer’s

After

Confirm the next step: Leave with a concrete “by Friday we’ll…”. A demo with no next step is a dead end.
Send the recap same day: What they saw, the value, next steps — while it’s fresh.
Capture new asks: Every “can it also…” is a scoping input, not a yes.
Share the recording: with timestamps to the key moments, for people who missed the call
Debrief internally: what landed, what broke and what to change, within 24 hours

Recipes

A 20-minute demo run sheet

00:00  Their problem, in their words (from discovery)       2 min
02:00  The current way, briefly — the pain                   3 min
05:00  The new way on their data; first wow, then pause      6 min
11:00  Check in: "Is this how your team works?"              2 min
13:00  The second and third moments                          4 min
17:00  Recap the three things, propose the next step         3 min

Budget time per beat and protect the last three minutes: a demo that overruns usually loses its close, which is the part that produces a decision.

Pre-flight checklist, 30 minutes before

[ ] Demo data reset to the starting state
[ ] Build frozen; no deploys since yesterday
[ ] Logged in, tabs open in order, zoom at 125–150%
[ ] Notifications, chat and mail off; do-not-disturb on
[ ] Recording of the happy path open and ready
[ ] Hotspot tested as a network backup
[ ] Agenda and the next step you will ask for, written down

Run it top to bottom every time; most live failures come from state left over from rehearsal or from a deploy nobody mentioned.

Recovering when the demo breaks (a script)

"That's the export step misbehaving. The matching you just saw is unaffected."
"Rather than debug it live, here is the result from this morning's run."
[switch to the recording or a prepared screenshot]
"I'll send you a note on the export issue by end of day tomorrow."
[continue with the next moment]

Name it, scope it, switch, commit, continue: about thirty seconds, no apology loop, and the follow-up promise becomes a reason to talk again.

The same-day follow-up email

Subject: Today's demo: what you saw and next steps
1. The problem we focused on: [in their words]
2. What you saw: [three moments, one line each, with recording timestamps]
3. Open questions: [each with an owner and a date]
4. Next step: [the agreed action] by [date]

Send it within a few hours while the impression is fresh; it is also the document that gets forwarded to the people who were not in the room.

Questions about The Demo Checklist

How do you prepare for a product demo?

Start from the audience: learn their problem and what decision the demo should lead to, then build one storyline that shows that problem solved, ideally on their own data. Rehearse the exact click path several times, reset the demo environment before each run, freeze the build, and prepare a recording of the happy path as a fallback. On the day, silence notifications, enlarge the text, have a backup network ready and write down the next step you will ask for. Preparation is what lets you watch the room instead of the screen.

What should you do when a live demo fails?

Stay calm and keep moving. Acknowledge the problem in one sentence, scope it so the audience knows what still works, and switch to your fallback, a recording or screenshots of the same step, rather than debugging in front of them. Commit to a specific follow-up, such as an explanation by tomorrow, then continue with the story. Handled this way, a failure costs less than a minute and can even build trust, because the audience sees how you behave when something goes wrong, which is what they will experience as customers.

How long should a software demo be?

Shorter than you think. For most customer and executive audiences, 15 to 25 minutes of demo inside a 30 to 45 minute meeting works well, leaving room for questions and an agreed next step. Technical deep dives can run longer, but even then the core story should fit in about ten minutes, with detail available on request. Plan the time for each section, protect the closing minutes and cut features rather than rushing: three moments the audience remembers are worth more than ten they saw in passing.

Go deeper

Customer discovery questions →FDE playbook →