Somewhere in your backlog is a ticket for a bug you already fixed. The user just didn’t know.
Writing Release Notes Nobody Reads
My software team recently took over the release notes process. Originally, we started with a long document that comprehensively covered each JIRA ticket, complete with a Figma link and sections like “How to Use” and “Why it Matters”. But tickets kept coming in for problems the release notes already addressed. People were still doing things the old way.
The Digest Fix
We realized we needed to try something different. Our client team builds software for operators who are in-house. They often communicate with us via Slack to raise support requests. Leveraging Slack , we decided to create a “digest” Slack message to post in the support channel, since we know Slack gets more traffic than a more formal release notes document.
We split the notes into three sections:
🚀 New Features
✨ Improvements
🐞 Bug Fixes
Each piece of work could be no more than a bullet point. This way, we could send the most important information to our operators without the overhead of having to read a bulky document. Using emojis breaks up the feeling of reading a big wall of text, and we even added the block quote formatting under each section to make them feel tied together.
The Synchronous Layer
The second thing we do is partner with the Product Operations Director to hold a small training with operators. Keeping it quick but synchronous helps keep the operators engaged and gives them the space to ask questions. Often, we will get valuable feedback from them during these trainings as well.
Know Your Audience
Ultimately, it’s important to think about the audience of your release notes. Solutions for our own in house operators wouldn’t make any sense if our release notes were for an API for developers, or public facing users. Once we tailored our communication process to our users, we started to see more success. It’s not perfect, but our operators have a better sense of changes as they come in.