Product demo vs. launch video: which should you make?

Someone who has never heard of your product needs a reason to keep watching before they need a tour of the settings. Someone evaluating a specific feature may already understand the problem and want to see whether your workflow handles it. Giving both people the same opening makes one of them wait through an explanation they don't need.

These aren't strict industry definitions, and a launch video can contain a demo. The distinction is useful because it helps you decide what to keep when the brief starts growing.

• Choose a launch video when the main question is: what's changed, and why does it matter to me?
• Choose a product demo when the main question is: can I use this to get my work done, and what does that involve?
• Choose a tutorial when the viewer already wants to use it and needs exact instructions, including setup or permissions.

Let's use Reviewboard, a fictional task-management product. Its saved-view feature lets someone filter tasks, save those filters as Weekly review, return to the full task list and reopen the same view. That is the whole example. We aren't claiming it saves a measured number of hours or that a real customer uses it.

The demo version needs to make the relationship between those steps clear. The launch version needs to make the recurring problem recognizable, then show enough of the feature to support its announcement. Neither needs a tour of every item in the sidebar.

For the launch cut, I'd start with the repeated work: setting up the same task filters for a regular review. Then I'd introduce saved views and show the relevant result. You can skip some pointer travel, but don't skip the evidence that makes the benefit believable.

Here's a proposed 25-second structure. The timings are an editing brief, not a performance recommendation or a claim that this duration works best.

0-5 seconds | Show the task list and the recurring review context.
Copy: Setting up the same filters for every weekly review?

5-10 seconds | Select Status: Blocked and Sprint: Current. Show the two matching tasks.
Copy: Save the view you come back to.

10-17 seconds | Save as Weekly review, briefly return to All tasks, then reopen Weekly review.
Copy: Your filters are there when you need them again.

17-22 seconds | Hold on the restored filters and matching tasks.
Copy: Saved views in Reviewboard.

22-25 seconds | Show the next action.
Copy: Create your first saved view.

The opening addresses the viewer's situation before naming the feature. The middle still shows the return to the saved state, so the announcement doesn't depend entirely on a line of copy. If the real feature is only available on certain plans, that qualification belongs in the accompanying explanation and wherever omitting it would mislead.

For the demo cut, I'd spend less time introducing the problem and more time showing what the saved view contains. The viewer should be able to follow the change from four tasks to two, see where the view is saved and recognize the same filters when it opens again.

This proposed 40-second version gives the interface more room. A longer cut isn't automatically better; those extra seconds have a job because this viewer is evaluating the workflow.

0-6 seconds | Show All tasks.
Narration: Here's how to keep the filters you use for a weekly review.

6-14 seconds | Select Status: Blocked, then Sprint: Current.
Narration: Choose the status and sprint you want to review. The list now shows the two tasks that match.

14-22 seconds | Save the filtered view as Weekly review.
Narration: Save this combination as Weekly review so you can open it again.

22-30 seconds | Return to All tasks, showing the full list.
Narration: You can go back to the full task list without replacing the saved view.

30-37 seconds | Reopen Weekly review and show both filter chips.
Narration: Opening Weekly review brings back the same filters and the matching tasks.

37-40 seconds | End on the saved-view control.
Narration: Try it with the filters you use most often.

Notice that the narration names the controls instead of repeatedly describing the feature as powerful or simple. If sharing, permissions or automatic updates matter to the buying decision, add them only after verifying how the real product behaves. This fictional example doesn't establish any of those capabilities.

The tempting edit is to show the filter selection, cut straight to View saved and end there. That proves someone clicked save, but it doesn't show what happens when they return. For this feature, the reopening is the useful part of the explanation, so I'd protect it in both versions.

You can shorten the trip back to the full task list, remove an introductory logo sequence or simplify the surrounding interface. Those edits save time without removing the action that supports the claim. Check the small labels at the size the video will actually play, because the filter values are doing real explanatory work here.

Write specific feedback for the next revision

If you need a launch post and a demo on the product page, plan the shared material first: a clean starting state, the important action and a readable result. Then write a separate opening and ending for each destination. That gives you reusable material without forcing every viewer through the same story.

A launch post might introduce the change and send someone to the fuller demonstration. The demo can assume that context and spend its time answering the next question. Cutting the first ten seconds off a video won't necessarily accomplish that, especially if the removed section contains information the remaining steps depend on.

I'd review each cut on its own before publishing. If someone only sees the shorter one, will they know what changed? If they arrive directly at the demo, will they understand the starting state without reading the announcement first?

Plan versions for different product-announcement placements

A screen recording can be enough when the actual interaction is the main thing to explain. An animated treatment can help you control the framing and focus, but it also gives you another thing to check: whether the simplified interface still represents the product accurately. Choose the approach after deciding what the viewer needs to see.

Impractical's current agent workflow supports creating a draft, editing its source, reviewing frames and requesting an MP4 export. You still need to give it the actual product behavior and review the result. The tool doesn't decide whether your audience needs an announcement, an evaluation demo or a tutorial.

Audience: [Who is watching, and what do they already know?]
Question to answer: [Why should I care, or how does this work?]
Feature shown: [One specific capability]
Starting state: [What is on screen before the action?]
Required evidence: [The action and result that support the claim]
Details we can leave out: [Setup or context that belongs elsewhere]
Destination: [Where this cut will appear]
Next action: [What the viewer should do after watching]

If people understand the problem but can't tell what your product does, I'd start with a focused demo. It gives you a concrete explanation you can link from your site and use inside a later launch announcement. If the workflow is already clear and you're introducing an important change, a launch cut may be the more useful next piece.

There isn't a universal rule that one format converts better. For this decision, I'd ask someone who hasn't helped write the script to watch the rough cut and explain what they learned. If they can repeat the benefit but can't describe the product action, the demo needs more evidence. If they can describe every click but don't know why the feature matters, the launch story needs more context.

You don't need to solve both problems by adding more scenes. Decide which question this particular video is responsible for answering, make that explanation clear, and give the viewer somewhere sensible to go next.