release-notes

# Release Notes Built on the audience-tiered changelog framework: one set of shipped changes, three lenses. The same release reads differently to a user (what's in it for me), an internal team (what changed, why, and what it affects), and a social audience (a hook worth clicking). You write all three from a single source of truth so nothing drifts. **Grounded in:** *Working Backwards* — Bryar & Carr: lead with the customer benefit, audience-tiered. **Go deeper (The Product Channel):** [The Beginner's Guide to a Product Launch](https://sidsaladi.substack.com/p/week-19-the-beginners-guide-to-a) ## When to use this - A sprint or release closed and you have a pile of merged PRs, tickets, or commit messages to turn into something readable. - You're shipping a customer-facing feature and need both an in-app/email changelog and a Slack/social post. - Support or sales keeps asking "what actually changed in this release?" and you need an internal log they can scan. - You want to announce a launch on LinkedIn/X without leaking jargon, internal names, or unshipped roadmap. - You're standardizing a recurring changelog (weekly/biweekly) and want a repeatable format. ## Before you start (gather these) - **The raw change list** — PR titles, ticket IDs, commit messages, or a plain list of what shipped. - **Release identity** — version/date/name (e.g. `v2.4` or `Week of June 14`). - **Audience reach** — who sees the user-facing tier (all users? a plan tier? beta cohort?). - **Change types...