How to Use Release Notes to Drive Feature Adoption: Best Practices and Examples

Companies are understandably excited to tell the world when they push new features. New developments can take months of work and gallons of coffee—and teams dream for more users, greater engagement, and achieving milestones towards success. 

So how do you communicate these feature announcements to users? A blog post, an email, and then... tumbleweed? You sit back and wait for impact, but end up disappointed if the anticipated uptick in usage doesn't arrive.

Standard feature announcements are missing the mark—but they don't have to. We're going to walk you through how to create and distribute release notes that help drive new feature adoption amongst your users and get some buzz going.

Remember way back in the old days when you'd download software on your desktop PC or need to have to put a CD in? You'd have a file with all the instructions and notes, sometimes coming in the form of a booklet. Release notes are the 21st-century equivalent of this.

When a new update of the software is launched, release notes detail what features have been added, what issues have been fixed, and what has been specifically improved by the company. Essentially, release notes inform the user of the current state of the product in relation to the past version.

One thing to keep in mind about release notes is that while it provides information about the new product or an update, it is not a substitute for a user guide. Thus, always make sure to have in-depth user guidance alongside your release note.

Release notes are an opportunity for you to "top up" your users' knowledge. For companies with a product-led growth strategy this is important because the more your users are empowered with product knowledge, the more successful they will become. In this way, great release notes complement self-service learning driven by your product.

By using release notes, you can easily inform your customers about updates they've been waiting for, new features they've been requesting, or bug fixes. They help keep your customers excited and informed about your product—as well as reduce the pressure on your support and customer success teams.

Release notes typically include any feature enhancements, bug fixes, new product or feature releases, UX changes, UI redesigns, and more. 

The information you include needs to be concise and informative. In general, when there is a new release for a software product, users want to know the following:

1. What changes have been made to the product—and why

2. What impact this will have on them

3. If they need to do anything differently

Apart from these three key pieces of information, there aren't any real rules to follow—but there are a few best practices to make sure that you're writing great release notes that are actually helpful to the user.

How do you make release notes that people will engage with? Here’s what you can do to increase your chances of feature and product adoption.

Release notes are often written by developers and product managers since this is product documentation. However, this can run the risk of making it too heavy with technical jargon and vocabulary that is unfamiliar to users.

Instead, use plain language to explain complex changes in a simple manner and showcase why the change is important for users. Keep in mind that your release notes should be instantly understandable to your users. 

For instance, if you had bug fixes in the new version of your software, don't go into the weeds of what was fixed and how it was done. Simply let people know that the bug has been addressed, and reassure them that they won't be running into it again. Just like how Slack did it below.

(Source)

Release notes can be boring. Aside from the fact that not every single release note is about a huge exciting feature, they can also be a tough read to get through. This is where showing a bit of personality can go a long way. By expressing your brand, you can engage your users effectively through your release notes and improve feature adoption.

This can manifest in many different ways, but the most important thing is to maintain your brand's tone. If you're usually quite playful in your copy, roll with that. Similarly, if your tone is more formal, don't crack jokes in the release notes.

If you're unsure of how to achieve this, get help from a copywriter. They'll gladly help you find the right tone and write in your brand voice.

For example, Medium is known for having fun with its release notes, and it works because they still provide value to the reader. Expect haikus, stories, and puns—all while you learn about their updates.

(Source)

They say a picture is worth a thousand words. The same goes for release notes. No matter how accurately you describe the changes, it could never beat a picture that shows what was changed about your web app or your software.

This especially helps if you have made significant UI/UX improvements. There is really no better way to show such changes than to simply use visuals, whether it's a simple screen capture or a more elaborate GIF of the user flow.

As an example, see how Mural introduces a new feature. Without reading further, you can tell what they're trying to introduce by referencing the image.

(Source)

Release notes should be informative, but they should also be a brief overview of the update. Nobody wants to read an entire saga to find out what are the latest features.

An extreme case of what not to do is Tumblr's infamous release note in 2015 when they released an update about version 4.3.1.

It seems that the release note was written by an MFA graduate with far too much obsession with David Karp. Just take a look at how it begins:

