How to Write Compelling Software Release Announcements
A release announcement showcases how the user’s experience is better today than it was yesterday. That sounds obvious, but most release announcements seem to forget that there’s a user at all.
So many release announcements just enumerate new features in a way that’s totallly divorced from how real people use the software. The announcement is essentially just a changelog with better writing.
For example, here’s a “changelog” style of announcing a new feature:
Bad: Describe what the dev team did rather than how it benefits the user Added “duplicate” button to the event menu.
Don’t just tell the user that there’s a new button. Tell the user what they can do with that button.
Good: Describe how changes benefit the user Create events 10x faster🔗 When you create a new event, chances are that the first thing you do is copy/paste information from an existing event. Creating events this way is tedious and slow, so we’re sparing you this toil with the new Duplicate feature. When you need to create a new event based on an existing event, go to the existing event, and select Options > Duplicate. Duplicating events is 10 times faster than copy/pasting fields.
Note that the example doesn’t boast about what the software can do. It tells the user what they can do with the software. It speaks directly to the user, describing what happens when “you” create events.
Release notes are not release announcements🔗
Some software companies dump their commit history into a document, add some headings, and call that a release announcement.
Not a release announcement
That is not a release announcement. Those are release notes.
Release notes are fine, but they’re bookkeeping. They’re boring.
If you want users to feel excited about your newest release, give them something more interesting to read than a sterile changelog.
What to feature in a release announcement🔗
What can the user do in the latest version that they couldn’t before?
Which workflows became easier?
Which workflows became faster?
Notice that the questions don’t include, “Which feature took the longest to complete” or “What feature contains the cleverest algorithm?”
I’ve published releases where the flagship feature was a performance improvement that only took a few hours of dev work. Implementation cost doesn’t always correlate with end-user value.
Call it “faster” not “less slow”🔗
Some bugs are so frustrating and time-consuming to fix that you forget why you’re even fixing them in the first place. You lose sight of how the bug affects the user’s experience.
Bad: Focus on what was previously broken Saving a large file no longer freezes the save dialog for 20 seconds.
From the user’s perspective, the new version isn’t just the same software minus a bug — it’s a tangibly better experience.
Focus on the improvement rather than the flaw. Instead of declaring the absence of a bug, celebrate how you improved the user’s experience:
Good: Focus on the improvement rather than the previous flaw Improvements to file saving allow you to save 100 MB files in under 200ms, a 100x speedup from v1.2.
No more “various improvements and bugfixes”🔗
A release announcement should never include the phrase, “various improvements and bugfixes.” You might as well boast that the team proudly breathed air throughout development and used the latest version of the Internet.
If you can’t articulate how a change benefits your users, don’t highlight it in your release announcement. Save the exhaustive list of changes for your release notes, but even there, please leave out “various improvements and bugfixes.”
Make the most of your screenshots🔗
Screenshots liven up a release announcement and make it easier for users to understand new features.
Make screenshots so obvious that the reader recognizes what you want them to see without reading the surrounding text or zooming in. Use cropping, highlighting, or arrow indicators to draw the reader’s attention to what’s relevant.
Bad: Make the reader guess about what in the screenshot is notable
The above image makes it difficult for the reader to see which part of the screenshot is relevant. There are so many UI elements in the screenshot, and none of them have focus.
Good: Make the relevant part of the screenshot obvious
The second screenshot draws the reader’s focus more clearly by using a tighter crop and adding an arrow indicator to identify the relevant part of the UI.
Keep animated demos short and sweet🔗
Good news: modern browsers support media formats for playing high-quality screen recordings. We’re long past the days of washed-out, pixellated GIFs and clunky YouTube embeds.
Animated images: WebP and AVIF image formats can show GIF-like animated images, and they enjoy wide browser support.
Embedded videos: H.264 and WebM-encoded videos play natively in the browser with a simple