Like Linear, we love using a changelog. It's a way of letting users know quickly and easily that the product is being worked on and improving.
Linear discussed their fondness for changelogs in detail here and this section is worth calling out:
Our initial aim was to share the latest product changes with our early adopters and communicate how rapidly we were adding new features and fixing bugs. In the last 12 months, we have published over 50 changelogs. After doing these changelogs for a year, it turns out it was more impactful than we ever thought.
Similarly, we've found great success by using a change log as a "forcing function" to always be shipping code. (you can see ours here) We love having a destination where we can write and write and write solely about the product and what we're doing to make it better.
Changelogs also act as an awesome way of reiterating to users that the product is still moving forwards. If a company has a changelog and the last post was a day (or hour!) ago — it's super exciting! similarly when a changelog hasn't been updated for a few months, you start to wonder if the company is still developing the product.
One of the issues with a changelog is actually making users read it organically. Some changelogs offer emails for new features, but that always seemed rather transactional. Similarly you can embed the changelog into your application - which is awesome - but even that doesn't feel like it solves the itch of reiterating to users that you're actively thinking and working on improving your product.
What we started doing was an "editorial" of our changelog once a month. We'd package all the changes - sometimes with even more colour (such as a video demo) than on the changelog - and email it to users is a single packaged Journey.
Here's an example of a Product Updates Journey — we send an equivalent to our users every month.