How to Announce a New Feature: A 4-Tier Playbook for SaaS Teams

You shipped the feature three weeks ago. Adoption is sitting at 12%, and you’re staring at the dashboard wondering why your users aren’t using it.

Two things might be true. The first is uncomfortable: maybe the feature isn’t useful. You built it because someone asked for it, or because it was on the roadmap, or because it seemed obvious at the time. But the people you built it for aren’t reaching for it.

The other possibility, the one most teams jump to first, is that users don’t know the feature exists. They never saw the modal, the email landed in promotions, the changelog post got six page views. This is the announcement problem.

The trick is separating the two. If your users can’t tell you what the feature does when you ask them in a support call, you have an announcement problem. If they know about it, tried it once, and didn’t come back, or never tried it at all because they didn’t find it relevant, you have a feature problem. The feature problem is real, but it’s not what this post is about. This one’s about announcements.

The playbook I like to use: tier every announcement by how much the change matters to the user, then match the channels to the tier. Over-announce small things and users tune you out. Under-announce real launches and users miss them. The four tiers below give you a way to decide which is which before you write a single word.

Feature announcement vs everything else it gets confused with

Before getting into the playbook, a quick definitional pass. “Feature announcement” gets used as a catch-all for a half-dozen related but distinct things. They’re not interchangeable, and conflating them is one reason teams tend to over-communicate.

Changelog

A changelog is the running list of everything that changed in the product. New features, bug fixes, performance improvements, UI tweaks. It’s documentation, not marketing. Power users check it. Most users never look at it. It serves a specific purpose: a permanent record of what shipped, accessible to anyone who wants the full picture.

Release notes

Release notes are the changelog entries that ship with a specific version. The format is similar to changelog entries, but the framing is “what’s new in version 4.2” rather than “what’s new since you last looked.” Some teams maintain both. Most teams have one.

Product update email

A product update email is the broadcast that goes out when something user-facing changes. Sometimes it’s a single feature, sometimes a batch of changes. The audience is broad (often the full user base), the depth is shallow, and the goal is awareness more than adoption.

In-product notification

An in-product notification is a UI element that surfaces inside the product itself when a user is using it. Modals, banners, tooltips, dot notifications, “What’s New” feeds. These are the highest-intent channel because the user is already in your product when they see them.

A feature announcement is a coordinated use of some or all of these to introduce a single new capability. The coordination is the point. A modal alone is a UI element. An email alone is a broadcast. A feature announcement is the decision about which combination is worth the user’s attention for a particular feature.

The 4-tier playbook for feature announcements

A pattern I’ve seen often: every shipped change gets treated like a launch. The modal goes up, the email goes out, the LinkedIn post happens. Three weeks later you do it again. Six weeks in, users have stopped reading any of it.

The way I tend to approach this is to sort each announcement into one of four tiers, based on how much the change actually matters to the user, then match the channels to the tier. What follows is the version I default to. It’s a starting point, not a rulebook, the boundaries between tiers shift with your product, your audience, and how often you ship. But having some tiering at all tends to beat treating every announcement as equally important.

Tier 1: Major launches and changed workflows

I’d treat a change as Tier 1 when it materially affects how your users get work done. A new product inside your platform. A redesigned core flow. A new pricing tier. A feature that opens up a use case the product couldn’t do before.

The test I lean on: whether existing users will need to relearn or rethink something. If yes, I usually call it Tier 1. OpenAI’s GPT-4o launch fits Tier 1 by this test, it changed what users could do with the same product. Slack’s Huddles launch fits Tier 1, it introduced an entirely new mode of communication inside Slack.

For Tier 1 I’d usually reach for the full stack: in-app modal for active users, email for the broader base, public changelog entry, blog post explaining the why, social posts for amplification. Each channel reaches a different segment of your audience, and for a launch of that size it tends to be worth the investment across all of them. Use whatever channels you actually have. If you’re not on social, that’s fine, just hit everything else you run.

Tier 2: Meaningful new features