'4.3?’ roared David Karp across the boardroom table. He spun on his heels, turning his back to the board. His shoulder muscles rippled through his gingham shirt.

Overall, the rambling story went along until this fictional depiction of Karp decided that they would call the update 4.3.1.

(Source)

But despite all the spirit of a novelist within the release note, it failed to do the one thing it was supposed to do. It did not say a single word about what version 4.3.1 was actually about.

At least it was funny and was shared on Reddit like wildfire.

Like any other text-based communication material, release notes also should have great readability. No one wants to read a big wall of text. This means keeping things well organized on the page.

Use subheads to divide up different sections. Employ bullet points to keep things concise and easy to read. Cut up big chunks of text with paragraph breaks. All of this makes for a much better reading experience.

Check out this GitLab release note for example. The introduction is short and to the point. Then it divides up different sections into hyperlinked bullet points for easy viewing.

(Source)

In addition to on-page organization, you should also arrange your release notes by specific categories such as release dates so that should users want to revisit older release notes or catch up on the latest releases all at once, they can do so with ease.

As an example, take a look at what Shopify does below. It clearly outlines and tracks release notes as well as categorizes them with tags, making it easier for users to see the history of changes being made.

(Source)

A release note is supposed to clearly communicate what has been changed about the software in its newest version. This is why you need to be specific and direct about what updates you have made and what issues have been addressed.

However, too many times, release notes are strewn with vague language that gives a little indication of what users can look forward to.

For instance, instead of saying "we fixed a bug"—expand on this, like "we fixed a bug that was causing X feature to lag when Y happened". That tells users what to expect for the update, and it allows users who were experiencing particular issues to know that it was fixed.

So be clear and exact. Your users should know what to expect when they use the new version of your product.

At the end of the day, you write release notes for your customers. So keep that in mind and talk directly to them. Make it super easy for them to understand and think of what they want to gain from reading your release notes.

One of the ways to do this is to simply write in a language that is less indecipherable than you normally would. As we mentioned earlier, release notes can be quite packed with tech jargon. Ditch all of that. Instead of saying "The site now supports multi-language input" (talking to no one), switch up your update and say "You can now write in different languages".

The user should be the one you're always talking to—it's them who you want to use the new features after all.

Now that we have release notes covered let's take a look at how release notes can be distributed. Usually, release notes reside in a specific place reserved for them, such as changelog pages. 

But there are more than one ways to let users learn about the details of your software's latest version. Let's take a look at different ways of delivering release notes to customers.

Release notes serve as the "trigger" for the change. However, if not distributed the right way, some issues may arise:

1. Users might miss them or forget about them  if they are delivered through a noisy channel

2. Announcements that focus on how to use the feature, but are delivered in a channel out-of-context might not be as effective as they should

3. Announcements that don’t improve a user's ability (they don't make the new feature “easy to do”) might not actually help a user adopt the new behavior

💡 Want to learn more about triggers and user motivation? Read about how they can help you grow your product

This is why it matters to deliver your release notes in the right channel, at the right time, and in the right format. Let's take a look at several ways of distributing release notes, with pros and cons for each.

Blog posts are one of the most standard formats of release notes that companies use. Either they will be posted on the company's main blog, or there will be a specific release-focused blog like a changelog.

Blog posts get the job done. They are versatile, and they can accommodate updates of any length. The problem is that while they can help users understand the details of the new version and let them know about the latest features, they don't help them adopt any new behavior. What's more, when a user is going through their inbox or reading a blog, they are away from the context of the app.

Even if they see information about a new feature, it is difficult for them to internalize the new actions just through reading. When someone’s reading a blog, even if the blog is within your website, they're not actually in the product itself. Users are in the wrong place and have the wrong frame of mind, which gives blogs less ability to make any behavioral changes.

Email is another common way to deliver feature announcements and release notes to users. Let's take a look at this email from Mailchimp announcing improvements to their A/B testing tool:

This email does tell you all you need to know about the new features. These type of update emails are great for maximum reach as you can send the update to the thousands of users on your email list. If any currently aren’t finding good use for your product, this might be enough to bring them back.

But this doesn’t help the user actually use the product. The call-to-action at the end of the email is to read more, even though they have just read a very long email about the product.

