Pointspoken

How to run a product demo without rambling

Reviewed 19 Sept 2026

The most common demo failure is the guided tour: the speaker opens the product and walks through what is on the screen, feature by feature, in the order the interface happens to present them. The audience sees a lot and remembers nothing, because nothing was at stake.

A demo works when the audience recognises the problem in the first fifteen seconds. Everything after that is watching someone they relate to get out of a situation they know. That is a story, and stories survive translation and nerves far better than feature lists do.

The structure: problem, promise, one path, stop

  1. The problem, in their words

    Describe the situation the audience is actually in, using the words they use for it.

  2. The promise

    One sentence: what they will see it do. Say it before you share your screen.

  3. One path

    One realistic example, start to finish, no detours. Real-looking data, not test1 and asdf.

  4. Stop and check

    Stop before you run out of interest. Ask what they would want to see next.

Before and after

Demonstrating an internal reporting tool to a customer-facing team.
Before

“So this is the dashboard. Up here you've got the filters, there's date range, account type, region, and a few others we don't really use. On the left is the nav, these are all the report types, I won't go through all of them. If I click here you get the table view, and there's an export button, although the CSV export has a known issue. Let me just find an account with some data in it… sorry, this one's empty. Let me try another one.”

  • It describes the furniture. No problem has been named, so nothing on screen means anything.
  • It volunteers a bug and a set of unused filters, both of which lower confidence for no benefit.
  • Hunting for data live tells the room this was not rehearsed.
Clearer

“You told me last month that when a customer asks why their invoice changed, it takes about twenty minutes to find out, and you often have to ask engineering. I want to show you that taking about thirty seconds. Here's a real case from Tuesday: Adeola emails asking why her bill went from £400 to £650. I search her account, open the billing timeline, and there it is: she added nine users on the 3rd. That's the whole path. What would you want to see next, the refund flow or the bulk export?”

Scripted example, not a real user's recording.

Phrases you can use

Name the problem first
  • “You told me that today this takes about…”
  • “The situation I want to solve is…”
  • “Most of you have had this happen:…”
Make the promise
  • “I want to show you that taking thirty seconds.”
  • “By the end of this you'll know whether it fits your week.”
  • “One example, start to finish. Two minutes.”
Keep the path narrow
  • “There's a lot else here; I'm going to ignore all of it.”
  • “I'll come back to that if we have time.”
  • “That's a fair question and it's outside today's path — let me note it.”
Stop and hand over
  • “That's the whole flow. What would you want to see next?”
  • “I'll stop there. What did I skip that you care about?”

Common mistakes

Touring the interface

Never narrate the screen. Narrate a person solving a problem, and let the screen follow.

Placeholder data

Use realistic names, amounts and dates. “test1” and “asdf” break the story instantly.

Apologising for the product

Do not volunteer bugs or missing features. Answer honestly if asked; do not tour the flaws unprompted.

Going until they stop you

Decide your stopping point in advance and stop there, with interest left over.

A ten-minute drill

  • Write one sentence describing the problem in the audience's own words. Not your words for it.
  • Choose one example with realistic data and prepare it before you record.
  • Record a 90-second demo narration with no screen at all, just the story.
  • Listen for every sentence that describes the interface rather than the person. Cut them and record again.

Questions people ask

What if the demo breaks live?

Say what should have happened, in one sentence, and carry on: “that normally returns in about a second — it's showing the timeline with her nine new users”. Do not debug in front of the room.

How much detail for a technical audience?

The same story, with the mechanism offered rather than pushed: “under this there's a queue — happy to go into it afterwards”. Experts still want the problem first.

They keep asking about features I'm skipping.

Note them out loud and visibly: “that's two for the list”. It shows you heard, protects the path, and gives you your follow-up agenda for free.

Related situations