Tier 2, in my head, is for a real new capability that doesn’t change the fundamentals of how the product works. The user can do something they couldn’t do before, but their existing workflows don’t break. Notion’s new database views fit Tier 2 for me. Linear’s project updates, same. A new export format, a new integration, a new keyboard shortcut hub. I’d usually land these here.

I’d also put same-functionality redesigns in Tier 2 if the workflow visibly changes. A reskinned settings page where every button moves but every function stays is Tier 2 in my view, because users have to relearn the page. A reskinned button that does the same thing in the same place probably isn’t.

For Tier 2 my default is an in-app announcement, an email, and a changelog entry. If you’re shipping at a high cadence, multiple Tier 1 or Tier 2 features a month, one move worth considering is bundling several into a single email instead of sending one per launch. Lower email volume, more weight behind each send, and the emails that do go out feel like events rather than noise.

Tier 3: Improvements and cosmetic redesigns

Tier 3, for me, is a change that’s better than what was there before but doesn’t introduce new capability. The export is now three times faster. The search is more accurate. The page is now responsive on mobile. A cosmetic redesign that doesn’t change the workflow.

For Tier 3 I usually just write a changelog entry and stop there. No modal, no email. If users notice the change, the changelog is there for them to look up the context. If they don’t notice, the change is doing its job invisibly. There are exceptions: a performance win that’s been a frequent support topic might justify a one-off note to power users. But the default I lean toward is to ship quietly.

The temptation with Tier 3 is to oversell. “We’ve completely reimagined export!” is Tier 3 dressed up as Tier 1, and in my experience it’s one of the fastest ways to teach users to stop trusting your announcements.

Tier 4: Bug fixes and polish

Tier 4, for me, is a bug fix or minor polish. I wouldn’t usually give these user-facing announcements at all. They may appear in a developer-facing changelog or release notes for compliance or transparency reasons, and there are products, regulated industries, security tools, infrastructure, where surfacing fixes is part of the value. But for most SaaS, the user base doesn’t need to hear about them.

The channel mix for each tier

The table below is the starting point I’d reach for. Treat the cells as defaults, not commitments. Your audience, your sending cadence, and the kind of product you run will pull individual cells in either direction.

Tier	In-app	Email	Changelog	Blog post	Social
1: Major launch	Yes	Yes	Yes	Yes	Yes
2: Meaningful feature	Yes	Yes	Yes	No	No
3: Improvement	No	No	Yes	No	No
4: Bug fix or polish	No	No	No	No	No

A heuristic I lean on for borderline cases: if I’m not sure whether a change is Tier 2 or Tier 3, I default to Tier 3. The cost of under-announcing a Tier 2 is one missed feature adoption. The cost of over-announcing a Tier 3 is a slow erosion of attention that’s hard to claw back.

In-app announcements: choosing the right UI pattern

For Tier 1 and Tier 2 launches, the in-app announcement is the highest-leverage channel, because the user is already in your product when they see it. The decision then is which UI pattern to use, and most teams default to a modal because that’s what feels like an “announcement.” Modals are right sometimes. They’re also the pattern that causes the most damage when misused.

A modal is the right pattern when you need to make sure the user sees the change before they do their next thing. It interrupts the workflow. That’s its point, and that’s why it should be used sparingly.

Use a modal when the change affects what the user is about to do. An example would be a new export format on the day a user opens an export dialog. The modal is justified because the user actually needs the information.

I wouldn’t use a modal for a feature the user doesn’t have access to (sounds obvious but mentioning it because this needs consideration when designing your modals). I wouldn’t use a modal for an improvement they’ll discover naturally. I wouldn’t use a modal for the third Tier 2 launch this month.

A banner sits at the top or bottom of the screen. It’s persistent until dismissed. The use cases are different from modals and tooltips: scheduled maintenance, time-bound promotions, plan-related notices, urgent service updates.

Banners work poorly for new features because they don’t tie to a workflow moment. A user sees the banner, ignores it, sees it again on the next page, ignores it again, and dismisses it. The banner gets a single chance to be relevant, and that chance is the moment of first display.