Reading doesn’t help the customer internalize the idea of the new feature. Though they might be giving use cases for the new features, the only way people can really learn is by using the product.

Mailchimp missed the opportunity here to direct the user into the product and to a tour of the new features.

Social media may sound pretty unusual. After all, social media posts are limited in terms of how much you can communicate through them.

However, social media posts can be a great way to highlight key new features. You can also generate hype for upcoming latest product updates and tease the release date.

ClickUp has a nice example of this. Among all the updates from their new release, they focused on the Whiteboards, displaying the feature with an engaging short video.

(Source)

The best place to educate the user in regards to a new feature is right inside your product because your users can get to act on the knowledge from the release notes right away.

But you need to be careful with on-page announcements, as they can often be delivered at the wrong time to the wrong user. Also, avoid giving the user more to read, instead of guiding them directly through actions they need to take to get value from the new feature.

Most in-app announcements have this fatal flaw. For instance, if you’ve ever used Trello, then you will be familiar with Taco the Husky and his announcements:

(Source)

If you were to click on that link though you would be taken away from the product and to their blog:

This is the opposite of what you want. Users have been moved to a detailed description of your product, possibly raising their motivation, but lowering their ability to act.

Plus, there's no guarantee that users will come back once you send them away from your app.

How many times have you clicked through a link thinking you’d just read one blog post and get back to what you were doing, only to disappear into an hours-long timesink? This is the fate Trello is tempting with this kind of feature announcement.

So far we have taken a look at how you can give release notes to your users via long-form information. No matter what happens, a user has to travel to the page to read it.

Instead, what if release notes could be shown via an in-product widget right in the app?

Let's step backward and examine why release notes exist in the first place. What is the point of telling the user about the details of your new release? The obvious answer is, to get them to use the very things you worked on. And in-app experiences are the best way to nudge users directly toward action.

For this purpose, you can use Chameleon to create on-brand in-product experiences, without the need to write any code. Showing users what to do in bite-sized chunks through Tooltips, Tours, and Launchers in-app self-serve help is an effective strategy to allow the user to understand the key new concepts and start using the features right away.

Feeling inspired to create engaging release notes that actually drive feature and product adoption for your users? Let's take a look at a few examples that stand above the rest.

This is a super simple yet highly effective way of communicating a new feature in-app.

By giving a modal that explains a new feature and how it can be used, it gives users motivation, knowledge, and the context to nudge them toward actually using the feature.

(Source)

In this example, Prosperworks uses a modal to share its product release notes and highlights the main points of the update. Users have the option to go and see the full list of improvements, or they can simply move on after finding out about the important changes.

(Source)

Here is another great example of educating your users in-app. This bottom banner that loads in-app allows the user to see detailed information about the latest features, that way the user can actually use this knowledge right away once they close the banner.

(Source)

This is another simple but highly effective way of showing release notes right inside the product.

Here, Stripe has summarized their most important features in their latest version and has put them front and center as a modal. It's concise, it's not as intrusive, and the user can smoothly transition into the product after reading it.

(source)

What's better than one release note? All the release notes. In Figma's in-app launcher, you always have access to the release note section, allowing users to have a self-serve resource at all times and learn as they go.

(Source)

Release notes should be a key part of your product strategy so your customers are always in the loop with everything they can do with your product. 

A survey conducted by James Scott from Google found that 83% of users are actually reading release notes and updates—so keep going with it.

Here’s a checklist with questions to ensure you’re making impactful release notes: 

• Is everything explained in a simple manner, without technical jargon?

• Is the message that you want to deliver straightforward and concise?

• Have you structured the text? Is your release note skimmable?

• Have you added images, GIFs, or other visuals to make it more engaging?

• Is your release note focused on the key points important for your users?

• Have you created different user segments for different types of release notes? 

• Is it showing your brand's personality with both language and styling?

• Do you know when, where, and how you will deliver a release note to your users?

If you find you're not getting much traction with blog and email announcements, look into using tours, tooltips, and other types of in-app experiences that actually engage users as you educate them. 

Remember, just because it says release ‘notes’, doesn’t mean that you have to actually write everything down. Showing is always much more effective than telling.