How to Make a Marketing Video for a Software Product, Step by Step, Recorded From a Real Run

Most guides to making a marketing video start with storyboards and a shot list. That is the right advice for a brand film and the wrong advice for software, where the interesting footage is not something you design in advance. It is something the product does, and your job is to be recording when it does it.

This is the process we use. It takes an afternoon for a first video, less once the environment exists, and it needs no camera, no studio and no presenter.

Step 1: pick one task and write it in a sentence

One task. Not a tour, not a feature set. The test of a good task is whether you can name the moment it finishes.

• Good: "Alert me when any product drops below twenty in stock." Finishes when the alert arrives.
• Good: "Restore a single file from last night's backup." Finishes when the file matches the original.
• Bad: "Show the reporting module." Nothing finishes, so there is nothing to film and nothing to verify.
• Bad: "Set up the account, import data and build a dashboard." That is three videos wearing a trenchcoat.

Pick the task from your support queue rather than your roadmap. The question your team answers most often is the one with a proven audience, and you already know the answer, which makes the recording fast.

Step 2: build a clean environment and state the prerequisites

Record on an environment that looks like the one your viewer has, not the one your demo team has been grooming for two years. A demo tenant full of perfect sample data is why viewers do not believe demos.

Before you touch anything, put the prerequisites on screen: the product version, the account type and permissions used, any dependency that must already exist, and roughly what free space or quota the task needs. Thirty seconds of prerequisites prevents the most common failure mode of published walkthroughs, which is a viewer following along and hitting a wall the recording never mentioned.

Never record against production. Ever. A trial or a demo tenant is enough, and the constraint keeps you honest about what a new customer actually sees.

Step 3: operate, and log every attempt

Start the screen recording before you start the task and leave it running. Do not stop it when something goes wrong. That footage is the most valuable material you will capture today and the instinct to delete it is the instinct to make a worse video.

Keep a written log alongside the recording with a timestamp per step. It looks like this:

[00:00] operator  open inventory dashboard
[00:38] operator  settings → alerts → new rule
[01:15] operator  threshold 20 · save
[02:04] retry     no alert fired
[02:31] operator  notify toggle was off · on
[02:50] verified  alert received

That log becomes the chapter markers, the written guide and the troubleshooting section. It costs nothing to keep while you work and is painful to reconstruct afterwards.

Step 4: verify against the product's own evidence

This is the step that separates a walkthrough from a demo, and it is the one almost every guide omits.

When the task finishes, do not take your own word for it. Check the result against something the product produced independently of the screen you were just clicking on.

• The file is really in the bucket, and its checksum matches the original.
• The alert really arrived, in the inbox, with the value you expected.
• The restored machine really boots and you can log into it.
• The record really appears in the API response, not just in the UI that wrote it.

Put that evidence on screen. It is four seconds of footage and it is the difference between showing a button being clicked and showing a job being done.

Step 5: cut, caption, publish

Cut the dead air and nothing else. Resist the urge to cut the pauses where the product was thinking, because that is how long it actually takes and a viewer planning a migration wants to know.

Captions are not optional. A large share of viewing is muted, and captions are also the only part of the video a search engine and a language model can read. Write them from the log rather than auto-generating them, because the auto-generated version will mangle every product noun you care about.

Publish with the written guide beside the video. Some people will read rather than watch, and the guide is what gets found in search and cited in answers.

The part most guides skip: keep the failure

The polished take proves the task can be done by someone who already knew how. The failed take proves it can be done by someone who did not.

Add a troubleshooting section listing what went wrong before it went right, with the fix. In the example above, the alert did not fire because a notify toggle defaulted to off. That single line is more useful than the other five minutes combined, because it is the exact thing a user will hit and search for at eleven at night.

You can see this in practice on the Proxmox VE 9.2 install walkthrough, where the two documented failures are the whole-disk warning and the network screen, which are precisely the two things people get wrong.

What it costs

For an internal team: half a day for the first video while you build the environment and the habit, then roughly ninety minutes per task after that, most of which is the recording itself. The expensive part is not production. It is the engineer's afternoon, which is why the fifth video usually never gets made.

If you would rather not spend the afternoons, that is the service on this site, and the rates are on pricing. Either way the method above is the method, and it works whether we run it or you do.

A checklist to steal

• One task, with a nameable finish line
• Prerequisites on screen before anything is clicked
• Clean environment, never production
• Recording running before the task starts and after it fails
• Timestamped log kept while working
• Result verified against evidence the product produced
• Captions written from the log, not auto-generated
• Failures kept, with the fix, in a troubleshooting section
• Version tag recorded so you know when to re-run it