Newsfeed (or “What’s New”): the running in-product record

A newsfeed widget is an in-product version of the changelog. The user opens it when they want to know what’s new. The icon usually has a badge for unread items.

Underrated in my experience: a newsfeed captures users who proactively want to know what’s changed without imposing on users who don’t. A team that maintains a clean in-product newsfeed has a permanent source of feature discovery that doesn’t burn modal attention.

The trade-off is that newsfeeds only reach users who open them, but it can be an alternative to maintaining a changelog outside of your product.

Hotspot: low-effort discovery for non-critical features

A hotspot is a small visual indicator, usually a pulsing dot, placed on a UI element that hints at something new without interrupting. The user notices and explores, or doesn’t. Typically the dot expands into a tooltip when hovered or clicked, giving the explanation in context. The user who didn’t need the prompt isn’t interrupted.

Hotspots work well for Tier 2 features that live at a specific UI location: a new button, a new menu item, a new field. The feature stays discoverable for users who want it, invisible for users who don’t.

Hotspots are the gentlest pattern, which also makes them the easiest to leave in place too long. A hotspot that’s been pulsing for six months on a feature most users already know about is just visual noise.

One configuration that makes hotspots much less annoying: hide them permanently on a per-user basis once the user has engaged. If they’ve hovered or clicked, the dot has done its job.

Email announcements that get opened and clicked

Email’s strength, in my view, is that it reaches users who aren’t in the product right now, exactly the segment in-app announcements can’t touch. The trade-off is depth: SaaS feature announcement emails average around 2% click-through rate, according to AnnounceKit’s industry data. With open rates around 20-25%, most recipients see the subject line and move on without opening. That shapes how I think about writing one: it has to do its job in the first three seconds.

The subject line

My rough rule of thumb: name the feature and the benefit, in under eight words. Slack’s subject line for their Huddles launch was “Say hello to Huddles,” and the body did the rest. Some patterns that tend to land for me:

“New: Export reports in one click”
“Now you can [outcome the user wants]”
“Introducing [feature name]: [benefit in three words]”

And some I’d avoid:

“Exciting updates to your dashboard”
“Big news from the product team”
“Q2 product update digest”

The weak subject lines are about you, the team. The stronger ones are about the user.

The body

My default for the body is to fit it on one screen on a phone, under 200 words. A structure I keep coming back to:

One sentence on what’s new (the same content as the subject line, expanded slightly).
One sentence on why it matters (the benefit, with one specific use case).
A visual: GIF or screenshot showing the feature in action. Animated if the feature is interactive, still if it’s static.
A single call to action. “Try it now” linking directly to the feature.

Things I’d cut: the welcome paragraph, the “we’ve been hard at work,” the multi-link footer of three other things the team wants to push. The email exists to drive one action, and everything that isn’t pushing toward that action is friction.

Who to email

I’d usually push back on emailing everyone by default. The segments I tend to exclude:

Users who have already used the feature, they don’t need the email. (if you can’t segment these out, not a big deal, these are highly engaged users, they likely won’t be too annoyed by the email)
Users on plans that don’t include the feature. You’re advertising something they can’t have.
Users who have unsubscribed from product updates specifically.

The supporting channels

For Tier 1 launches, the in-app and email work is usually the bulk of the lift. The supporting channels (changelog, social, blog) round out the announcement and reach segments the first two can’t. How much weight to put on each is one of the more product-dependent decisions in this whole framework.

Public changelog: the channel I’d argue is most underrated

A public changelog (e.g. changelog.yourdomain.com) is, in my view, high-ROI and easy to neglect. Power users check it. Prospects evaluating your product check it. SEO benefits from the cumulative weight of entries. And it costs almost nothing to maintain if you write entries as part of the release workflow.

My default is to put an entry there for every Tier 1, 2, and 3 change. The format I tend to use: feature name, one paragraph of what changed, one line on who it’s for, link to docs. Linear’s changelog is a model I keep coming back to. They treat it as a marketing surface, and that’s part of why their product feels velocity-rich to outsiders.

