From Product Guide to Promotional Video Assets

A finished product guide contains more video material than most launch teams use.

It already names the problem, sequence, artifacts, limitations, examples, and next action. The mistake is treating that guide as background reading, then writing promotional scripts from memory.

That is how unsupported claims enter the launch.

The guide should become the source system for the video, not merely inspiration for it.

Start with a claim ledger

Before writing narration, extract the claims a viewer may hear:

Claim type	Required source	Safe treatment
Product contents	Current delivery registry	State exact files, pages, or modules
Workflow outcome	Product method and artifacts	Describe what the process prepares
Personal example	Preserved project files	Label it as Kevin’s example, not a buyer result
Tool behavior	Current official documentation or tested state	Add date-sensitive boundaries
Customer outcome	Real, permissioned buyer evidence	Omit when none exists

This ledger creates a hard distinction between a demonstrable process and a promise.

If the product is new and has no testimonials, say nothing that implies otherwise. Real project receipts are useful, but they remain Kevin’s evidence of process.

Reduce the guide to one video brief

A useful brief fits on one page:

• audience,
• current problem,
• one promise,
• proof available,
• three teaching beats,
• visual language,
• desired action,
• exclusions.

The exclusions are not legal decoration. They protect the edit from accumulating claims the guide does not support.

For a workflow product, the promise might be: “See how a one-page product brief becomes a reviewable video package.” It should not become: “Make viral videos automatically.”

Write narration for the ear

Guide prose and spoken prose have different jobs.

Narration needs shorter sentences, explicit transitions, and fewer nested qualifications. Read every line aloud. If one sentence requires a breath halfway through, split it.

Use a simple rhythm:

1. identify the viewer’s current friction,
2. show the missing artifact,
3. explain the workflow that creates it,
4. reveal a real example or file,
5. state the boundary,
6. offer one next action.

Do not stuff the table of contents into the voiceover. The viewer needs the product’s shape, not an audio inventory.

Turn narration into scene jobs

Each scene should have one visual job.

“This workflow begins with a brief” can show the actual brief structure. “Every shot has a purpose” can show the shot list. “Corrections return to the source” can show a source file flowing into a rebuilt render.

Avoid decorative images that merely restate the sentence. A character looking at a laptop communicates almost nothing about a pipeline.

The scene plan should record:

• narration span,
• visual job,
• source or generated asset,
• on-screen text,
• duration,
• transition,
• and QA note.

Use real artifacts as proof scenes

The most persuasive visual is often already inside the product.

Show the brief, worksheet, file structure, timeline, candidate log, or final package when the narration discusses it. Crop sensitive information, enlarge the relevant part, and explain what the viewer should notice.

Do not flash a busy screenshot for two seconds. A proof scene needs time and hierarchy. Highlight one region, reduce surrounding noise, and let the narration interpret the artifact.

Real artifacts prove that this workflow and file exist. They do not prove that every buyer will achieve the same output or speed.

Give music a support role

The soundtrack should support the narration’s movement rather than compete for attention.

Define its job in the brief: gentle momentum, tension before the diagnosis, lift during the reveal, or a clean landing at the CTA. Use a mix that leaves stable space for speech. Listen on ordinary laptop and phone speakers, not only studio headphones.

If original music has no clear job, use a simpler bed or none at all. A promotional video does not become more credible because every available creative tool appears in it.

Create images around the edit

The edit should request images, not adapt itself to random outputs.

For every generated scene, specify the ratio, focal placement, action, product objects, shared art direction, and safe area for captions or labels. Keep important text out of the generation and add it during composition.

Thumbnails need their own brief. They are not a frame exported from the middle of the video. A thumbnail must work before the viewer knows the context.

Use one focal subject, a short headline, a recognizable product object, and enough contrast to survive small display sizes.

Build captions from the approved narration

Captions should trace back to the same final narration used for audio.

Kokoro can create controlled local narration. Local Whisper can help draft word timing, but product names and unusual terms still need correction. The final caption source should match the approved script, not an unreviewed transcription.

For vertical video, reserve a caption zone. Do not place captions on top of the generated proof image and hope both remain readable.

A reliable 9:16 frame can use four separate regions:

• hook,
• visual proof,
• captions,
• footer or CTA.

That layout constraint prevents the most common batch-render defect: a correct image and correct text occupying the same pixels.

Use code when the family needs repeatability

Remotion is a strong fit when one campaign needs multiple videos with shared layouts, captions, transitions, thumbnails, and product-specific data.

The manifest can define scene order, narration, asset ids, and metadata. React components can define the visual system once.

This is not automatically faster for a one-off, irregular film. It becomes valuable when corrections must propagate across a family.

If a caption safe zone changes, one component fix can repair every Short. If the product title changes, the data source can update the thumbnail and end card without manual timeline surgery.

Verify the master mechanically

Before anyone watches the creative edit, confirm that the file is technically deliverable:

• expected id exists,
• H.264 video stream,
• AAC audio stream,
• correct dimensions,
• correct aspect ratio,
• plausible duration,
• nontrivial file size,
• audio and caption duration aligned.

Mechanical verification does not approve the story. It prevents review time from being wasted on a broken export.

Review claims and creative separately

One review pass should compare every spoken and on-screen claim with the ledger. Another should judge hook, pacing, composition, captions, sound, and CTA.

Combining these jobs invites tradeoffs that should not exist. A visually exciting sequence cannot compensate for an unsupported sentence. A perfectly factual edit can still be too slow to publish.

After a factual repair, repeat the creative watch because changed narration can alter timing. After a creative rewrite, repeat the claim check because compressed language may overstate the original boundary.

Watch the entire video

Contact sheets catch repeated compositions and obvious crop errors. They do not catch pacing, late captions, awkward narration, music masking, or a CTA that appears before the argument is complete.

Watch the master from start to finish. Then sample it at the actual destination size.

For a batch, compare the family: do all videos open differently, does each product remain recognizable, and do the thumbnails create distinct reasons to click?

Build the publishing handoff

Rendering is not publishing.

The final package should map each video to:

• master file,
• thumbnail,
• title,
• description,
• tracked destination,
• captions,
• publication date,
• platform id after upload,
• and final public URL.

Open the published video in a signed-out session and test the description link. The master proves what was rendered. The public receipt proves what viewers can reach.

Reuse the argument without duplicating the edit

One approved long-form argument can create several useful derivatives without turning every channel into a transcript dump.

An article can expand the reasoning and include source links. A Short can isolate one mistake and repair. An X post can turn the completion test into a compact prompt. A sales-page preview can show the real artifact behind one claim.

Preserve the same factual boundary while adapting the form. Each derivative should have its own opening, pacing, and reason to exist.

This is more work than automatic clipping, but it produces a campaign rather than a pile of repeated excerpts.

Corrections should return to source

If a claim is wrong, repair the ledger and script, then rebuild the dependent audio, captions, and render. Do not patch the final MP4 and leave every source artifact stale.

This is the quiet advantage of an asset pipeline: not content volume, but a visible correction route.

The AI Video Pipeline Toolkit expands this process from brief through delivery. The free Indie Creator Toolkit Roadmap helps determine whether Media is actually the project’s current bottleneck.

A promotional video becomes reliable when every scene can answer two questions: what source supports this sentence, and what visual job makes the sentence easier to understand?

That standard does more than protect accuracy. It removes decorative scenes, vague narration, and claims that cannot survive inspection. The resulting edit is usually simpler, more specific, and easier to repair because every creative decision points back to an artifact rather than a mood board alone.

It also gives the publisher a clean handoff: nothing important has to be rediscovered inside the edit project on upload day.