Release notes that get read
Write release notes that explain what changed and why it matters to the reader.
1 min read
Most release notes are a changelog written for the team that built the release. Readers want to know one thing: what does this change for me?
Lead with the benefit#
A change is only interesting when the reader knows what it does for them.
| Instead of | Write |
|---|---|
| Refactored export service | Exports now finish up to 3x faster |
| Added scheduling module | Send any report to your team every Monday |
| Fixed currency bug | Invoices no longer show the wrong currency for teams with several workspaces |
A structure that works#
Group changes so readers can scan for what matters to them:
- New. Features and capabilities that didn't exist before.
- Improved. Existing things that now work better.
- Fixed. Problems that are gone.
- Deprecated. Anything that will change, with the date and what to do instead.
# Release notes: March
## New
- **Scheduled reports.** Send any report to your team
every Monday. Open a report and click **Schedule**.
## Fixed
- Invoices no longer show the wrong currency for teams
with more than one workspace.Say what the reader has to do#
If a change needs action, put that first and make it impossible to miss.
Product release docs#
Major launches need more than a list. Pair the release notes with updated user guides, a short "what's new" walkthrough and, for developers, an updated API reference, so the docs are ready on launch day.
Was this page helpful?