My take: social posts are amplification rather than announcement. The users who see your LinkedIn or X posts are mostly prospects, partners, and people in adjacent communities.

I’d reserve social for Tier 1 launches and Tier 2 launches with visual punch. A 20-second screen recording of a new feature in action let’s prospects learn more about your product.

Blog post: when the feature has a story

I’d justify a blog post for a Tier 1 launch where the feature has context that doesn’t fit in a changelog entry. The story behind why you built it. The customer problem that drove it. The technical decisions worth surfacing.

PostHog’s blog announcements are a model I find useful. Their Data Management launch is a good example: it explains the feature, but also lays out the why and the concrete pain points it solves. The post becomes a permanent reference, indexable by search, shareable in support conversations, citable internally.

For Tier 2 launches I’d usually skip the blog post unless there’s something to say beyond what fits in the changelog entry. A blog post that exists because “we need a blog post for the launch” tends to read like one.

What kills feature adoption (anti-patterns to avoid)

The principles above describe how I think about getting announcements right. The patterns below are the failure modes I’ve watched happen most often, usually when announcements get treated as a checklist instead of a decision.

Announcing things that aren’t features

A pattern I’ve seen often: a team finishes a sprint, decides every shipped item deserves an announcement, and pushes a modal for a button label change. Users learn that the modals are noise and start dismissing reflexively.

My rough heuristic is that the threshold for a modal should be higher than the threshold for a Slack message to your team.

Untargeted blasts that ignore relevance

Every user gets every announcement. The marketing manager doesn’t care about your new developer API. The free-plan user doesn’t care about the enterprise SSO feature. The user who already used the feature last week doesn’t need an email telling them it exists.

A check I run on every announcement: does it have an exclusion list? If the exclusion list is empty, I’d treat that as a signal something is wrong with the targeting.

Notification fatigue and the unsubscribe spiral

If you announce too much, users unsubscribe from emails, mute push notifications, and dismiss in-app modals on reflex. Once they’ve been trained to ignore your announcements, recovering that attention is harder than not losing it in the first place.

This is what the tiered approach is trying to solve. Tier 3 announcements don’t go to email. Tier 4 don’t go anywhere user-facing. Email becomes a signal again because it only shows up for things that matter.

A user dismisses your modal on Monday. They log in Tuesday and the same modal appears. They dismiss it again. By Friday, your modal is in the same mental category as a cookie banner: an obstacle to clear before the actual work starts.

This is usually a configuration problem. My preference is to configure dismissal at the user-account level, not the session level. A dismissed modal stays dismissed, unless there’s a specific reason to re-show.

“Got it” buttons with no follow-through

A modal pops up, explains the new feature, and offers a single button: “Got it.” The user clicks. Nothing happens. They’ve closed the loop without ever trying the feature.

The way I think about CTAs: a modal CTA should drive the next action. “Try it now” that opens the new feature. “See how it works” that opens a short walkthrough. “Read the docs” that opens the documentation. “Got it”, in my view, is a dismissal disguised as engagement.

Announcing features users can’t access

A free-plan user sees a modal for a feature that’s gated to Pro. They click through. They land on a paywall. They close the modal, mildly frustrated, and trust the next modal a little less.

If a feature is gated, I’d either skip announcing it to users who can’t access it (my usual default) or be explicit about the gate in the announcement itself. The frustrating middle path, where the announcement looks like a feature and ends as an upsell, is the worst of both options in my experience.

How to measure whether the announcement worked

A feature announcement isn’t done when it ships, at least not in my view. The work of measuring whether it worked is the work of learning how to do the next one better.

The four-stage funnel

The framework I’ve found useful comes from AnnounceKit’s product analytics guidance:

Exposed. The user saw the announcement (modal viewed, email opened, banner shown).
Activated. The user engaged with the announcement (clicked through, expanded the modal, replied).
Used. The user tried the feature at least once.
Retained. The user used the feature again in a subsequent session.

