Media Angles
Part of Digital PR for product and company news
Identifying what genuinely changed in a product announcement
Compare the product before and after a release, confirm access and timing, and describe the change a product announcement can support.
Compare the product before and after the proposed release. State the exact change, who can use it and when access starts. If those points are unsettled, call the announcement a plan or wait until they are confirmed.
Record the before and after
Ask the product owner for the previous public position, the approved new position and the evidence for each. A new name, a refreshed screen and a new capability are distinct changes. A redesign should not imply a new function; a private trial should not imply general availability.
Field / Question for the product team
- Previous state
- What could an eligible user do before the change?
- New or planned state
- What can that user do now, or what is planned?
- Access
- Which users, plans, devices or locations qualify?
- Timing
- Is it live, staged, in trial or still planned?
- Proof
- Where can the difference be seen or documented?
Write a headline only once the answers agree. Resolve any conflicting accounts of access or timing before making a public claim.
Before and After: Product Change Analysis
- Previous State
- Available only to selected trial accounts in Australia
- New or Planned State
- Available to all eligible Australian accounts
- Access
- Eligible users with active Australian accounts
Verifying a Product Announcement
- Confirm the previous public positionReview product documentation and release notes prior to the change
- Identify the new or planned stateObtain updated information from the product owner or release team
- Verify access and timingCheck eligibility criteria, device compatibility and rollout phase
- Gather evidenceReference official release notes, screenshots or user guides
- Draft headline only after alignmentEnsure consistency across product page, release note and media claims
Name the type of change
For a new product, establish what exists and who can obtain it. For a feature release, describe the changed function. For a wider rollout, state who had access before and who gains it. For a roadmap item, use conditional language and explain what remains uncertain.
Suppose a feature was available to selected trial accounts and is now available to all eligible Australian accounts. That is wider access. Calling it a newly invented feature would hide the earlier trial; calling it available to every Australian would ignore eligibility. The useful sentence names the expanded group and the condition.
Explain why the change matters
Ask what task becomes possible or different for the affected user. Describe how the change works, then check the evidence for any claimed outcome. A demonstration of fewer steps can support a description of those steps; alone, it cannot show that all users save time.
A change may warrant a customer update without offering much to a broader newsroom. If the difference is only a new marketing label, describe it accurately. If it changes access or use for a publication's readers, explain that consequence within its limits.
Before release, compare the proposed headline with the product page, release note and approved availability information. They should describe the same product, audience and release state.
Key Metrics for Product Announcements
- Eligible Users Affected
- All Australian account holders
- Change Type
- Wider rollout (not new feature)
- Impact on User Task
- Fewer steps to complete transaction
- Evidence Source
- User testing and internal release documentation
