Brian Bailey

March 28, 2024

Anatomy of an Announcement

Announcements tell the ongoing story of a product. They frame new features, suggest different ways of using the product, and pull in curious people who haven't signed up yet.

They're also easy to tune out. Here are a few ways to make them worth reading.

1. Tell a friend
Starting here makes everything easier. Imagine you're at a coffee shop with a friend and want to show them this new thing that was just released. You'd be human, friendly, casual, and brief.

With a friend, you don't use jargon or assume they are intimately aware of your product. You tell them why it's interesting to you, but also why it's interesting to them.

2. Paint a picture 
What can you do now that you couldn't do before?

Kathy Sierra wrote in Badass: Making Users Awesome:

People don’t want to be badass at using our tool.
They want to be badass at what our tool helps them do.

Explain how it can be used in the real world. Some people have wanted this feature for a long time, but most haven't thought about it once. The goal isn't just that they understand the feature, it's that they understand what the feature makes possible.

3. Connect the dots
Since the work is the feature, you become completely focused on it instead of how it fits within the larger product. But the product is a dynamic system where everything is related.

Don't silo your features. Explain how this change fits within a wider workflow or is tied to a previous one.

4. Show and tell
Whenever you can, include text, screenshots, and a video. Some people will never read more than the bullet points. Others will never click play on a video. Let people learn how they want to learn.

5. Stay out of the deep end
There's overlap between an announcement and a support article, but they're fundamentally different. You don't need to cover every corner of the feature in your announcements or walk people through each step and edge case. If there are a lot of those, you can always link to the article.

The announcement should absolutely explain how to get started, though. I've finished reading more than a few announcements and thought, "Great! Now, where do I actually find this?"

6. Look for chances to be novel
If you ship often, you'll write a lot of announcements. You settle into a rhythm and patterns emerge. Nothing wrong with that! It makes it easier to be timely and knowing what to expect makes for quick reads.

Look for ways to bring originality now and then, though. It could be as small as an unusual word choice or a whole different approach for a unique feature. Maybe it's a little humor or a clever reference in a screenshot. People appreciate the extra effort and touches.

7. Be honest
One way to not be formulaic is to not over-celebrate every single feature. You can only be thrilled to announce something so many times.

If the team is genuinely excited about a release, by all means, capture that. Same with the pride of a particularly ambitious project or a simple solution that required many iterations before it was found.

Sometimes, though, an update is just an update, adding a nice polish or fixing a frustrating bug. There's no need to oversell it.

Also be transparent when you're a bit embarrassed about how something used to work or how long you lived with it. Everyone can relate to that.

This post Jason wrote years ago about introducing a Basecamp feature stuck with me.

We were all hacking it. As of today, the silliness is over. No hacks required!

When everyone knows you're finally fixing a long-standing frustration, pretending otherwise rings hollow.

8. Know your audience
You know the product really well. Everyone you work with does, too, along with many of the customers you hear from. But the announcement shouldn't be written from that perspective.

Experienced people aren't the only ones reading. Don't assume extensive prior knowledge, especially if you have a lot of unique terminology. Think of the person who signed up a week ago or has never used this part of the product. If you post announcements publicly, consider people who come across then who aren't customers.

9. Match the house style
Whether it's formalized or not, your organization has a unique voice and tone. You'll want the writing to be familiar and consistent across contexts.

These are some basic things we keep in mind:
  • Direct and confident
  • Clear and concise
  • Conversational, yet professional
  • Second person perspective
  • Active voice

10. Timing isn't everything
Not everything has to be announced immediately. We usually announce things within a day or two, but it's not a hard rule. We avoid delaying shipping so an announcement and support article are ready. A fast follow is usually enough.

It's fine to let people discover features on their own. Surely everything they need is there to get value out of it without an announcement. If not, how is someone new to the product 3 months from now going to be successful?

Of course, if it's a substantial change, especially one that impacts a core part of the experience, you'll want to be ready. Same thing if it's likely to prompt a lot of questions — the support team will thank you!

The announcements I'm referring to here are for blogs and social media. For in-app news and emails, we usually wait and bundle a few together in a single message. Better to interrupt people less often and make it worth their time with a fun collection of improvements. It's likely that at least one item will be of interest, so they'll be inclined to read the next announcement, too.

11. One more
The best advice Jason has shared with me about announcements is: 

Don't tell people how to feel or what they need. Explain what it is, what it's for, how it can be used, and they'll know if they need or want it.

Finally, an under-appreciated part of writing an announcement is the feedback loop about the feature itself. When you have to explain it to someone else or capture it in screenshots, you look at it from a different angle. Time after time, you notice things that aren't right or realize that the flow could be simpler.

Sometimes, it's more than that. Maybe it's a struggle to come up with ways someone would use this or explain the why behind it. Other times you realize the announcement is going on and on because there's so much surface area, maybe too much. In rare cases, those are reasons to reconsider shipping it as-is, but in all cases, use those lessons to inform the next project.

Included in our Seven Shipping Principles is this:

Not every batch of work is going to be a 10/10. But if it’s less than 8/10, it probably shouldn’t go out the door. If it’s less than a 7/10, there’s no way it should go out the door, except as an emergency patch you immediately return to cleanup.

Announcing is part of shipping great work, and that work deserves a great announcement.

About Brian Bailey

Head of Product Strategy at 37signals, the friendly people behind Basecamp, HEY, and ONCE. Find me elsewhere at bb.place and @bb.