Identify what the viewer already knows
A problem-aware viewer recognizes a task or frustration but may not know your product. A product-aware viewer already knows the product and may be looking for a specific feature. These are planning assumptions, not fixed labels for every individual. Use them to decide how much context the first shot needs.
For the fictional examples below, NorthStar Notes has a project call note with a next-step section. The examples are scripts and shot plans, not customer data or reviewed cuts.
Brief A: lead with the task
Audience assumption: someone who has just finished a call and needs to find the agreed next action. Opening overlay: “the call ended. where did the next step go?” A short reaction introduces the uncertainty. Then show a real, sanitized product recording opening the project note and revealing its next-step section. End with “check the next step before the follow-up.”
The message does not assume the audience knows the product name or interface. It also does not claim the app writes or sends the follow-up. If the actual app cannot show the assumed section, choose a different feature and rewrite the entire brief.
| Element | Problem-aware plan | Product-aware plan |
|---|---|---|
| Opening | Where did the next step go? | The next steps are in the note |
| Context | Explain the post-call task | Name the feature directly |
| Proof | Open a call note and reveal the section | Show the relevant existing interface |
| Ending | Check the next step | Open the call note |
Brief B: lead with the known feature
Audience assumption: an existing user who knows the app but has not noticed the next-step section. Opening: “the next steps are in the call note.” Show the project, open the note and hold the relevant section. End with “open the call note to find it.” This version can name the interface earlier because the assumed viewer already has context.
Verify the real screen labels and any access conditions. Do not imply that every user already has content in the section; it may require manual input.
Review the two versions as separate briefs
Compare the opening, first screen and closing action. If both versions need the same explanation and show the same task, combine them instead of creating two nearly identical assets. Before publishing, record the actual screens and test whether representative viewers can explain the relevant action. Preserve only observations you really collect.
Use permissioned footage and accurate captions. Neither audience assumption predicts retention or conversions; any performance comparison requires a real, carefully interpreted test.
Copy the planning worksheet
Use this worksheet in your own notes. Fill it with verified product details and actual review observations before sharing an asset.
Audience assumption: __. Task: __. Supported feature: __. Opening: __. Product proof: __. Access conditions: __. Review observation: __.Browse the founder guide library for the next task in your workflow.