How to write release notes people actually read
Most release notes are written for the team that shipped them. The ones people read are written for the person using the product: what changed for them, and why it matters.
What to include
- A date and a short title for each release.
- Each change in one line, starting with what the user can now do: “You can now export ideas to CSV” beats “Added CSV export endpoint”.
- Group changes as New, Improved and Fixed. Put the most useful change first.
- Credit the people who asked for it, if you track requests. It shows you listen.
- Leave out internal work (refactors, dependency updates) unless users will notice it.
A template
## October 31, 2026: Faster exports
### New
- You can now export all your data to CSV from Settings.
### Improved
- Search results load about twice as fast.
### Fixed
- Dates on the dashboard now show in your own time zone.Where to publish
- A public changelog page: good for search and for people evaluating your product.
- Inside your app: a “What’s new” badge or widget reaches people while they use it.
- Email: for big releases, sent to people who opted in.
- Where your users already are: a short post linking to the full notes.
Drafting help
UserNote’s free release notes generator (also mine) turns a list of what’s new, improved and fixed into a changelog entry in Markdown or HTML, an email, and posts for X and LinkedIn. No sign-up: getusernote.com/tools/release-notes-generator