Explain a technical feature in a launch video

When to use this guide

Use this if you write product launches and an engineering change is hard to explain in customer terms. A CRM now identifies duplicate contacts. Support leads need to see what happens to two matching records before they trust the feature with their queue. Bring the release note, two sample records and the verified outcome.

Step 1. Identify the change a customer can verify

Ask the product owner for one before-and-after case with approved example data. Identify who encounters it, what they do, and which result they can check. For a duplicate-record feature, you might show the two sample inputs and the resulting review screen. Confirm exactly what the system does when fields disagree before putting a claim in the narration.

If the launch concerns internal maintenance and customers do not need to change how they work, written release notes may be enough. Reserve video for a change that benefits from seeing a sequence, a screen or a relationship.

Step 2. Set up two records that demonstrate the rule

Take the duplicate-contact example. Make two fictional records for the same email. Give one a recently confirmed phone number and the other an old number plus a useful note. Ask the product owner what the released merge rule actually retains, how a conflict is surfaced, and whether the action can be undone. Capture the approved test result before writing the ending.

Start the video with the problem as the customer sees it: the same contact appears twice and a rep could call the wrong number. Show the two records, run the supported reconciliation action, and reopen the surviving record. Pause where the viewer can check the phone and note. If a person must confirm a conflict, show that decision. A diagram can explain the matching rule, but it cannot substitute for the resulting record in this example.

Write the scope as carefully as the benefit. “Contacts with the same verified email can be reviewed together” is a narrower claim than “Duplicates disappear automatically.” If only a workspace administrator can run the action, put that prerequisite before the first click. Someone with a member account should understand why their screen differs.

Step 3. Capture the review decision and its result

Use real screenshots or a recording for controls people must locate. Use labels to identify the important change. If the explanation involves a rule that happens off screen, use a diagram and label it as an explanation. Keep the rule separate from the observed result: a drawing of two records merging is not a demonstration of how your product handles conflicting data.

For duplicate review, put two sample contacts in a demo workspace with the same email. Give ngram Studio the product link and ask for a video showing the review decision. Use Browser Handoff if the site needs a login. Check that the chosen record and the resulting status are visible before adding a diagram of the matching logic.

Try this brief: “Introduce duplicate review to support leads. Use the attached screenshots to show two sample contacts before review and the resulting customer record. Use the approved note for the conflict rule. End by showing where a lead can inspect the result.” The feature announcement workflow can help frame the release for existing users.

Step 4. Explain what happens between the two screens

Play the cut from the two contact records through the review decision. Explain which field makes the pair eligible for review, who decides whether to merge them, and what that person sees afterward. Pause on the surviving record long enough for the viewer to check the retained details.

Step 5. Test the claim against a second pair of records

A product manager might write “We made duplicate handling smarter.” Turn that into a sentence a sales rep could demonstrate: “Review two matching contacts, resolve the conflicting phone number, and reopen the surviving record to check the chosen value.” Every part should point to a real action in the released workflow. If the release doesn't support manual conflict resolution, revise the sentence and the footage together.

Ask the release owner to identify the strongest counterexample. Do similar names with different emails qualify? Can a member without merge permission use the feature? Put the relevant exception beside the launch note. A confident “not for this case” is useful to a buyer deciding whether to try the feature.

Try two records with similar names and different emails. If the release doesn't establish that those records should merge, leave them separate in the explanation. Now ask a reviewer who did not build the feature to predict what will happen in each case. Their answer reveals whether the launch video taught the matching rule or merely showcased a successful animation.

Step 6. Check whether a viewer can explain and try the change

After watching, could the intended viewer say what changed and what to do next? If they remember the product name but cannot find the control, replace a general scene with an actual screen. If they can find the control but still cannot explain the result, slow down the comparison. Review the script and storyboard before generating another cut; a missing fact belongs in the plan.

Finish the launch review by asking someone outside engineering to repeat the demo in a sample workspace. If their expectation diverges at the matching rule, repair the explanatory scene. If their screen lacks the control, repair the stated prerequisite.

Use the closing frame to name the next action: review one known duplicate in a sample workspace. Put setup requirements and exceptions in the written release note where readers can find them later. If an exception changes after launch, the team can update its text without forcing customers to rewatch a two-minute announcement.

References and next steps

• Feature announcement videos — choose footage and a call to action for a release.
• Scripts and storyboards — check the wording and the order of the scenes before production.
• Browser Handoff — collect product footage when a website asks you to sign in.