How to Write a Product Demo Script

The best way to write a product demo script is to write two documents instead of one: an exact click sequence you rehearse from, and a loose set of narration points you speak over the finished cut. Writing a single word-for-word script and performing it live is what produces the recited, slightly anxious delivery that most demos are criticised for.

This is the scripting step in creating a product demo. The recording mechanics — data, frame, resolution — are covered separately in recording without retakes.

Why split the script in two?

Because the two documents have different jobs and different failure modes.

The click sequence must be exact, because it is choreography. You rehearse from it until the actions are mechanical, and it is the artifact that lets you re-record step four next quarter without touching steps one to three. If it lives only in your head, every product change costs you a full re-record.

The narration must be loose, because it is performance. Bullet points let you sound like someone explaining their own product. Full sentences make you sound like someone reading, and viewers detect it immediately even when they cannot say why.

Separating them has a practical benefit too: you can re-narrate the same recording for a different audience — a technical buyer versus an executive — without re-recording anything.

What does a click sequence look like?

Plain, numbered, and specific enough that someone else could perform it:

1. Start on Invoices, filtered to All. Wait for the list to settle.
2. Click the Overdue filter. Pause on the result.
3. Select the top three rows.
4. Click Send reminder. Confirm in the dialog.
5. End on the confirmation toast with the count visible.

Three things make this version useful. It names the starting state, so you are not recording whatever the app happened to be showing. It includes the pauses, which are what make a demo readable rather than frantic. And it names the last frame, so the demo ends on the payoff instead of trailing off.

How do you structure the narration?

Four beats, in this order:

The outcome first. "In about thirty seconds, every overdue invoice here gets a reminder." Not "Hi, I'm Jake and today I'll be walking you through…". The viewer already chose to watch; the introduction spends the only attention you are guaranteed.

The context, briefly. One line on why this matters — the situation the viewer recognises.

The doing, narrated as consequence not instruction. Say what the click achieves rather than what it is. "Filtering to overdue" is a description of the screen the viewer can already see. "These are the ones past due — twelve of them, about four thousand pounds" tells them something the screen does not.

The payoff, stated plainly. Name what just happened. Then stop talking.

The most common script problem is narrating the interface instead of the work. If a line would still be true with the product replaced by any other product, cut it.

What changes for an interactive demo?

Interactive demos replace narration with step captions, and the constraint is much tighter — nobody reads a paragraph in a tooltip.

One instruction, one reason, per step:

Filter to overdue. These twelve are the ones costing you money.

Instruction first, because the viewer is looking for what to do. Reason second, because that is what they remember. Anything longer than about two short lines gets skipped, and a skipped caption is worse than no caption — it trains the viewer to ignore the next one too.

Write captions in the imperative and in the second person. "Click Send reminder" beats "The user can now send a reminder." You are giving directions, not documenting a feature.

How do you know the script is good?

Read the click sequence aloud while watching someone unfamiliar follow it. Three signals mean it needs work:

• They ask "where?" — your sequence assumes knowledge of the interface.
• They finish and say "so what?" — the payoff is not on screen, only implied.
• You find yourself explaining something the script does not cover — that thing belongs in the script, or the demo is covering too much.

Then publish it where the decision happens. For an interactive demo that is usually the pricing page and the top feature pages; the embed guide covers the single script tag and its options. Rendemo can also generate step captions from the recording as a starting draft, which is useful precisely because editing a draft is faster than facing an empty caption field — though the lines above about instruction-then-reason still apply to whatever it gives you.

A script is a maintenance artifact as much as a creative one. Keep it in the repository or the document next to the demo, so the person who re-records in six months inherits the choreography instead of reinventing it.