Each stage is a percentage of the previous one. A typical funnel for a well-targeted Tier 2 launch might look like 100% exposed, 12% activated, 8% used, 5% retained 30 days out. I’d treat that as illustrative, not a target.

What each drop-off tends to mean

Announcements are mostly one-shot events. You can’t rewrite the subject line on an email that already sent. So the value of looking at drop-offs isn’t really to fix the current launch, it’s to learn for the next one, or to spot the same shape repeating across announcements over time. (In-app announcements are the exception, where a misconfigured trigger or broken CTA can sometimes be fixed mid-flight.)

With that framing, here’s how I tend to read each pattern:

High exposure, low activation. People showed interest by opening the email or sticking with the modal, so the hook worked. They just didn’t take the next step. Usually this points to one of two things: the body didn’t deliver on what the headline promised (an expectation mismatch where users feel mildly baited and bounce), or the body did match but didn’t make a compelling enough case for action. The lesson for next time is in the body copy and visual, not the headline. The headline already did its job.

High activation, low usage. Users clicked through, so they wanted to try the feature. They just didn’t get there. Two common causes: the CTA sent them somewhere other than the feature itself (e.g. to the homepage or a generic dashboard), or the link was right but the destination screen was confusing enough that they gave up before figuring it out. The lesson for next time is use a CTA that lands the user one click away from actually using the feature, and the destination should make the next step obvious.

High usage, low retention. Users tried the feature once and didn’t come back. Before reading too much into this, check the expected frequency. Not every feature is a daily feature. An export might be monthly, a settings change is one-and-done, a tax tool gets pulled out once a year. If the feature is genuinely supposed to be recurring and users aren’t returning, that’s the announcement working and the feature failing. The announcement isn’t your problem here, the feature is.

Benchmarks worth knowing

AnnounceKit’s data gives a reasonable directional reference:

In-app modal CTR for well-targeted announcements: 5-15%.
Email open rate for feature announcements: 20-25%.
Email click-through rate: around 2% SaaS average.
Notification center badge clicks: 2-8%.

I’d treat these as starting reference points, not targets. Your numbers will vary by audience, feature type, and product complexity. The more useful exercise, in my view, is tracking your own baseline and improving against that, rather than chasing an industry average.

FAQ

What’s the difference between a feature announcement and release notes?

A feature announcement is targeted communication about a specific new capability, written for end users with a focus on benefit and adoption. Release notes are documentation-style: a record of everything that changed in a given release, for users who want the complete picture. Some teams publish both, a polished announcement for major launches alongside a comprehensive changelog or release notes for the running record.

Should I announce every feature?

No. A possible approach is to tier announcements by how much the change matters to the user. Major launches and meaningful new features get user-facing announcements. Improvements and cosmetic redesigns get a changelog entry. Bug fixes and minor polish don’t get a user-facing announcement at all. Announcing every shipped change trains users to ignore announcements, which makes the ones that actually matter less effective.

What’s a good adoption rate for a new feature?

Adoption rates vary widely by feature type and audience segment. A simple UI change targeted at active users typically sees 40-60% adoption within 30 days. A complex new workflow targeted at the broader user base typically sees 5-15%. The more reliable benchmark is your own baseline over time, rather than an industry average that doesn’t account for your specific product or audience.

A modal interrupts the workflow and forces awareness. Use it when the change affects what the user is about to do, or when they need to know about it before continuing. A hotspot points at a specific UI element without interrupting anything, and works when the new thing has a clear location in the UI. As a general rule, default to the lighter pattern. Modals carry a higher cost in attention and should be reserved for cases that justify the interruption.

How do I avoid annoying users with announcements?

Three things tend to make the biggest difference. First, tier your announcements so only meaningful changes get user-facing communication. Second, segment your audience so each announcement only reaches users for whom it’s relevant. Third, configure dismissal at the user-account level so a dismissed announcement stays dismissed. Announcements that show up rarely, target precisely, and respect a “no” tend to get read.