Here at Nickelled, we’ve written our fair share of product updates for our users – we’ve been in business since 2014, and we ship new product features (small and large!) weekly, if not daily – so we’ve come to rely on a release note template to help us communicate the latest and greatest enhancements.
There’s a big catch here – because in our view, release notes are one of the WORST ways to communicate new product features. Why? Well, because in most contexts, they look like this:
See the many problems? It’s truncated, in tiny text, and it’s talking only about the app and not about users. There’s a reason that you only see release notes in this format in App Stores (where they’re mandatory) – they don’t serve the company or the user particularly well.
For that reason, as Adam Sigel at InsightSquared explains on this excellent ProdPad blog post, “most people don’t read them”.
However, release notes ARE useful for us, and our users, and there’s a reason we use a template internally; it’s the skeleton from which our marketing and sales team hang their work when announcing a new product feature to our users.
Every time we ship something with an internal release note, it flows into other parts of the business, and it will normally end up in a blog post announcement with images and use cases like this one:
See how much more useful that is than an internally-relevant release note?
Our Release Note Process
We start thinking about release information, which will eventually make it into the release note, early.
Product decisions start in our Trello pipeline, which is organised in a way that will feel familiar with anybody following a kanban-style methodology:
Cards on Trello move from an idea/backlog phase through to design, in-process, test and production, and all the while, we’re trying to understand exactly what the feature on the card means to the user.
This will generally mean that each card features links to our various product feedback channels, such as Intercom, our database table which collects cancellation feedback, or the spreadsheet maintained by our customers success team (yes… We could be better at collecting this stuff!).
From those links, we’ll have fleshed out the functionality requirements on the Trello cards, often in a ‘users should be able to do X’ type of format, which is ideal for a release note!
As the card passes through design and test, we’ll also have collected screenshots, which (assuming they’re the same as the production release), are extremely handy to use in product release material.
At the point where the card moves from in-progress to test, we’ll append some information (if it’s not already there) which is vital for writing the final release note to the card.
Ticket Type: Feature Enhancement / Bug Fix / Upgrade / Other
Explanation: What is this card? Normally we’ll track this in the card title, but it’s important to know whether this is new functionality
Top Line: Normally the card name
Explanation: What’s the one-line summary of this ticket?
Expected Functionality: What should the user be able to do after this card is in production?
Explanation: This should be a user-friendly illustration of how the card will impact users. For a new feature this might be “view tasks as a board as well as a list” or for a bug fix it might be “fixes bug which prevented users from sharing their location with WiFi disabled”.
Impact: 1/2/3/4/5
Explanation: We use this when prioritising our product pipeline, so it’s already attached to the card. But essentially, this helps us to understand how great this change will be for the user.
Our dev team is responsible for ensuring this information is present on every card which makes it into production.
Our Product Release Note Template
Since we’re deploying cards almost daily, we rely on our weekly retrospectives to get our first aggregated look at what we’ve shipped, and on a fortnightly/monthly basis, we’ll pull that information together into an internal-only email our CEO sends to the team.
Here’s the release note template we use, with any internal-only information italicized:
<Date>
<Deployment Tag Number from Github>
<Preface>
Time Period of changes (e.g. over the last two weeks…)
People we want to specifically call out has having done a great job (e.g. our infrastructure team and front end team)
<New Features>
- These are our “big bang” changes
- The title of the new feature (e.g. “Nickelled Launchers”)
- The topline objective of the new feature (e.g. “Nickelled Launchers make it easier to launch Nickelled Guided Tours from your website”)
- Bulleted underneath, the Trello cards, reformatted slightly so that it’s “You can…”, rather than “Users should be able to…”
<Feature Enhancements>
- These are important changes to existing features – they add useful but limited functionality to an existing product area.
- The title of the enhancement (e.g. “Dedicated URLs for Academy Articles”)
- The topline benefit of the enhancement e.g. “You can now provide your visitors with specific URLs to Academy pages, instead of the Academy homepage”
<Bug Fixes>
- These are fixes to issues that customers have raised, ordered by Impact
- This should be a one-liner, focused on the impact only (e.g. “Fixed: Users can now update their email address without having to fill out address field”)
<Ops>
- These are changes we’ve made to infrastructure for stability or security
- We’ll rarely release these publicly, unless they have a significant user impact (e.g. “Guides now save 3x faster”)
<Deployment Tag Number from Github>
Taking our Release Notes Public
This release note template is only used internally, but we’ll then tweak it for external release. How?
In Blog Posts
For the example above, we’d plan a specific blog post on Nickelled Launchers, which covers more use cases and examples, along with providing branded graphic and screenshots so that users can really grasp which the release has added. You can see an example of how that might look here.
Note the differences between the release note and the feature launch blog post – we stay focused on the user, remove any extraneous information, and include a bunch of ways to get extra help if it’s required.
Occasionally, we might write multiple blog posts to cover off functionality which our CEO has featured in one release note. If there’s a headline new feature and a bunch of enhancements which are also impactful for users, we’re likely to separate those, to ensure that the enhancements don’t distract from the new feature announcement, which will likely also be used in marketing materials and potentially as an SEO landing page too.
In Emails
In common with many other companies, we’ll send release notes via email.
However, we never send the same release note format that that our CEO uses externally – it’s just not user-friendly enough.
Instead, our marketing team will extract the most impactful messages from each release note and wrap it up into an email to announce the good news, often replete with emojis ?
If we’ve got a dedicated blog post for a feature, we’ll link directly to that post in the email, often wrapping the additional bug fixes or enhancements underneath.
Occasionally, we’ll segment these emails – our user base will receive the link to the blog post plus all of the other impactful changes featured in the release note, and our mailing list (which includes prospects and people who have opted in after downloading ebooks etc) will receive just the blog post.
Inside our App
We use Nickelled Announcement bars to draw attention to new product launches inside our app, normally with a link to a guided tour or blog post:
We may also use Intercom to deliver a fuller explanation to users when they’re logging in:
Both of these are driven by our in-app event tracking – if we know that a user has already used the feature or was using it in beta, we wouldn’t surface the information.
On our marketing site
We try to wrap our release notes into our marketing copy on a quarterly basis as a minimum, checking to see whether we need to update copy or screenshots on our website to make sure that potential users are aware of our latest product enhancements.
Sometimes, we’ll launch a dedicated landing page which is distinct from our launch blog post. This isn’t common, but for a significant enhancement we know that prospective users may want to learn more, and even to try the feature, before they sign up. A good example of this is our Launchers page, which went far beyond our Launchers blog post and actually provided interactive examples of how Launchers work for users to click on.
On Facebook and Google
We’ll run Facebook ad campaigns to highlight new features if we think they’re likely to convert our existing audiences better than what we’ve tried before.
We’ll also update the sitelinks on our CPC ads to relevant launch and landing pages, especially if we know that the new feature is something prospects will be searching for.
Conclusion
So there you have it – the release note template which we use, not externally, but as a kickoff point for a marketing lifecycle which stretches from a Trello card through to a Facebook ad campaign.
So, it may be true that users don’t read release notes – but it may also be that you haven’t tried hard enough 😉