← All postsHow-to

Demo script: showing a product without touring it

A demo script keeps a product demonstration pointed at the buyer's problem instead of your feature list. How to structure one, and what to do when they ask about something you cannot show.

How-toD

The default product demonstration is a tour: here is the dashboard, here are the settings, here is the reporting. It is comfortable to give and almost useless to watch, because the viewer has to do the translation work themselves. A demo script is the alternative — a planned sequence tied to one buyer's problem, where every screen shown exists to answer something they said.

What a demo script contains

  • The problem in their words, stated back before anything is shown. If you cannot state it, you are not ready to demo.
  • Three moments, not fifteen features — the points where their current situation becomes visibly better.
  • The exact path to each moment, including the data you will have prepared so nothing is empty.
  • What you will deliberately not show, which is most of the product.
  • The question you ask after each moment, because a demo without questions is a broadcast.
  • The next step, named before you start.

Start at the end

Open on the outcome rather than the setup — the finished report, the completed approval, the clean inbox — then show how little work it took to get there. Starting at configuration is the most common structural mistake: it front-loads the least persuasive part, and buyers quietly conclude the product is work rather than relief. Nobody has ever bought because the settings screen was comprehensive.

Prepare the data as carefully as the path. A demo on an empty account shows nothing, and a demo on obviously fictional data ("Test Company 3") tells the viewer you did not spend ten minutes on them. Use realistic volumes, realistic names, and the kind of mess their data will actually have.

When they ask for something you cannot show

  1. Say so plainly and immediately. Every experienced buyer has watched somebody dodge, and the dodge costs more than the gap.
  2. Separate "not built" from "built differently" — the second is usually the real answer and leads somewhere.
  3. Write it down visibly, so they see the question captured rather than deflected.
  4. Offer the nearest real thing rather than a roadmap promise.
  5. Follow up in writing afterwards with the accurate answer, which is often better than the one you would have improvised.

Running it live

Rehearse the path, not the words — a memorised demo sounds memorised, and the point is to be responsive. Keep the deck and the product separate: slides set up the problem, the product shows the answer, and switching between them repeatedly makes both feel thin. And stop when the buyer has what they need. A demonstration that ends five minutes early with a clear next step beats one that fills the hour because the time was booked.

Ettex Slides handles the framing part — the problem and the next step — with speaker notes for the argument you make out loud, while the product does the rest. Where the deck depends on numbers that change between demos, keeping them in a sheet and referencing it avoids the version where two slides disagree in front of a customer.

Frequently asked

How long should a demo be?

Shorter than the slot. Twenty focused minutes with questions beats fifty minutes of coverage, and leaving time for the next-step conversation is the point of the meeting.

Should I follow the script exactly?

No — it exists so you can leave it safely. The script guarantees you reach the three moments even when the conversation takes a detour.

What if they ask to see everything?

Offer a second session for depth. A full tour in a first meeting almost always loses the thread that got you the meeting.

MI
Written by Maria I.

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.