How to run a product demo: A seven step runbook

How do you run a product demo that feels polished without turning it into a one-off script nobody can maintain? The honest answer is not a slicker recorder or a better slide deck. A good demo starts when the asset lives in your repo, not inside someone else's SaaS. Here's the seven-step runbook.

Start by defining what a product demo is supposed to prove

The demo is not the product tour

A product tour shows screens. A demo proves one buying decision. The difference sounds small until you're twenty minutes into a walkthrough and the prospect is still waiting for the part that matters to them.

When you try to cover everything, you prove nothing. The buyer leaves with a vague sense of the product's breadth and no clear reason to move. A demo that proves one thing — setup speed, a specific workflow, the fact that the output is code they can own — creates a belief shift. A tour just creates familiarity.

What the buyer needs to believe by the end

Before building anything, write down the one sentence the buyer needs to believe after the call. On a previous project, the goal was not "understand the product" but "believe setup takes under five minutes." Every screen in the demo was chosen to prove that single claim. Anything that did not serve it got cut.

For a software product, that belief might be: "I can see how the API handoff works without involving engineering." Or: "The demo is editable — I'm not locked into a vendor's version of it." Pick one. Build toward it.

PostHog's tips on S-tier demos make the same point: the demos that land are the ones built around one main thing the audience should remember, with everything else subordinated to it.

Do the buyer research before you touch the demo

The questions you need answered before the call

A product demo runbook without discovery context is a script written for nobody. Before the call, you need five things: the buyer's role, their current tool or workflow, their urgency, their technical comfort level, and the one objection they're most likely to raise.

Role tells you which proof moment to lead with. Current tool tells you what the comparison will be. Urgency tells you whether to spend time on the close. Technical comfort tells you how deep to go on the implementation detail. The likely objection tells you which screen to slow down on.

How to avoid tailoring the demo into a dead end

Tailoring is useful. Overfitting is a trap. The difference is simple: tailoring changes the talking points and the proof moment you lead with. Overfitting rebuilds the demo from scratch for every prospect, which leaves you with five versions of the demo and none of them maintained.

On one early customer call, a discovery note flagged that the prospect cared about handoff speed, not creation speed. The demo structure did not change. The same base flow covered both. But the slow-down moment shifted from the capture step to the export step. Same asset, different emphasis. That's the right kind of tailoring.

Research on discovery-led selling consistently shows that pre-call context is the variable that separates demos that convert from demos that just inform. Stripe's approach to product storytelling shows the same discipline: know the audience's job before you show the product.

Choose the demo type that fits the moment

Live demo, async video, or interactive demo

Live demos give you control and real-time responses to questions. Async video is faster to send but cannot adapt mid-watch. An interactive product demo lets the buyer explore at their own pace, but if the product changes underneath it and the demo is a recording, you're showing stale UI to every new viewer.

The tradeoff that actually matters is reuse. A live demo is always current because you're running the real product. An async video is outdated the moment the UI changes. An interactive demo is only current if you can update it without re-recording.

Why code-native demos win when the product moves fast

If the demo is code in your repo, your agent can update it when the product changes. The workflow is straightforward: you have a `demo/` directory in the repo, a set of HTML files that represent the demo screens, and a prompt you run against the existing code when a UI change ships. The agent edits the affected screens. No re-recording, no manual click-by-click fix, no hunting through a vendor UI.

That's the ownership wedge. When the demo is a recording inside someone else's platform, every UI change means a new recording session. When it's code you own, a UI change is a diff.

Build the demo script as a sequence, not a monologue

The seven beats the demo needs to hit

A working demo script has a shape: setup, problem, proof, walkthrough, objection, next step, follow-up asset. In that order.

Setup is thirty seconds. Confirm the goal and timebox the call. Problem is one minute. Name the thing the buyer is trying to fix. Proof is the moment you show it working, ideally in under ninety seconds. Walkthrough is the supporting detail, two to three minutes max. Objection is the anticipated challenge, answered in the product. Next step is the close. Follow-up asset is what they can share internally after the call.

Where the story arc should speed up and slow down

Move fast through setup and navigation. Slow down on the one proof moment that earns the belief shift. Most founders spend too long on the dashboard and not long enough on the specific workflow the buyer came to see.

A rough agenda that works: 0:00–0:30 frame the call, 0:30–1:30 name the problem, 1:30–3:00 show the proof, 3:00–5:30 walk the supporting flow, 5:30–7:00 handle the expected objection, 7:00–8:00 close and next step. Eight minutes. If the call runs longer, it's because the buyer asked questions, which is usually a good sign.

Rehearse the demo until the rough edges disappear

The parts that always break in rehearsal

Transitions between screens, loading states that pause at the wrong moment, permission prompts that appear mid-flow, and assets that have not been updated since the last release. Rehearsal finds all of them before the prospect does.

The most embarrassing one in a live call is a loading spinner that appears on the proof screen right as you say "and here's where it happens." Rehearsal catches it. The fix is either a state change in the demo or a bridging line in the script. Either way, you want to find it before the call.

Why a repo-native demo is easier to clean up

When the demo is code you own, the fix is a change in the repo: edit the file, commit, done. When the demo is a recording in a vendor's UI, the fix is a re-record or a manual edit through their interface, which means navigating their editor to find the right frame.

A product demo runbook that includes a pre-call rehearsal checklist should also include a maintenance step: after any product release, run the demo against the current build and note what's stale. If the demo is code, that stale note becomes a prompt for your agent.

Run the live product demo without losing the room

Opening the call without wasting the first two minutes

