A feature release video is a short explainer — usually 45 to 90 seconds — that ships next to a changelog entry and teaches one new capability to people who already use your product. The whole game is treating them as a series with a standing visual system, because the series is where the economics work: the first video pays for the world, and every one after it mostly reuses it.
Most teams get this backwards. They produce one big launch video, burn the budget, and then ship the next eight months of features as changelog text nobody reads. The launch video was the expensive kind. Release videos are the cheap kind — but only if you build for the cadence from video one.
A release video is not a launch video
The two get conflated because both are "product video," but they differ on every axis that drives cost and design:
| Launch video | Release video | |
|---|---|---|
| Audience | Strangers deciding whether to care | Users who already have a mental model |
| Job | Excitement: the machine running end to end, framed as a real outcome | Comprehension: one new capability slotted into a model they already have |
| Altitude | The whole story, top to bottom | One feature, at the "what it does and when you'd reach for it" level |
| Length | 60–90 seconds is already tight | 45–90 seconds, and the short end is usually right |
| Frequency | Once, maybe twice a year | Every meaningful release |
The altitude point is the one teams miss. Across sixty-odd produced videos, the working rule for depth is: include only enough mechanism to make the capability's behavior predictable — never an internals deep-dive. A release video for existing users can go even leaner, because it gets to start from what the viewer already knows. It doesn't re-explain the product; it says "you know how runs work — here's what a run can do now."
That starting point also changes the energy. Launch and showcase videos are built to excite. Release videos should be calm, diagrammatic, one-structural-idea pieces. A hype edit on a settings improvement reads as insecurity. If you're making the once-a-year excitement piece instead, the launch video guide covers that job.
Not every changelog line earns a video
The discipline that makes a release cadence sustainable is refusal. In our production planning we keep a standing "cut — never animated" list: topics that will only ever be screen recordings or a docs paragraph, because no diagram earns its keep. UI procedures, settings walkthroughs, permission tables, small fixes, reference facts. That list exists to kill the recurring temptation to animate everything.
The routing test for a changelog entry:
- Does it change the user's causal model? New object, new behavior, a thing that used to be impossible — that's a video. Animation exists to stage what a screenshot can't show: causality, timing, structure.
- Is it a procedure? "Here's where the new button is" — that's a 15-second screen recording, captured in an afternoon, and it's the right artifact. The rule we route by: animate the concept, record the live product.
- Is it a fix or a tweak? Changelog text. Shipping a video for it trains your audience that your videos are skippable.
A healthy cadence for most products is a video for maybe one release in three or four. The videos stay dense, and the audience learns that when a video appears, something actually changed.
One release, one idea
Every video we script opens with a mandatory field: the one idea, in a single declarative sentence the whole video argues. For release videos this discipline matters double, because the lazy default — "this video is about the audit log feature" — produces a feature tour, and feature tours are where release videos go to die.
The one idea is a claim, not a topic. Not "introducing audit logs" but "nothing that runs is a mystery — the record is always there." Not "our new integrations" but "you connect a source once and your agent's knowledge updates itself instead of going stale." The test: is it falsifiable? "This feature is powerful" fails. A sentence the viewer could end the video finding obvious passes.
One more scripting rule that matters more in a series than anywhere else: never frame by a fixed count. "The five new operations" dates the moment you ship a sixth, and the count is never the lesson. Name the capability.
And because a release video is a product claim by construction, ground it. Every on-screen string, number, and label should trace to a real run of the real feature — the grounding method is one email to whoever can operate the live build, sent before the script locks. For release videos this is non-negotiable in a specific way: the product just changed, which means every value borrowed from a previous video is now the most likely thing on screen to be wrong. Product truth drifts; re-derive at every build.
The standing rig: why the second video costs half
Here is the actual economics argument for a release cadence, and it's the part one-off buyers never see.
A finished explainer sits on top of a pile of decisions: a visual language (what a block looks like, what "running" looks like, what travels along a wire), a set of timing constants, a camera grammar, a voice, a music bed, a title treatment. On a one-off, you pay for all of it and then throw it away. On a series, you pay once and freeze it:
- Motion timing is decided once. In our system the durations for reveals, camera moves, and cause-and-effect beats are a tuned table, imported by every video — never re-guessed per project. They were mined from graded-good renders and they are not re-derivable by feel.
- Voice settings get A/B tested once, then pinned. Voice, model, delivery — tested head to head at the start, approved, frozen. Approved audio takes are kept and reused rather than re-synthesized, because regenerating "the same" line produces a different take.
- Surfaces promote on second use. Anything two videos both need — your product's table, your run inspector, your brand's title card — becomes a shared component the third video gets for free. Not before (speculative libraries), not after five (copy-paste drift). Second use.
- Words stay the cheap layer. Because narration is written to the finished picture and synthesized from text, a wording fix on a shipped release video is roughly a 60-second loop: edit the line, re-synthesize one scene, re-render. The expensive layer (the picture) never gets touched for a cheap-layer change.
What this buys you in practice: the first video in a series carries the full cost of building the world. By the third or fourth, production is mostly "new worked example, new one idea, same rig" — the marginal video is a fraction of the first. This is also why per-video pricing from a vendor with no standing system understates your real cost: you're re-buying the rig every time, and it comes back slightly different every time too.
Series consistency is a set of rules, not a vibe
Consistency across release videos isn't just the same colors. The rules that make a series read as one product speaking:
- Each video owns exactly one idea and defers its neighbors. Our curriculum plans literally annotate ownership — this video owns "what an agent block is"; the rest own "what you hand it." When two videos both half-teach a concept, both fail, and viewers feel the overlap as padding.
- No "welcome back." Release videos are watched non-linearly, months apart, from a docs page or a tweet. Every video self-contains its prerequisites at one-line depth and gets to the point. Only a series opener earns a full welcome.
- One home for every fact. Brand strings, product claims, pricing — one source of truth that every script's grounding table points at. Write the same fact in two videos independently and you are creating tomorrow's contradiction.
- "Redo" is a first-class state. A standing series needs a plan of record that marks each video exists / redo / new. When the product outgrows a shipped video, admitting it and queueing the rebuild is part of the plan, not a failure of it. A stale release video is worse than none — it demos a product that no longer exists.
- If a founder fronts them, keep the intro short and framing-only. The working shape: 25–30 seconds, about 70–80 words, a plain noun open ("Audit logs."), two or three concrete use cases, hand off with a bridge line — and never repeat a line the video itself says.
One warning from our own records: consistency is not sameness of beats. A technically clean build that repeated one good beat shape five times drew a one-word review — "boring." The rig stays constant; the worked example and the staging vary every time.
FAQ
How long should a feature release video be? 45–90 seconds of animated content is the working band; our finished concept cores run about 54–124 seconds and release videos should sit at the short end. If the script wants three minutes, it's either two videos or a launch video wearing the wrong clothes.
How fast after the release should it ship? With the code merged and a real run available to ground against, same week. The standing-rig point is exactly this: once the system exists, a release video is a worked example and a script away, not a six-week project.
Can we reuse scenes from the previous video? Reuse the system — components, timing, camera grammar, voice. Don't reuse rendered scenes with the values swapped: every on-screen value has to be re-derived from the current build, because the release you're announcing is precisely what made the old values stale.
Do release videos work without an existing audience? They compound with one, but their first home doesn't require one: the changelog entry, the docs page for the feature, the announcement post. The same video also does quiet duty in onboarding once the feature stops being new.
If you want to see what a standing system would look like on your product, send us your URL — the candidate board is free and every frame is built from your real UI.