Resources/12 min read

From product launch to usable cutdowns

How to plan one technical capture so it yields a hero cut, a docs cut and social versions without a reshoot — and without the UI going stale or the review collapsing.

  • Planning
  • Launch
  • Review

01

One capture, several jobs

A launch video gets made. Three weeks later someone asks for a thirty-second version for LinkedIn, a ninety-second version for the docs page, and a cut that leads with the customer rather than the product. None of that was planned for, so it becomes a reshoot, a bad crop, or nothing.

The fix is entirely upstream. The derivative set is a decision you make before the capture, not a favour you ask for after it — because the things that make a cutdown possible (frame safety, isolated takes, a version-stamped UI) cannot be added later.

One scope note, because it matters for planning: this is about what a single technical capture can legitimately produce. A customer story still needs the customer, and an interview still needs an interview. Knowing which assets need their own shoot is half of what this document is for.

02

Decide the set before you shoot

Name the assets at the script stage and every downstream decision gets easier. Each one carries a different job, and the job dictates the framing, the length and whether it can come out of the same capture at all.

FigurePlanned before the shoot, one capture yields every cut in the set. The customer story is the exception.
AssetLengthWhat it has to carrySame capture?
Hero cut2–4 minThe whole argument: the problem, the mechanism, the proofYes
Docs cut45–90sOne task, start to finish, no narrativeYes
Social cutdowns20–45sOne claim, legible with the sound offYes
Feature clip10–30sA single interaction, in-product or in a release noteYes
Customer story90s–3 minThe person and their result, not the productNo — needs its own interview

The last row is the one people get wrong. A customer story cannot be extracted from a product capture, because the thing that makes it work is a human being saying something you did not script. Plan it as a second capture, or plan to do without it.

03

Protecting UI accuracy

A technical video ages badly for exactly one reason: the interface in it stops matching the interface the viewer has open. Every choice below exists to make a stale screen cheap to replace instead of fatal to the asset.

  • Capture size

    2×

    Twice the delivery resolution, so a crop into one region of the UI is still native pixels rather than an upscale.

  • Takes

    1 screen

    One screen per take. When a screen changes you replace a take — screens captured in one continuous pass mean re-cutting the whole thing.

  • Account state

    1 fixture

    The same seeded account across every asset, so names and numbers never contradict between one cut and the next.

  • Version stamp

    Always

    Product version, date and any flags that were on, written down at capture. Six months later this is the difference between a re-cut and a reshoot.

FigureWhy capture at twice the delivery size: a cutdown that zooms into the interface still has real pixels to zoom into.

Do

  • Seed data a real engineer would believe — plausible latencies, sane IDs, consistent timestamps
  • Record with the cursor slowed and no highlight rings
  • Keep the raw captures alongside the finished edit
  • Re-record a single screen when it changes, and drop it into the existing timeline

Don't

  • Capture anything mid-migration or behind a flag due to flip
  • Upscale a screen recording to fill the frame
  • Blur a region to hide something you should have seeded properly
  • Let the same product show two different account states across the set

04

Review ownership

Technical video review collapses in a predictable way. An engineer flags a wrong flag, product marketing wants the positioning changed, design wants the UI reshot, and nobody in the thread knows who decides. The cut goes round four times and arrives late without getting better.

The fix is not more process. It is naming, before the first review, who owns which layer and what each of them is allowed to block on.

LayerOwnerCan block onCannot block on
Technical accuracyA named engineerWrong command, wrong architecture, impossible dataPacing, wording, music
PositioningProduct marketingClaims, naming, competitive framingTechnical detail
BrandDesignLogo, type, colour, motionScript structure
Final cutOne named approverAnything—

Then run the reviews in an order that matches what is cheap to change. A technical correction arriving at fine cut is the single most expensive note in this format, because the motion graphics have already been built on the wrong frame.

FigureThe same technical note, arriving at each review stage. Free at the script; expensive once the graphics are built.
  1. Script

    Technical and positioning together

    Both sign off before anything is captured. This is the only review where changing your mind is free.

  2. Rough cut

    Technical accuracy only

    Is anything wrong? Wording and pacing notes are out of scope and should be held.

  3. Fine cut

    Positioning and brand

    Graphics, claims, naming. The structure is settled by now.

  4. Final

    One approver, one round

    Not a committee. Whoever holds this seat was named at the script stage.

Notes go in one place, against a timestamp. A note given verbally on a call did not happen, because the person who has to act on it is not the person who heard it.

05

Cutting the set down

A cutdown is not a shortened video. It is a different argument built from the same material, and the reason most of them fail is that they keep the setup and lose the claim.

The vertical versions carry one more constraint, and it is the one that has to be settled before the capture: you cannot crop a 16:9 interface into 9:16 and still have an accurate UI. Either the frame is composed with a centre-safe region from the start, or the vertical version rebuilds its frame around the interface rather than cropping to it.

FigureCropping a 16:9 interface to 9:16 cuts it apart. A vertical version needs its frame rebuilt around the interface.
  • Keep

    • The claim, in the first two seconds
    • The single strongest visual moment
    • One number, if there is one
  • Cut

    • The setup and the context
    • The second and third examples
    • Anything that needs earlier material to make sense
  • Add

    • Burned-in captions, always
    • A frame rebuilt for the aspect ratio
    • An end card that names one next step

06

What gets handed over

Whoever makes the next re-cut is often not whoever made this one. The handover is what decides whether that costs an afternoon or a reshoot.

  • Delivered

    • Graded hero cut, per-platform exports
    • Captions as SRT, not burned into the master
    • Chapter list and description copy
  • Source

    • Raw captures, version-stamped
    • Edit and motion project files
    • Fonts, logo lockups, brand assets used
  • Written down

    • The seeded account and how to recreate it
    • Product version and flags at capture
    • Who owned which review layer

07

Do and don’t

Do

  • Name the derivative set before the script is approved
  • Capture one screen per take at twice the delivery size
  • Give every review layer an owner and a boundary
  • Run technical review at rough cut, when it is still cheap
  • Hand over the source files with the export

Don't

  • Promise a customer story out of a product capture
  • Crop a 16:9 interface to vertical and call it a cutdown
  • Open a cutdown with the setup instead of the claim
  • Take technical notes at fine cut without expecting a cost
  • Ship a master with the captions burned in

Now the hard part

Knowing this and doing it are different jobs. We do the second one.

Book a call→

Next guide

PLG/GTM video toolkit

15 min read →