The first two minutes of a live product demo are where most founders lose the room. They spend them on introductions, company background, and a recap of what the product does, all things the buyer already knows from the calendar invite.

Instead: confirm the goal in one sentence, state the timebox, and tell the buyer what they're about to see. "We've got thirty minutes. I'm going to show you how the export step works, then we'll have time for questions." That's it. You're in the demo by minute one.

The moment to go slow and the moment to move on

In a live demo, the buyer signals when they want to slow down. They lean forward, ask a question, or say "wait, can you show that again." That's the proof moment. Stop. Show it again. Let them ask the follow-up.

The moment to move on is when the buyer goes quiet on a screen that is not the proof moment. Don't narrate every click. Say "I'll skip through the setup steps" and move to the part that matters. A prospect who asked to jump ahead on a previous call was telling me the proof moment was earlier in the flow than I'd placed it. That feedback restructured the next ten demos.

Handle objections and close with a next step the buyer can repeat

Answer the technical question without turning it into a support call

When a technical objection comes up mid-demo — "how does this handle X" — answer it in one sentence, prove it in the product if you can, and get back to the flow. "It handles X through Y. Let me show you." Click. Show it. Move on.

The failure mode is treating the objection as an invitation to explain the architecture. The buyer does not need the full implementation detail. They need to believe it works. Prove it in the product, then continue.

End with a close and a follow-up asset

The cleanest close in a product demo is a specific next step plus something the buyer can forward internally. "Let's set up a technical call with your engineer next week" is a next step. A shared demo link, a short recap doc, or a repo branch the buyer can explore is the follow-up asset. It keeps the demo alive in the buying committee conversation after you leave the call.

On a previous deal, a shared demo branch, a version of the demo the buyer could click through on their own, was what moved the internal conversation forward. The champion could show the proof moment to their team without scheduling another call. That's the asset worth building.

Where Inkly comes in

The structural problem this runbook keeps circling is the same one: the demo needs to stay current as the product changes, but most demo tools make currency a re-recording problem. Every UI change, every new customer, every tailored variant means another pass through the editor. The workflow described in steps three and five, a demo that lives in your repo and gets updated by a prompt instead of a re-recording, is what Inkly is built on.

Inkly makes the demo code you own. You capture the initial flow via Chrome extension or prompt your agent directly, and the output is HTML in your repo, not a recording locked in someone else's SaaS. When the product ships a UI change, you re-prompt the existing demo code. When a new customer needs a tailored variant, you re-prompt for their branding and data off the same base. The three-prompt loop — create, update, produce variants — replaces the three things that historically killed demo maintenance. The honest tradeoff: you need a coding agent (Cursor, Claude, Codex) in your workflow; there's no hosted in-app agent yet. If you're already working that way, demos as code you own is the natural next step.

FAQ

Q: What is the simplest step-by-step flow for running a polished product demo?

Define the one belief shift the buyer needs to have by the end. Research the buyer's role, current tool, and likely objection. Choose the demo format. Build a script with seven beats: setup, problem, proof, walkthrough, objection, next step, follow-up asset. Rehearse until the rough edges are gone. Run the live call, slow down on the proof moment, and close with a specific next step plus a shareable asset.

Q: How do you tailor a demo to a prospect without overfitting it so much that it becomes hard to reuse?

Change the talking points and the proof moment you lead with, not the underlying demo structure. The same base flow can serve different buyers if you know which screen to slow down on. Overfitting means rebuilding the demo from scratch per prospect; tailoring means adjusting emphasis. Keep one maintained base demo and layer the tailoring on top.

Q: What should a founder or product engineer prepare before the demo starts?

Five things: the buyer's role, their current tool or workflow, their urgency, their technical comfort level, and the one objection they're most likely to raise. That context shapes which proof moment to lead with, how deep to go on implementation detail, and where to slow down. Without it, you're running a generic tour, not a targeted demo.

Q: How do you structure a live demo so it stays clear, persuasive, and on time?

Open by confirming the goal and the timebox, thirty seconds. Spend the first ninety seconds naming the problem. Show the proof moment in under two minutes. Walk the supporting flow for two to three minutes. Handle the expected objection in the product. Close with a next step. Eight minutes total. If it runs longer, it should be because the buyer asked questions, not because you narrated every screen.

Q: How can you keep a product demo accurate when the product changes every week?

The only durable answer is that the demo lives somewhere you can update it without re-recording. If it's a recording in a vendor's SaaS, every UI change means a new capture session. If it's code in your repo, a UI change is a prompt to your agent: edit the affected files, commit, done. Build the maintenance step into the release workflow, not as an afterthought.

Q: What is the easiest way to create an interactive or video demo with low overhead?

For a first demo, capture the live flow via Chrome extension. Most tools, including Inkly, support this and it is fast. For ongoing maintenance, the lowest-overhead path is a code-native demo your agent can update with a prompt. Async video is the fastest to send but the most expensive to maintain. Every UI change means a new recording.

Q: How do you handle objections, questions, and next steps without losing momentum?

Answer the objection in one sentence, prove it in the product if you can, and get back to the flow immediately. Don't treat a technical question as an invitation to explain the architecture. For the close, name a specific next step before the call ends — "let's schedule a technical call next week" — and hand the buyer a follow-up asset they can share internally without scheduling another call.

Conclusion

A good product demo is repeatable because the workflow starts in the repo and ends with a clear next step. The runbook does not change call to call. The proof moment shifts, the tailoring shifts, but the seven beats stay the same. Run one demo this week using this structure. Then take the demo asset and make it code you can keep, so the next call starts from a maintained base, not a re-recording.