How much of your product update news should you share? Announce every update on every channel and customers will soon turn off notifications and miss even the important news. Setting principles that match channel and frequency to the weight of each update takes a lot of guesswork off your team.
Sort updates into three tiers
First, judge the weight of the news. A change that alters how every customer uses the product is major, an improvement to some features is standard, and a small fix is just logged.
The tone of announcements matters too. If you copy a changelog written by the dev team as is, it reads like code to customers. Building into your workflow a step where marketing polishes it and rewrites it around “who can now do what more easily, and when” changes how announcements land.
- Major change: use email, in-app announcement, and the blog
- Standard change: in-app announcement and the changelog page
- Minor change: log it on the changelog page only
Each channel has its own job
Email handles news that mustn’t be missed, in-app messages handle news related to the feature someone is using right now, and the blog handles stories that need context and background. Don’t copy the same text into all three places; rewrite it for the reader’s situation in each channel.
For messages shown inside the product, timing is everything. A short tip that appears the first time a new feature is used on that screen is understood without any separate email. Also remember to include a clear close button and make sure it doesn’t reappear once dismissed.
A team that announces everything ends up announcing nothing.
The Story Light editorial team
“What’s in it for me” over “what’s changing”
Announcements that open with feature names and technical terms don’t get read. Put in the headline the pain customers had before and the one-sentence change this brings.
Look at the response after an update, too. Beyond how many people opened the announcement, how actual usage of the new feature changed shows which kind of guidance worked. As these records accumulate, they become the basis for choosing channels and wording for the next announcement.
What to check before writing the announcement
Before writing an announcement, first sort out who the recipient is. Even for the same feature improvement, the story differs for a long-time customer and one who just signed up. It’s natural to center existing customers on what’s changing and new customers on how easy it is to use from the start.
It also helps to set the timing of the announcement in advance. Announcing a big change during peak working hours or on a weekend evening often means it goes unread. A flow that gives one heads-up a few days before the change takes effect, and a short reminder on the day, is usually the least burdensome.
- Which customers most need to hear this first?
- Is there an action the customer needs to take, and if not, did you say they can relax?
- Did you brief the support team in advance on what is likely to generate questions?
- Did you pick a single metric to check after the announcement?
An announcement flow built with the support team
Update announcements aren’t only marketing’s job. Support is the first team to learn what questions come in right after a change. If you briefly collect the inquiries received in the week after an announcement, it becomes clear what to explain more in the next one.
Put answers to frequently asked questions in the announcement itself, or add them as short question-and-answer notes on the changelog page. As these small additions pile up, time spent answering the same question repeatedly shrinks, and customers come to trust and read announcements.
A small team doesn’t need to put a perfect system in place from the start. Gather all the update announcements sent this quarter and organize in one table what tier each was, which channels it used, and how customers responded. That table alone shows where you announced too much and where you missed.
From that table, you can refine slowly by adjusting a line or two of criteria for next quarter. Changing criteria often confuses both the team and customers, so I recommend keeping a principle you’ve set for at least one quarter while you watch the results.
Finally, always include where to ask questions in an announcement. When customers stuck because of a change know where to ask, their anxiety drops, and the responsible team can receive scattered inquiries in one place. This single line raises the credibility of an announcement more than you’d expect.
It’s also good to hold a team retrospective a week or two after an announcement goes out. Briefly share what came across well and what caused misunderstanding, and add it to the checklist for the next announcement; the whole team’s announcement quality improves bit by bit without any separate training.
Summary
Creating a changelog page lightens the burden of small updates and lets customers look things up when they need to. Before each announcement, I recommend the habit of writing in one line what you’d like the person receiving the news to do.
Add your first comment to this post