How to Make a Product Demo Video: A 7-Step Process

Your product does something worth watching and nobody has watched it. The landing page needs a video, the launch post needs a video, and the sales call would go better with one. So you block out an afternoon.

The afternoon is usually enough. What catches people out is the second afternoon, three months later, when you ship a redesign and the demo on your homepage is now showing software you no longer make. This is how to make a product demo video in seven steps, with that second afternoon designed in from the start.

What you'll need

• A build you can put into a specific state. Seeded data, a real-looking account, nothing named test1. This is the actual prerequisite and it takes longer than the recording.
• A screen capture tool. Whatever you have. The tool matters far less than the state of the product in front of it.
• About two hours, most of which is not recording.

You do not need a microphone, a studio, a voiceover artist, or a script in the screenwriting sense. Demo videos are watched muted more often than not, and the ones that work are usually silent with text on them.

The short version

1. Decide the single claim the video has to prove.
2. Pick the one flow that proves it, and cut every other screen.
3. Write a shot list of interactions, not a paragraph of voiceover.
4. Budget the seconds per beat before you record anything.
5. Put the product into its demo state — data, notifications, window size.
6. Capture the footage, or generate it.
7. Cut on the interactions, add text, and keep the shot list so you can do it again.

Steps 1 to 4 are most of the work and none of them involve a camera. If you start at step 6 you will record the whole product and then try to find a video inside it, which is where the four-minute cut comes from.

Step 1: Decide what the video has to prove

One claim. Write it down as a sentence before you do anything else.

Three that work: "our export is faster than the thing you use now", "you can set this up without an engineer", "this does in one screen what your current tool does in six".

A demo video is an argument with evidence. If you cannot state the claim, the video becomes a feature tour, and that is the failure mode behind every four-minute demo nobody finishes.

The test: if a viewer could watch the whole video and not be able to repeat your claim back, the video does not have one yet.

A feature tour tries to prevent objections. A demo video makes one argument and lets the objections happen on a call.

Step 2: Pick the single flow that proves it

Now find the shortest path through your product that demonstrates that claim, and treat everything off that path as cut.

Not the login. Not the onboarding, unless setup speed is the claim. Not the settings screen. The flow that produces the moment where a viewer thinks "oh, that's the thing." Usually it is three to six interactions long, which surprises people who expected to need more.

If two flows both prove the claim, pick the shorter one. If the claim needs two flows to land, you have two claims and you should make two videos.

Step 3: Write a shot list, not a script

Every guide on this query tells you to write a script and shows you a paragraph of voiceover. That is the wrong artifact. Voiceover prose does not tell you what to do with your hands, and it does not tell you when to stop recording.

What you need before you capture anything is an ordered list of interactions with the caption that belongs on each one:

1. Projects list, scrolled to top      → "Start from a real project"
2. Tap New Project                     → (no caption, let the sheet land)
3. Type "Q3 Launch"                    → "Name it"
4. Tap the template picker             → "Pick a template"
5. Tap Save                            → "That's the whole setup"
6. Hold on the new project row         → "Eleven seconds."

Six lines. Now you know exactly what the take has to execute, where the captions go, and — critically — you know when the video is over. This list is also the thing you will still have in three months when the video file is out of date, which is why step 7 exists.

Write the captions here, not in the editor. Captions written against footage describe what is on screen; captions written against the shot list say why it matters.

Step 4: Budget the seconds before you record

The common recommendation across demo-tool vendors is 60 to 90 seconds, and it is a reasonable default for a marketing-page demo. What none of them publish is how to spend it, which is the part that decides whether your shot list is filmable.

Do the arithmetic:

1. Pick the runtime. Say 75 seconds for a landing-page demo. Shorter for an email embed, longer only for a sales call where someone is obliged to keep watching.
2. Count your beats. From step 3 — six interactions.
3. Divide. 75 ÷ 6 is about 12 seconds per beat.
4. Subtract the joins. Roughly a second of settle time per transition, so call it 10 seconds of actual content per beat.
5. Read a caption aloud in 10 seconds. About 25 words. If your caption for beat three is 40 words, the caption is wrong or the beat needs to be two beats.

Ten seconds per beat sounds short until you time yourself performing one. It is not short — it is roughly three times longer than the interaction actually takes, and the extra is what makes the video legible instead of frantic.

Step 5: Set the product's state

This is the step that separates a demo that looks like a product from one that looks like a staging environment.

• Seed real-looking data. Names of real-sounding things. Plausible numbers. Dates near today, not 2019-01-01. An empty state in a demo video reads as an empty product.
• Silence everything. Notifications, Slack, calendar alerts, the update badge on your dock.
• Fix the frame. Pick the window size or device class once and keep it for every take, or your cuts will jump.
• Log in as someone plausible. Not admin@localhost. Not your own avatar if your face is not the point.
• Do the flow once without recording. You will find one broken thing. There is always one broken thing.

Step 6: Capture the footage, or generate it

There are three places demo footage comes from, and the choice constrains everything downstream.

Screenshots you already have. Fastest start; a tool animates between stills. Fine for a launch tweet, and it never shows your product actually moving, which is what a demo is for.

