How to announce a new feature: channels, copy, and timing

A feature nobody hears about might as well not exist. Most users don't read your commits, don't follow your blog, and open your product to do their job — not to explore. The announcement isn't a nice-to-have after the engineering is done; it's the last mile of shipping. This guide covers the three decisions every feature announcement is made of: how big to go, where to say it, and what the words should be.

First decision: how big is this, really?

The classic mistake is sizing the announcement by effort instead of user impact. A brutal three-month migration that users never see deserves one modest changelog line ("faster and more reliable under the hood"). A two-day feature that removes a daily annoyance deserves a proper announcement. Users don't know or care what was hard.

Three tiers cover almost every ship:

  • Tier 3 — quiet. Small fixes, minor polish, things only some users will notice. A dated changelog entry with a clear title. No push, no email, no post. Most ships are tier 3, and that's healthy — a changelog full of quiet, steady entries is itself a trust signal.
  • Tier 2 — standard. A real capability users will want to know about. Changelog entry with a body (why it exists, how to use it, one visual), surfaced in-app via a what's-new widget, mirrored to your Slack/Discord community if you have one. Maybe one social post. No email.
  • Tier 1 — launch. A handful of times a year: the feature changes what your product is for some audience. Everything in tier 2, plus a real email, a blog-style deep dive, and coordinated social. If you find yourself running a tier-1 launch monthly, you're diluting the signal — users learn to skim past "huge news".

Deciding the tier first settles every downstream argument about channels and effort. Most teams that "aren't sure it's worth an email" are asking the tier question without a vocabulary for it.

One canonical URL, many pointers

Whatever the tier, write the announcement once, in a place with a permanent URL — for most products that's the changelog entry — and make every other channel a pointer to it. The email links to it. The tweet links to it. The widget shows it. The Slack message mirrors it.

This matters for three reasons:

  • It survives. Social posts scroll away in hours; email gets deleted. Six months from now, "when did search ship, and what exactly did it include?" needs an answer with a date on it.
  • It's linkable. Support can paste one URL into every "is there a way to…?" ticket. Sales can send it to the prospect who asked for exactly this in March.
  • It keeps channels honest. When each channel gets its own hand-written version, they drift — the email promises something the docs walk back. One source, many excerpts.

Sequence it changelog-first: publish the entry, then fan out. The fan-out order that works for most products: changelog → in-app widget (automatic if the widget reads your changelog) → community chat → social → email last. Email last is deliberate — it's the most intrusive channel and the one where a wrong link or a broken feature costs the most goodwill, so let the announcement soak for a few hours first. For the full every-surface list — docs, support, stores, tickets — run the release communication checklist.

Copy: lead with what they can now do

The reader's only question is "what can I do now that I couldn't yesterday, and do I care?" Answer it in the first line. Everything else is supporting material.

Bad (leads with the company's feelings):

We're thrilled to announce the launch of our brand-new, completely
reimagined Search experience, the result of months of hard work by
our amazing team!

Good (leads with the reader):

New: search your entire changelog

Type in the box at the top of your public page to search every entry
you've ever posted — titles and bodies, filtered by tag if you want.
Works today on every project, no setup.

The reliable anatomy, in order:

  • Title: verb-first, capability-first. "New: X" or "You can now X". Feature code-names go in the body, if anywhere — the title is for what it does.
  • One sentence of why — the annoyance it removes or the job it enables. If you built it because users asked, say so; "most-requested" is the one piece of launch flair that reads as listening rather than bragging.
  • How to get to it. The exact place in the UI, the setting to flip, the plan or platform it's on. "Available to everyone today" or "rolling out this week" — never silence, because silence means support tickets from people who can't find it.
  • One visual for tier 2 and up. A screenshot or short clip of the feature doing its job beats three paragraphs describing it.
  • A link deeper — docs for the details, so the announcement can stay short.

And the banlist, same as any changelog writing: "excited/thrilled/delighted", "revamped", "supercharged", "we've been hard at work". Every sentence about your feelings is a sentence not about the reader.

Timing: announce when they can use it

The iron rule: the announcement goes out when the reader can actually use the feature. Every failure mode is a version of breaking that rule:

  • Staged rollouts. If you're at 10%, either wait for 100% to announce broadly, or say "rolling out over the next week" explicitly. Announcing "X is here!" to people who don't have X generates confusion at exactly the moment of peak attention. Schedule the announcement for when the rollout completes — this is what scheduled publishing is for.
  • App stores. Review delays and slow updaters mean your mobile users get the feature days apart. Announce when the store listing is live, and remember the store's What's New box is its own tiny announcement channel with its own constraints.
  • Feature flags. If it's flagged off for some plans or cohorts, the announcement must say who has it. "Available on all plans" vs "rolling out to Pro first" — either is fine; discovering the absence yourself is not.
  • Time of week. Ship whenever; announce when you're around to answer questions and fix the embarrassing bug the first hundred users will find. A Friday 6pm tier-1 announcement is a weekend on call.

Anti-patterns

  • Announcing before it exists. "Coming soon!" belongs on a roadmap, not in an announcement. An announcement is a record of something that is now true.
  • Re-announcing the same feature. One canonical announcement, then pointers. The team that announces search four times trains users that "new" doesn't mean new.
  • Hype with no specifics. If the copy works equally well for any feature ("a faster, more powerful experience"), it isn't an announcement — it's filler, and readers correctly skip it.
  • Hiding a breaking change inside the good news. If the new feature replaces or changes existing behavior, that's a breaking-change announcement wearing a party hat — the breakage needs its own loud, dated warning, not paragraph four.
  • Skipping the announcement because "it's obvious in the UI". Active users maybe notice. The dormant user who churned precisely because this feature was missing — the person the announcement is for — never will.

Did it work?

The announcement's job is first use, not applause. A day and a week after, look at whether people who saw it tried the feature — clicks from the announcement into the product, first-use counts, and the quality of questions arriving at support ("how do I get X to do Y" is success; "where is X" means the how-to-get-to-it line failed). If a tier-2 announcement moved nothing, the interesting question is usually the feature, not the copy.

Where Wakelog fits

Wakelog is a free hosted changelog built to be the canonical-URL half of this playbook: every entry gets a permanent link you can point every other channel at, with tags (new for features, announcement for the big ones), markdown bodies for the why/how/visual, RSS + JSON feeds for subscribers, and an embeddable what's-new widget so active users see the announcement in-app automatically. Scheduled publishing (--at) lets you write the entry at merge time and have it go live when the rollout completes, and Slack/Discord webhooks mirror each publish to your community the moment it's real.

Start your changelog free   Next: product update emails →

Related guides

Last updated 2026-07-27 · All guides