Release impact and refresher
Objective. Turn a product release into a short, honest account-impact note and a self-refresher - what actually changed, who it affects, what you may now say, and what is still confirm-with-product.
A lightweight template for staying current without over-claiming on new features. For each release it captures what changed at capability level, which accounts and conversations it affects, what you can now say confidently, and what remains unverified. It keeps you from demoing a feature you have not seen and from promising a change you cannot confirm shipped.
See it in the demo
What it is and when to use it
A release impact and refresher note is how a Sales or CSM person absorbs a product update responsibly. Use it whenever a release lands, before a demo or QBR that might touch the changed area, and as a periodic self-refresher on an application you sell or support. It does two jobs: it stops stale claims (demoing something as it used to be) and it stops premature ones (promising a feature as shipped before you have confirmed it). The note is short on purpose - if it takes more than fifteen minutes you are writing a spec, not a refresher.
The note - copy this
Release impact note - <release / date>
- What changed, in capability terms: (what a user can now do that they could not, at app-logic level)
- Which application(s) and areas:
- What I verified myself: (saw it in the demo / confirmed with product - cite which)
- What I am told but have NOT verified: (keep separate - confirm-with-product)
- Accounts affected: (who asked for this, who it changes the story for)
- Conversations to update: (open deals, pilots, QBRs, promises that referenced the old behaviour)
- What I can now say confidently:
- What is still confirm-with-product: (entitlement, availability per plan, exact behaviour, dates)
- Demo link to re-check before I show it:
- Action + owner + date: (e.g. update pilot charter, tell the sponsor, re-record the demo beat)
How to fill it
Describe the change by what a user can now do, not by feature name - capability is what the customer cares about and what you can honestly demo. Keep 'verified myself' and 'told but not verified' strictly separate; only the verified column is safe to state to a customer, the rest is confirm-with-product. Scan open pilots and QBRs for any promise or claim that referenced the old behaviour and flag them to update - a release can quietly invalidate something you said last month. Before you demo the changed area, re-check it in the demo lab so you are not showing a stale flow. End with one concrete action, because a refresher that changes nothing in your accounts was not worth writing.
Honest caveat
A release note does not confirm availability - whether a change is in a given customer's plan or environment is confirm-with-product and may be gated by entitlement or rollout stage. Do not announce a feature to a customer on the strength of a changelog you have not seen working; the demo lab and product confirmation are what let you speak. Never promise a date or a behaviour you have not verified, and never retro-fit a new feature into a closed business case as if it were there all along. If a release changes a metric's definition or behaviour, treat that as a metric-glossary and investigation update, not just a feature note.
Interpretation check
A release note tells you what capability changed and who it affects; it does not confirm that a given customer has it. Only the self-verified column is customer-safe - availability, entitlement, behaviour and dates stay confirm-with-product.
Practical task
Take the most recent release relevant to an application you sell or support and write the full note. Keep the verified and unverified columns separate, list the accounts and open conversations it affects, and finish with one concrete action and owner.
Self-check
Why describe a release by capability rather than feature name?
Because what a user can now do is what the customer cares about and what you can honestly demonstrate; a feature name without verified behaviour invites over-claiming.
A changelog says a feature shipped. Can you tell a customer it is available to them?
No. Availability per plan and environment is confirm-with-product; confirm it and ideally see it in the demo lab before stating it. The changelog alone is not customer-safe.
What should you scan after every release that touches an application you support?
Open pilots, QBRs and promises that referenced the old behaviour - a release can invalidate a claim you made, and those conversations need updating.
A release changes how a metric is calculated. What else must you update?
The metric glossary and your interpretation / investigation habits for that metric, not just the feature note - a changed definition can change every reading that depends on it.
Verified vs demo. By construction this tool separates what you verified (in the demo lab or confirmed with product) from what is only reported; availability, entitlement, exact behaviour and dates are confirm-with-product and never asserted from a changelog.