Run a public changelog that brings users back to your product

A public changelog is a dated list of what your team shipped, written for customers. It lives on its own page, appears inside the product, and feeds a regular email. It fits any SaaS product that ships often enough to have something to say at least a couple of times a month. It also helps late-stage buyers who want proof that the product is actively improving.

Why it works

Users rarely notice improvements on their own. They learn one path through the product and keep using it. When they never hear about the new export option or the faster search, they keep living with the old pain and may leave for a competitor that seems to have it. A changelog turns invisible work into visible progress.

It also brings people back. A note that says “You can now bulk-edit tasks” gives a lapsed user a concrete reason to log in and try it. For prospects, a busy changelog answers the quiet question of whether the company is alive and listening.

How to do it

1. Pick a home for the changelog. Use a page on your site such as /changelog, a dedicated changelog tool, or a section of your help centre. Give each entry its own URL so you can link to it.
2. Write for the customer. Lead each entry with the problem it solves, then explain the change in two or three sentences. Add a screenshot or a short clip. Skip internal ticket names.
3. Credit customer requests. When a change came from feedback, say so. Personally email the customers who asked for it with a link to the entry.
4. Add an in-app entry point. Put a “What’s new” link or badge in the product menu. Show a small in-app announcement only to users who use the affected area.
5. Send a monthly roundup email. Summarise the top three to five changes with links. Lead with the change that affects the most users.
6. Link every entry to the feature. The call to action should open the new feature inside the product.
7. Keep a steady rhythm. Assign an owner, usually a product manager or product marketer, and set a regular day to publish.

Example

A hypothetical form-builder SaaS ships small improvements every week, but customers keep asking support for features that already exist. The team creates a changelog page with one entry per release, each with a GIF and a “Try it” button that opens the form editor. They add a “What’s new” dot in the app menu that clears once a user opens it. Once a month they send a roundup email to all active and recently inactive users. Support starts linking to changelog entries in replies, and the product team tracks how many people click through to each feature.

Metrics to track

• Feature use after announcement. Compare use of each new feature in the week before and after the entry goes live.
• Roundup email click-through and reactivation. Track clicks and how many recently inactive users log in within a week of the email.
• Changelog page visits. Watch total visits and the share coming from the in-app link versus email or search.
• Support tickets about shipped features. Requests for features that already exist should fall as more users read the changelog.

When it backfires

• Gaps of months between entries. A stale changelog signals a stalled product, which is worse than having no public page at all.
• Engineering jargon. Notes like “Refactored query layer” mean nothing to users and teach them to skip the page.
• Announcing what isn’t live. If an entry goes out before a feature reaches every account, users who cannot find it lose trust. Publish after rollout or say who has it.
• Too many in-app pop-ups. Interrupting everyone for every small change becomes noise. Reserve pop-ups for big releases and target them.

Questions people ask

How often should we post to the changelog?

Post whenever something users would notice ships, and keep a steady rhythm so the page never looks abandoned. A small team might post weekly entries and send a monthly email roundup.

Should bug fixes go in the changelog?

Include fixes that customers reported or that changed how something behaves. Group small fixes into one line per release so they do not crowd out the main changes.

Does a public changelog help SEO?

Each entry is an indexable page that can rank for searches about your product and its features. Treat that as a bonus. The main job of the changelog is to keep current users informed.