How to Run a Video Marketing Campaign Around a Product Release: Changelog In, Verified Videos Out, Same Day

Most video campaigns are one-offs built around a moment: a launch, an event, a funding announcement. Software companies have a campaign that recurs on a schedule they already control, and they almost never treat it as one. The release.

If you ship monthly, that is twelve campaigns a year with a fixed structure, a known deadline and content that writes itself. Treating it as a repeatable process rather than a scramble is most of the win.

The brief is the changelog

No creative brief, no kickoff. The changelog is the brief, and the translation is mechanical: each headline item becomes one task with a finish line.

• "Improved cache restore performance" becomes "restore a cache on 3.2 and on 3.1, and time both".
• "New parallel execution flag" becomes "run the same job with and without --parallel".
• "Redesigned permissions screen" becomes "give a teammate read-only access", which is also a task you probably already have recorded and now need to re-run.
• "Various bug fixes" becomes nothing. If it cannot be stated as a task, it does not get a video, and that is the correct outcome.

Five headline items is five tasks. That is the whole planning stage and it takes an hour.

Record on the release build, before it ships

Everything is recorded on the tagged release candidate, not on a nightly and not on production after the fact. Two reasons: the video is accurate to the version it claims, and the recording session is itself a smoke test.

That second effect is worth more than the videos on a bad week. Somebody performing the headline features end to end, on the actual build, days before customers do, catches things that unit tests do not. When a recording fails, that is not a content problem.

Show old beside new, or it is just a claim

Where behaviour changed, run the old version too. Same task, same data, both timings on screen.

"41 seconds on 3.1, 9 seconds on 3.2" is a fact. "Dramatically faster restores" is a press release.

This costs one extra environment and one extra recording per changed behaviour, and it converts a marketing adjective into something a sceptical engineer will forward to their team. If the improvement does not survive being measured, better to find out internally.

The step that stops the library rotting

Here is the part that separates a release campaign from a release announcement, and it runs in the opposite direction from everything above.

Ask which existing videos this release just made wrong. The permissions screen was redesigned, so every video that walks through permissions is now stale. Re-run those tasks on the new build. A clean re-run republishes quietly; a failed one tells you a documented path broke.

Without this step, every release makes your library slightly less true, and the decay is invisible until a customer follows a video into a wall. With it, the library is never more than one version behind. The mechanism is a version tag per video, described in a video-first strategy for software products.

What ships, and where

• One release video, two to four minutes: what changed, each item operated once, old beside new where it matters. Chapters matching the changelog headings.
• One task walkthrough per significant feature, published to the library and linked from the docs page for that feature.
• Two or three short cuts, thirty to sixty seconds each, for social. Cut from the above, never recorded separately.
• The refreshed older videos, republished quietly with no announcement.

Distribution is unglamorous and effective: the release notes page, the in-app what's-new, the changelog entry, the customer email, and the docs page for each feature. Social last, because it is the only channel where nobody was looking for this.

A timeline that fits a release week

• T-5 days: changelog freezes. Translate items into tasks. One hour.
• T-4: environments prepared, including an old-version instance for any comparison.
• T-3: record. Half a day for five tasks once environments exist.
• T-2: cut, caption, write the guides. Identify which existing videos this release invalidates.
• T-1: re-run the affected older videos.
• Release day: publish everything with the version tag, and link from the changelog.

The first time this takes a week and feels like a project. By the third release it is a checklist item, because the environments persist, the format is fixed and the changelog does the planning.

For what the recording step actually involves, see how to make a marketing video for a software product.