Anatomy of a changelog people actually read
Most release notes are a graveyard. A few simple structural changes turned ours into our best re-engagement channel.
Sasha Kim
Product Marketing at FeatBudy
Most product changelogs are written for the team that shipped the feature, not for the user who is about to discover it. The result is a wall of developer-facing bullet points that no one reads, and no one is supposed to.
We changed our format six months ago and turned our changelog into our highest-CTR email. Here is what we changed and why.
Lead with the outcome, not the feature name
Bad: “Added bulk status update.”
Good: “Update 50 feature requests in one click.”
Users do not care that you built a thing. They care what they can now do that they could not before. Every changelog entry should start from that outcome.
Close the loop with voters
When you ship something that was requested, notify the people who asked for it. This is the single highest-ROI touchpoint in the feedback lifecycle.
- Send a targeted email to voters when their request ships
- Link directly to the feature or the docs page
- Thank them by name if the segment is small enough
The best re-engagement campaign you can run is “we built what you asked for.”
Show the before/after
When the change is visual, show a screenshot. When the change is a workflow, describe the old path versus the new path in two sentences. Context collapses the gap between “this sounds nice” and “I need to try this today.”
Sasha Kim
Product Marketing at FeatBudy
Sasha turns user research into messages people remember. She writes about changelogs, surveys, and turning quiet users into loud advocates.