How do I tell users about a new feature?
19 September 2026 · by Nordva, who make Nordva Launch
The short answer
Tell users where they already are: inside the app, by email to the people who asked to hear, and on a public changelog you can link to. Lead with what they can now do, not what you built, and tell the people who asked for it first, personally. One announcement in the right places beats five posts where your users don't look.
Where users will see it
- Inside the app. The one place every active user goes. A small notice or a “what’s new” badge reaches people while they’re using the product, which is when a new feature is useful to them.
- Email, to people who asked. Users who subscribed to updates want to hear. Everyone else gets it in the next note you’d send anyway, not a special blast.
- A public changelog. A page with every change and its date. You link to it from posts, from support replies (“this shipped last week”) and from your pricing page. It also shows visitors the product is alive.
- Social posts. They reach followers and future users more than current ones. Useful, but not the main channel for people already using the app.
What to write
Start with what the user can do now, in their words: “You can now send your report to Slack every Monday.” Then one line on how to use it, and a link. Leave out how hard it was to build.
A screenshot or a short clip helps more than a paragraph. Keep the title short enough to read in a notification.
Tell the people who asked first
If people asked for this feature, write to each of them before the public announcement: “You asked for this; it’s live.” It takes minutes, it’s the announcement most likely to be read, and people who see their request built tend to stay and ask for the next thing.
That only works if you kept track of who asked. Requests scattered across email, chat and social replies are hard to find again; one inbox with the person on each message makes it a two-minute job.
Don’t over-announce
Group small fixes into one note. Announce one thing at a time when it changes what people can do. An in-app notice every day becomes background.
Measure it
Put a tag on the links in your announcement (?utm_source=changelog&utm_campaign=slack-reports) and count how many people used the new feature in the week after. A feature nobody finds is the same as a feature you didn’t build.
With Nordva Launch
The changelog gives you a public page, RSS, Atom and JSON feeds, and a widget for your site (25 entries on Free, unlimited on Indie). On Indie, people can subscribe by email and each entry can notify them (500 subscribers on Indie, 5,000 on Builder). An entry can also post itself to your app’s in-app notifications when it publishes, on every plan. Link feedback to a changelog entry, and when you publish it, Launch emails each person who asked, once, if they left an email. You can also publish an entry from Claude Code or Cursor through Launch’s MCP server.
When Launch is the wrong tool
If you ship dozens of small changes a week, announcing each one trains people to ignore you; group them into a weekly or monthly note instead.
- How do I announce product updates to users?
- Should I have a changelog for my app?
- How do I let users know about new features?