Who this is for: Product teams preparing accurate software update communication.
What to prepare
- The release record and responsible product owner.
- Approved screenshots, recordings or test evidence.
- Current availability, limitations and terminology.
Define the packet around claims and ownership
The packet can be a simple document. Its value comes from clear authority and traceability, not a particular tool. Record the release identifier, status date, factual owner and intended audience. Then list each claim with its evidence and any conditions.
Separate factual approval from creative approval. A designer can approve a composition without confirming a rollout date. A product owner can confirm behavior without deciding whether the typography is readable. Record both responsibilities when needed.
- Release identity and current status.
- Claim, supporting source and confirming owner.
- Asset identifier, capture version and permitted use.
- Audience, role and availability conditions.
- Unresolved question, owner and effect on production.
- Approved wording and the revision it belongs to.
Worked example: an evidence packet for saved filters
For a fictional release adding personal saved filters, the illustrative packet could contain the following entries. These are sample records for the process, not evidence of a live capability.
- Claim C1: a member can save status and owner filters. Evidence request: approved save workflow capture. Owner: product lead.
- Claim C2: saved filters are personal. Evidence request: approved scope statement. Owner: release manager.
- Asset A1: queue before saving, sample data labeled, version recorded.
- Asset A2: reopened named view with retained filters, same sample queue.
- Question Q1: where does the saved view appear? Owner: interface lead. Production effect: reopening scene cannot be finalized.
- Wording W1: “Save a personal view of your review queue.” Approval attaches to the current packet revision.
Resolve conflicts before the scene is polished
If a screenshot and release note disagree, do not choose whichever makes the better story. Ask the factual owner whether the asset is stale, the behavior changed or the wording is incomplete. Mark the disputed claim as unresolved until the conflict is settled.
Link sources directly in the internal packet, with enough context to identify what they support. A general homepage is not evidence of a specific permission rule. Do not copy private source material into a public article merely because it informed the production.
Keep the packet current through production
Give each approved revision an identifier and record which script and asset versions depend on it. When a fact changes, locate the affected scenes rather than asking everyone to remember where it appeared.
At handoff, preserve the approved packet with the final asset. Later editors need to know which claims were supported at publication and which require renewed verification. The packet is a working source of truth, not a permanent guarantee that a release remains unchanged.
Review checklist
- Each product claim has a specific source and factual owner.
- Unknowns are explicit and linked to affected scenes.
- Conflicting sources are resolved before approval.
- Asset versions match the approved release record.
- The final asset can be traced to one packet revision.