Your users don't know the feature exists

Every product team has this scar: a feature that took a quarter to build, got a launch email, a changelog entry, maybe a webinar — and six weeks later, analytics show a sliver of users have touched it. Support still fields requests for the thing. Sales still gets asked whether it's on the roadmap. It shipped, and nobody knows.

The uncomfortable cause: launch communication happens everywhere except the place users actually are. Emails land in a different tab from your product. Changelogs are read by fans. The only channel with a guaranteed audience of active users is the product itself — and inside the product, your new feature is one more menu item that looks exactly like the old ones.

Why in-product discovery fails too

Teams that learn this lesson often over-correct: every release gets a modal, every button gets a beacon, and within a month users dismiss everything unread. Announcement fatigue is real, and it's self-inflicted. The failure isn't announcing in-product — it's announcing everything to everyone with the same intensity.

The graduated system

Match the surface to the blast radius, and target by who actually has the problem the feature solves:

• Ambient, for the likely audience. A hotspot on the new button, shown only to a segment whose behavior predicts caring — users who exported ten reports see the beacon on "Scheduled exports". Everyone else sees nothing.
• Contextual, at the moment of relevance. Trigger a tooltip on the event that proves the need: the user who just did the manual version of the thing your feature automates. Discovery lands exactly when it's useful, which is why it converts.
• A modal only when it changes how everyone works. The full-stop announcement is a currency — spend it a few times a year and users keep reading them. Everything else rides a banner or the changelog.

The targeting is the whole trick, and it runs on data you already have: user traits and behavior your app sends anyway. "Announce to everyone" is what you do when you can't segment; once you can, relevance replaces reach.

Tier your releases before you announce anything

The discipline that makes the graduated system work is deciding, per release, how loud it deserves to be — before anyone opens the announcement tool. A workable tier list: Tier 1 (changes how everyone works — new pricing, redesigned navigation) earns a modal for all affected users. Tier 2 (a real feature with a natural audience) gets a targeted hotspot or tooltip for the segment that plausibly cares, and nothing for anyone else. Tier 3 (improvements, fixes, small conveniences) rides the changelog and is discoverable by tooltip only in context. Most releases are Tier 3; the system stays credible precisely because they're treated that way.

Write the tier into the release checklist next to the changelog entry. When "how loud?" is a standing question with named tiers, the loudness inflation that kills in-product announcements never gets started — and your Tier 1 modal, when it finally fires, still commands attention.

Measure adoption, not impressions

An announcement with ten thousand views and flat feature usage is a failure with good reach. Track the chain: who saw the announcement, who clicked through, and — in your own analytics — who used the feature in the following weeks. When clicks are high and usage is flat, the feature has the problem, not the messaging; that's worth knowing before you write a louder announcement.

And close the loop on the silent cohort: if a feature's natural audience keeps not adopting it, ask a handful of them why with a one-question survey. The answer is regularly humbling — wrong name, wrong menu, wrong mental model — and always cheaper to learn in week two than in the quarterly review.

Users don't owe your changelog a read. The product is the only announcement channel with guaranteed delivery — spend its attention like money.