Who this is for: Founders and product marketers preparing the first creative handoff for a software launch.
What to prepare
- A description of the intended viewer and their current task
- A verified list of available product behavior and access conditions
- Approved screenshots, brand assets and exact product terminology
- The destination and action the viewer should take
Turn an aspiration into a decision
“Make our launch exciting” leaves nearly every important choice open. A producer still needs to decide whether to explain the category, demonstrate a workflow or announce availability. Replace the aspiration with an observable communication goal: after watching, the intended viewer should be able to describe one task the product helps them perform.
Do not ask one short film to prove the entire business. If pricing, setup, security review and every feature all compete for attention, decide which questions the surrounding launch page will answer. The brief should name those exclusions so omitted material is a deliberate choice.
A filled brief for a fictional request-triage product
The following is an illustrative planning example, not a customer project or a tested video. The imagined product collects requests and lets a coordinator assign an owner.
- Viewer: an operations coordinator who receives requests from several colleagues.
- Communication goal: show how one incoming request gets an explicit owner and a visible status.
- Lead message: “Give every request a clear next owner.”
- Evidence to show: an unassigned request, an owner selection and the same request displayed with the selected owner.
- Creative treatment: a calm interface-led sequence with large labels and one active area at a time.
- Availability: use the actual release status supplied by the product owner; keep the draft labeled “status to confirm” until verified.
- Next action: visit the launch page for the current access options.
- Excluded claims: no promised time saving, no claim that every request is captured and no invented customer outcome.
Give each scene a source and a purpose
For the example, request three matching interface states: the unassigned item, the owner menu and the assigned item. Use the same fictional request title and account throughout. A screenshot of an unrelated dashboard is not a substitute for the assigned state, even if it looks more impressive.
Write an asset note beside each planned scene: file, relevant region, exact label and any information that must remain visible. If the assigned state is unavailable, mark the scene as unresolved. Do not let a producer invent the behavior to complete the sequence.
A practical 30-second starting outline is 0–5 seconds for the request problem, 5–12 for the unassigned item, 12–21 for owner selection and confirmation, and 21–30 for the product name and next action. Adjust these intervals after checking copy and visual complexity. They are planning choices, not proven ideal timings.
Define approval before polishing the motion
Separate message approval from visual refinement. First confirm the viewer, promise, evidence and availability language. Then review the storyboard for missing context. A polished transition cannot repair a scene that implies an unsupported product action.
Make acceptance criteria inspectable: the same request stays visible across the handoff; the assigned owner can be read; the closing action matches the live destination; and no claim goes beyond the supplied evidence. A comment such as “needs more energy” becomes useful only when the reviewer identifies a moment and explains what the viewer is failing to notice.
Review checklist
- The brief names one intended viewer and one task they recognize.
- Every product action in the outline has a supplied or verified source.
- The example data and any provisional assets are clearly labeled.
- Availability and the final destination have a named fact-check owner.
- Acceptance criteria describe visible results rather than subjective enthusiasm.