How to announce a new feature (without the silence)
5 min read
Most feature announcements die in a channel nobody reads twice: a tweet that scrolls past, a release-day email buried under the other twelve a subscriber got that week, a Slack message in a channel half the team muted months ago. The feature shipped. Almost nobody who would have used it found out. Fixing that is less about writing a better announcement and more about picking the right channel for the right reader, and reaching the people who specifically asked for this one directly rather than relying on them to notice a broadcast.
Where should a new feature actually be announced?
In more than one place, because “everyone reads the same channel” is never true. A changelog or feed entry serves the reader who checks in on their own schedule and wants the permanent, dated record. An in-app notice serves the reader who is already using the product and would use the feature today if they knew it existed. Email serves the reader who is not currently in the product but would come back for the right update. Social serves reach beyond existing users entirely, at the cost of almost no targeting.
| Channel | Best for | Weakness |
|---|---|---|
| Changelog / feed | The permanent record; readers who check on their own schedule | Passive; does nothing for someone who never checks |
| In-app notice | Users who are already there and would act today | Reaches nobody who isn’t currently logged in |
| Users who are not currently active but would return for this | Easy to bury under other mail; needs a real subject line | |
| Social | Reach beyond current users | Almost no targeting; short shelf life |
None of the four is sufficient alone. The changelog is the one document that should carry every release regardless of size, because it is the record everything else points back to; the other three are amplification layered on top of it, chosen by how big the feature actually is.
What should the announcement say first?
The outcome, not the mechanism. “We added a caching layer to the reports endpoint” describes what the team built. “Reports now load in under a second” describes what changed for the reader, and it is the sentence that gets someone to click through, because it answers “what’s in it for me” in the first clause instead of the third. The mechanism belongs in the changelog entry or the detail page, not the headline.
Lead with specifics over adjectives. “A faster, more powerful reports experience” tells the reader nothing they can act on; “reports now load in under a second, and can be filtered by status” tells them exactly what changed and what to go try. The second version also reads as more credible, because a vague claim is what marketing copy sounds like when there is nothing concrete to say.
How is this different from a product update email?
Overlapping but not identical. Product update email covers the email channel specifically, including cadence, subject lines, and when a digest beats a one-off send. A new feature announcement is the underlying event; the email is one of the four channels above that might carry it, chosen when the feature is big enough to justify a dedicated send rather than riding along in the next digest. A small feature earns a changelog entry and maybe an in-app notice. A significant one earns all four channels, timed together.
How do you reach the specific people who asked for it?
This is the announcement with the best return for the least effort, and most teams skip it. If ten customers requested a feature
by name, those ten people are worth a direct, personal note the moment it ships, independent of
whatever broader announcement goes out. Closing the customer feedback loop
covers the mechanics in full; the summary here is that this only works if the original request
stayed linked to the requester, which is a tracking problem more
than an announcement problem. In Changeloop, when widget feedback became a GitHub issue and the
merged pull request closes it (fixes #142), approving the changelog entry posts a
“Shipped —
How do you write the entry itself?
The same discipline as any other release notes entry: lead with what the reader can now do, follow with any setup required, skip the internal justification. How to write release notes covers the full method; a new feature announcement is the highest-stakes case of it, because it is the entry most likely to be screenshotted, forwarded, and read by someone who has never seen the product’s changelog before.
When should you not announce something widely?
When the feature is still rolling out to a subset of accounts, is genuinely a beta, or is priced or gated in a way that most readers of a broad announcement could not use yet. A wide announcement for a feature nine in ten readers cannot access reads as a bait, and it burns trust in the next announcement more than it builds excitement in this one. The fix is not silence, it is scope: tell the eligible accounts directly, and hold the broad channels until availability catches up to the announcement.
FAQ
Should every new feature get its own announcement? Every one earns a changelog entry. Only the ones significant enough to change how someone uses the product, or that were explicitly requested by name, earn the wider channels like email or social.
What’s the best channel for a small feature? The changelog alone, plus an in-app notice if the feature is discoverable inside a flow the user is already in. Email and social are worth saving for features that justify asking for attention.
How do you announce a feature to the people who requested it, specifically? Keep the request linked to the requester from the moment it is filed, then notify individually when it ships, separate from any broader announcement. A shared status label a requester can check also reduces how many people need a direct message in the first place.
Does a new feature announcement need a screenshot? For anything visual, yes; a described-but-unseen feature gets skipped far more often than one readers can see a preview of. For an API or backend capability, a short code sample does the same job a screenshot would for a UI change.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.