Test the product fit before writing
A reference may look compelling while depending on a product behavior your app does not support. List its central promise, the action shown and the result implied. Then compare those items with your own verified feature and available proof. If the match is missing, change the concept or choose another reference; do not invent a capability to preserve the format.
The following is a fictional example for planning. It is not an analysis of a real creator or a claim about an existing business.
Reject the unsupported central claim
Imagine a reference that says “my follow-up sends itself” while showing an automatic send. Your fictional notes product can display next steps in a saved call note but cannot send a follow-up. A renamed copy of the reference would still mislead.
Keep only the general creative function if it fits: a brief reaction followed by a clear task. Replace the claim with “the next steps are in the note,” then show your own real note and section. If your application does not have that section either, choose another verified task.
| Reference promise | Your evidence | Decision |
|---|---|---|
| Automatic sending | Only a saved note is available | Reject the automation claim |
| Find the next step | A real next-step section is visible | Consider an original hook and demo |
| Very fast screen cut | The interface requires context | Slow down or use a tutorial |
| Creator footage | No reuse permission | Create or license your own footage |
Check whether the audience and format fit
A reference can also fail because it assumes a different viewer. A joke about a large sales team may not help a solo app founder understand your feature. Write the intended viewer and the task they need to complete. If the source’s setup requires knowledge your audience lacks, add context or choose another structure.
Consider whether the proof fits the format. A dense screen may need a slower tutorial or slideshow instead of a fast reaction cut. Do not crop away conditions or hide required setup just to imitate the pacing of a reference.
Keep a record of the decision
Record the reference link, the intended structural idea, unsupported claims you removed and your own supporting evidence. Obtain the necessary permissions before using another person’s footage, text, likeness or other protected material. A reference is inspiration, not automatic reuse permission.
Review your final script, captions and actual product view together. Have an unfamiliar person describe the promise and the demonstrated action. If they do not match, revise before sharing. Observing a popular reference does not guarantee the same results for your version.
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.
Reference source: __. Its central promise: __. Your verified feature: __. Unsupported detail: __. Original alternative: __. Rights check: __.Browse the founder guide library for the next task in your workflow.