Death to "Minor bug fixes"
- Modern users treat software as an investment, expecting you to incorporate their feedback into the development process.
- You're working hard for your users, but they don't always know that.
- There's no place you can point and say "this is how we changed stuff in the last couple of months."
- You need to get at least another department to help you update users.
- Users spend time mastering the software and bringing changes without telling the users can feel like the ground is slipping from under them.
- Customer success & sales teams can't position themselves as product experts in front of customers / prospects.
- Have an open space that you can own and update your users on what changed.
- Continuously engaging your users can help with churn.
- Remove the need to update all departments by centralising client-facing changes.
Changelog as a service
- Git logs ≠ changelogs Think of it as the middle ground between a git log and a press release.
- The ordering should be reverse chronological. Users shouldn't have to scroll to get an answer for "What's the latest update?"
- If the users have the opportunity to update themselves, and there are breaking changes - make it very clear.
- Keep data formats open for every region that might read it, starting from higher to lower: YYYY/MM/DD.
- If possible, use something that makes it possible to link between sections. (for example: announcing a fix for an update and giving more context to user by linking between the two)
- Tailor your dialogue for the users. (working on an open-source project and highly-skilled developers are interested in every change vs mom and pop shops who are interested in "how will this affect my business")
- Help your users explore new features by linking to relevant help articles or using GIFS / short videos for walkthroughs.
- If you're working within a team, consider taking the burden from your development team and use a tool that can be used without having to deploy code or write html.
- If you're working in B2B you might want to opt for in-app release notes that sit behind some sort of authentication and/or is removed from search indexing.
- Keep your changelog somewhere visible within the platform.
How do you structure an update?
From Keep a changelog:
Added for new features.
Changed for changes in existing functionality.
Deprecated for soon-to-be removed features.
Removed for now removed features.
Fixed for any bug fixes.
Security in case of vulnerabilities.