Product updates people actually read
How to announce product updates without writing the same thing five times, a product announcement template to copy, and three real companies worth stealing a habit from. I ship most days, so I need this to be cheap.
Definition
What a product update is
A product update is a change to software people already use. A new feature, an improvement, a bug fix, a removal. Announcing it is how the people who use the product find out. Most updates don't need an announcement bigger than one line, and a few deserve a real launch. Telling those two apart is most of the skill.
A product update is also different from a changelog entry, slightly. The changelog is the record of everything. An update announcement picks the parts a given audience cares about and says why. The changelog format guide covers the record. This page covers the telling.
Channels
Where product updates go
- A public changelog. The source of truth. Every other channel links here. If you only do one thing, do this.
- In the app. A badge, a banner, a "what's new" panel. Reaches people while they're using the product, which is the only time some of them will see anything.
- Email. For the updates big enough to interrupt someone. A monthly roundup works for everything else. The product update email templates are on their own page.
- Social posts. X, Bluesky, Mastodon, LinkedIn, Threads. One change per post, with the link to the changelog entry.
- Community spaces. Discord or Slack, where the people who care most already hang out.
- Release notes in the repo. For developer tools, a GitHub release on the tag. The release notes template has a copy-ready version.
Method
How to announce a product update
The method I use, which survives shipping most days:
- Size it. A fix gets a line in the changelog. An improvement gets a line and maybe a post. A feature that changes how someone works gets the full announcement and every channel.
- Write it once, for the user. One paragraph on what someone can now do. Not the branch name, not the internal cause. This becomes the changelog entry.
- Cut it down per channel. A post is one beat of that paragraph and the link. An email is the paragraph and a screenshot. Same facts, different length.
- Publish the changelog entry first. Everything else links to it, so it has to exist before the links do.
- Close the loop. If someone asked for the change, tell them directly. That reply is worth more than every post combined.
Template
A product announcement template
For the big ones. Paste it, fill the brackets, delete any line that doesn't apply. It works as a changelog entry, a blog post, or the body of an email.
Headline: [What you can do now], in the words a user would search for.
[One sentence on who this is for and the problem they had before.]
[Two or three sentences on what it does. Name the button, the command,
or the setting. Show it with one screenshot or one code block.]
[How to get it: on by default, behind a setting, or on which plan.]
[What it doesn't do yet, if someone will ask.]
[One link: the docs or the changelog entry.]And for the small ones, which is most of them:
Fixed: [the symptom people saw], in [where it happened].
Thanks to [person or issue link] for the report.The "what it doesn't do yet" line is the one people skip and the one that saves you the most support email. Saying the limit out loud reads as honest. Leaving it out reads as hiding it, once someone finds it.
Examples
Product update examples worth copying
Three companies, each good at one specific thing. For changelog pages in particular, the changelog examples page goes deeper.
Linear
Each changelog entry has a date, a headline, an image, a few paragraphs on the main feature, and then separate lists of fixes and improvements, each tagged with the part of the product it touches.
Steal this. Lead with one feature, then let the small stuff ride along as a list underneath it.
GitHub
Every entry is labeled Release, Improvement or Retired, with topic tags and a filter, and the page offers an RSS feed. Retirements get announced in the same place as new features.
Steal this. Announce what you remove where you announce what you add. Nobody should learn about a removal from a broken build.
Supabase
Launch Week batches the big announcements into one week, a new feature each weekday, with a hackathon and meetups around it. Routine updates still ship the rest of the year.
Steal this. Save the big ones for a moment people expect, and keep the small ones flowing in between.
Disclosure
How I do it
I built Merge & Tell because step two of that method, writing it once, was the step I kept skipping. It reads each merged pull request, drafts the changelog entry and a post per network, and puts them in a queue. The networks I've set to publish on their own go out without me. The rest wait for a look. It covers the changelog, social networks, Discord, Slack and WordPress. It doesn't send email, so the monthly roundup is still on me.
The result is the updates page on this site, written from my own merges.
Honesty
What an announcement won't fix
A great announcement for a feature nobody asked for is still a feature nobody asked for. And no channel works if it only fires at launch. The companies above are worth copying for their cadence more than their copy. They announce small things often, so the big ones land on people who were already listening.
Write it once. Let the merge do the telling.
You were going to merge the PR anyway.