To write a product changelog customers actually read, lead each entry with the benefit to the customer, not the feature name, keep it to two or three short sentences, add a screenshot or GIF when the change is visual, and link to the help article or setting. Group small fixes into one line, post on a steady rhythm such as weekly or every release, and tag entries as New, Improved or Fixed. The most effective changelogs also tell the customers who asked for a change that it shipped, by email or in the app, instead of waiting for them to find the page.
A changelog is the cheapest marketing a SaaS team has. Every entry is proof the product is getting better, and every customer who asked for a change is a reason to send one. Yet most changelogs read like commit messages. Here is how to write one people want to read.
What a product changelog is
A dated, public list of the changes to a product, written for customers: what is new, what improved and what was fixed, and why each change matters to them.
Why it is worth the effort
- It shows momentum. Prospects check whether a product is alive. A changelog with entries from last week answers that.
- It closes the loop. Customers who asked for something can see it arrived.
- It cuts support questions about how a new feature works.
- It is good for search. Each entry is a fresh, specific page about your product.
Anatomy of a good entry
| Part | What to write | Example |
|---|---|---|
| Title | The benefit, not the feature name | Send weekly reports to people who never log in |
| Tag | New, Improved or Fixed | New |
| Date | The day it shipped | November 6, 2026 |
| Body | Two or three sentences: what changed and why | Schedule a PDF of any dashboard every Monday. It arrives by email, no login needed. |
| Visual | A screenshot or short GIF when it is visual | The new schedule menu |
| Link | Where to find it or learn more | Settings, Reports, or the help article |
| Credit | Who asked, when it fits | Thanks to the 23 customers who voted for this |
Good and bad examples
| Instead of | Write |
|---|---|
| Added PDF export endpoint | Export any report to PDF in one click |
| Refactored notifications service | Notifications now arrive in seconds instead of minutes |
| Bug fixes and improvements | Fixed: dates in CSV exports now match your time zone |
| v2.14.0 released | Three things that make onboarding new teammates faster |
| Implemented SSO (SAML) | Sign in with Okta or Microsoft Entra ID |
The pattern: start from what the customer can now do, use their words, and be specific. “Bug fixes and improvements” tells nobody anything.
A changelog template
| Field | Fill in |
|---|---|
| Title | [Customer can now do X] |
| Tag | New / Improved / Fixed |
| What changed | One sentence on the change |
| Why it matters | One sentence on the problem it solves |
| How to use it | Where to find it, with a link |
| Visual | Screenshot or GIF |
| Thanks | Optional: the customers or votes behind it |
How often to post
- Ship weekly? Post weekly, with small fixes grouped into one Fixed line.
- Ship in bigger releases? Post with each release and lead with the headline change.
- Whatever the rhythm, keep it. A changelog that stops for two months looks like a product that stopped.
Getting people to see it
A changelog page alone gets little traffic. Bring the update to people:
- Email the customers who asked. This is the single most valuable thing you can do with a changelog entry. See how to close the feedback loop.
- Show it in the app with a small “What’s new” badge or widget.
- Link it from the roadmap item so people following the public roadmap see it shipped.
- Share the big ones on X, LinkedIn and in your newsletter.
Hi Grace, you asked for this in March and it is live today. Thank you for voting.
Changelogs in Murmur
In Murmur the changelog sits next to your roadmap and feedback portal. Mark an idea shipped and Murmur drafts the changelog entry and emails every customer who voted for it, so the people who asked hear first. You can see a live example on our own changelog. It is free to start, and Solo is $19 a month.
Frequently asked questions
What is a product changelog?
A product changelog is a dated, public list of the changes to a product: new features, improvements and fixes. SaaS teams use it to show customers the product is moving and to announce what shipped.
What is the difference between a changelog and release notes?
They overlap. A changelog is usually a running page of every change in date order. Release notes often describe one version or release in more detail. Many SaaS teams use one page for both.
How often should you update a changelog?
On a steady rhythm that matches how you ship: every release, or weekly or every two weeks. A regular rhythm matters more than size. Group small fixes together rather than posting each one.
What should a changelog entry include?
A clear title that names the benefit, a date, a tag such as New, Improved or Fixed, two or three sentences on what changed and why it matters, a screenshot when it is visual, and a link to the setting or help article.
Should internal changes go in a public changelog?
Only if customers notice them, such as faster load times or better reliability. Refactors and infrastructure work that customers will never see belong in your internal notes.
How do you get customers to read your changelog?
Bring it to them: email the customers who asked for a change, show a small badge or widget in your app, and share bigger updates on social media and in your newsletter.
Collect it, rank it, ship it, tell everyone
Murmur is customer feedback software for small SaaS teams: a feedback portal and widget, AI that captures requests from email, revenue on every vote, and emails to every voter when you ship. Free for one board with unlimited voters.