A recording you make yourself. Works for any stack — web, desktop, mobile, anything on a screen. The cost is the clean take: no mistyping, no hesitation, no missed tap, for the whole length of the flow. Most people get it on take four.

Footage generated from the running product. Some tools drive the software themselves and produce the recording, rather than asking you to perform it. This removes the clean-take problem entirely, and it is platform-specific by nature, since driving an app means running it. Which of the three fits your situation is a longer argument than this step deserves — the blog works through it in detail.

For the first two, record more than you need at each end of each beat. Trimming is free; a beat that starts half a second late is a re-record.

Step 7: Cut to the beats, then make it reproducible

Cut on the interactions from your shot list. The tap is the edit point: land the caption when the finger lands, not a beat after, because a caption that arrives late reads as a subtitle for something you already saw.

Three edits carry most of the quality:

• Remove dead air. The gap between "tap" and "screen responds" is real time and it is not interesting. Cut it.
• Push in on the interaction. A gentle zoom toward the thing being touched tells the eye where to look, which matters at the size these videos actually get watched.
• Put the caption on the beat, not on the section. One short line per interaction beats a paragraph over the whole clip.

Then do the thing nobody's guide tells you to do: save the shot list next to the video file.

A product demo video has a shelf life measured in releases. The version on your homepage will show a button that moved, a screen that got redesigned, a flow that gained a step. At that point you either re-record from memory — which means re-deriving steps 1 through 5 badly — or you open the shot list and re-shoot six known beats in fifteen minutes.

The video file is the output. The shot list is the source. Guides that treat the file as the deliverable are the reason your last demo is eight months old.

One page-one guide does address staleness, and it is worth understanding why its answer will not help most people. HowdyGo captures a web page's DOM rather than pixels, so its editor can rewrite the captured HTML after the fact — per its own guide, read on 16 August 2026. That works because a web page is text. A native iOS or Android app has no DOM to re-edit, so for mobile, staleness means re-shooting, and the shot list is the only thing that makes re-shooting cheap.

Where this goes wrong

The feature tour. You had one claim in step 1 and then added "while we're here, let me also show you". Every added screen costs a viewer.

The four-minute cut. Almost always a symptom of skipping step 4. If you never budgeted the seconds, there was no point at which the video was supposed to end.

The take you cannot repeat. You got a clean run, you did not write down what you did, and the run is now unreproducible. This is fine until the first UI change and then it is expensive.

Voiceover first. Writing narration before the shot list produces a script the footage cannot execute. If you want narration, write it against the shot list afterwards, and assume most people will not hear it.

The demo that shows software you no longer ship. The most common one, and the only one that gets worse on its own while you do nothing.

Doing it without the manual work

Most of the seven steps are judgement and cannot be automated: nothing decides your claim for you. Steps 5 through 7 are mechanical, and that is where tooling earns its place — putting the product in a known state, capturing it, cutting on the interactions.

Reely does that half for Apple platforms. You describe the flow — the same interactions you listed in step 3 — and it drives the feature in the iOS Simulator, records the run, and composites the cuts, the push-ins and the captions against the interaction marks it recorded along the way. Because the flow is a JSON spec rather than a performance, re-shooting after a UI change is re-running a file. That is step 7 solved structurally rather than by discipline. The docs cover how the spec is written.

The limits are worth stating plainly. Reely covers iOS and Apple platforms, so a web app or an Android app needs a different tool. It produces the video, not the claim or the flow — steps 1 and 2 are still yours. And if your product is not something you can run locally on a Mac, none of this applies.

Frequently asked questions

How long should a product demo video be?

Sixty to ninety seconds for a landing page or a launch post, which is where most demo-tool vendors converge. Go shorter for an email embed, where under a minute is safer. Go longer only for a sales context where the viewer has a reason to keep watching. If your flow will not fit in ninety seconds, the problem is usually the number of features, not the pacing.

Do I need a script for a demo video?

You need a shot list, which is not the same thing. A shot list is an ordered set of interactions with the caption that belongs on each — six lines of plain text. It tells you what to perform, where the cuts go, and when the video ends. A voiceover script tells you none of those, and most demo videos are watched with the sound off.

Should a product demo video have a voiceover?

Usually not for a landing page or an app listing, because autoplay is muted and most viewers never turn sound on. On-screen text carries the same information and survives being watched silently. A voiceover earns its place in longer sales or onboarding videos, where the viewer has already committed and narration can cover things the screen cannot show.

What software can I use to create demo videos?

Any screen recorder plus any editor will get you there; the tool is rarely the constraint. Purpose-built demo tools save time on the parts that are fiddly by hand — zooms that follow the cursor, captions timed to clicks, device frames. The real split is whether a tool asks you to record a clean take or produces the footage for you, since that decides how much of your afternoon goes on re-takes.

Next

Do steps 1 through 4 today, on paper, before you open a recorder. Twenty minutes there is worth two hours of recording, and it is what stops the video from becoming a tour.

Then keep the shot list. Whatever you use to make the video, the list is the thing that makes the next version cheap. If your product is an iOS app and you would rather write the flow once than perform it repeatedly, Reely turns that list into the finished reel from the Simulator — download it for Mac and try it on one feature.