A product changelog is the public, dated record of what you shipped, written for the people who use the product. Here is what a good one looks like, where it should live, and how to choose between the two very different kinds of software that publish one.
Full disclosure: I built ReleasePad, which is one of the tools discussed near the end. Everything above that point applies whichever tool you pick, including none.
Search for product changelog and you get three kinds of pages mixed together. Definitions, such as Keep a Changelog and a few glossary entries. Feedback platforms such as Canny and UserJot that sell a changelog tab at the end of a voting board. And changelog software that starts from your GitHub repository. Those are not ten flavors of one thing. The first group explains the artifact, and the other two are separate products that happen to share a noun.
This post covers all three in order: what a product changelog is, what a good entry looks like, where it should be published, and which family of software should publish it.
What is a product changelog?
A product changelog is a public, dated list of the changes that reached your users, written in their language rather than in the language of the people who built them. Each entry names one shipped change, says what it does for the reader, and tells them where to find it. The list runs newest first and never gets rewritten, so a customer can scroll back and see how the product got to where it is.
Two neighbors get confused with it.
A CHANGELOG.md file is not a product changelog. The Keep a Changelog convention describes a file in the repository for people who clone the repository. It is grouped by version and by change type, and it is written by developers for developers. Useful, and a different audience. Your customers will never open it.
Release notes are the longer cousin. Release notes explain one release in depth, with context, screenshots, and sometimes a migration guide. A product changelog is the running index those notes hang off. The changelog vs release notes post draws the line in detail. If you are still deciding whether you need either, read product release notes first.
What a good product changelog entry looks like
The gap between a commit and a changelog entry is the whole job. Here is a change as it left the repository:
feat(reports): add CSV export to reports table (#482)
Here is the same change as a product changelog entry:
Export any report as a CSV file New · 9 September 2026
You can now download any report as a CSV file. Open a report, click Export in the top right corner, and choose CSV. Whatever filters you applied stay applied to the file, so what you see on screen is what you get. Available on every plan.
Everything that makes the second version readable is missing from the first. The pattern that works:
- A title that states the outcome. “Export any report as a CSV file”, not “CSV export”, and never the commit subject.
- A date and a type. New, Improved, or Fixed is enough. Readers scan the type before the title.
- Two to four sentences. What changed, what it does for the reader, where to click. Stop there.
- Who gets it. Every plan, Pro only, or rolling out over the week. Leave this out and support gets the question instead.
- A screenshot or link when the change is visual or complex. Optional for most entries. Mandatory when the entry would otherwise say “see the docs”.
Leave out ticket numbers, commit hashes, and internal project names. Refactors, dependency bumps, and infrastructure work do not get entries unless a user could notice the difference. A fix that a user could have hit gets a line even if it embarrasses you, because the alternative is that user still believing it is broken.
Cadence matters more than polish. A product changelog that gets one entry a week for a year is worth more than a beautiful one that stopped in March. Every gap tells customers, prospects, and increasingly AI assistants that the product went quiet. For more entries to model on, see the release notes examples from ten SaaS companies and the free release notes templates.
Where a product changelog should live
One entry, four surfaces. Publish to whichever of these your readers actually use, and ideally to all of them from a single source so they never drift apart.
A hosted page. The canonical, linkable version. Support pastes its URLs into tickets, sales sends it to prospects who asked whether the product is still maintained, and Google indexes every entry. A public changelog page on your own domain is the minimum.
A widget inside the product. Most users never visit a changelog page. They log into your app and either see a badge or never learn the feature shipped. A widget inside your app puts the entry where they already are, at the moment they could use it.
Email and RSS for subscribers. The customers who want to be told get told. Every changelog tool does some version of this. The feedback suites do it best, because they know exactly who asked for the feature.
Markdown at a stable public URL. Users now ask Claude, ChatGPT, and Cursor whether your product does something before they ask you. Those assistants fetch text. A changelog they can read without an account, in Markdown or JSON, is how your latest release shows up in the answer. AI agents are reading your changelog covers what that changes.
Two kinds of product changelog software
This is the part the search results hide. The software that publishes a product changelog comes in two families, and they start from opposite ends.
Board first tools start from a feedback board. Canny, UserJot, ProductLift, and a dozen smaller suites sell feedback collection, voting, and a roadmap. The changelog is the last tab. Canny’s own feature page describes the changelog as “where you announce what comes out the other end” of a system that captures feedback, prioritizes it by revenue, and turns it into a roadmap. UserJot puts the loop in three words, “Feedback, roadmap, changelog”, and the AI prompt it advertises is “write a changelog for closed feedback this week”. ProductLift says it plainly: “Ship a roadmap item and it becomes a changelog entry. Every user who voted for that feature gets notified.” None of those three pages mention GitHub, commits, or pull requests, because in this family the source of every entry is the board.
Repo first tools start from the repository. The input is what merged: commits, pull requests, a tag. The tool drafts an entry in user language, a person edits it, and the same entry lands on the hosted page, the widget, and the Markdown URL. Feedback boards are out of scope on purpose. ReleasePad is in this family, and so is any pipeline you build yourself around GitHub Releases.
Both families are legitimate. The expensive mistake is treating them as substitutes. A team that ships from GitHub and buys a voting suite ends up typing every entry into a blank editor in a tool that never saw the release. A team that runs a voted roadmap and buys a repo first tool gets a clean page and a widget, and never emails the two hundred people who asked for the feature.
If the question you actually have is “file in the repo or page for customers”, that is a different fork, covered in changelog management tool. This post assumes you already want the page and asks where its words should come from.
When a feedback board is the right home for your product changelog
Stay with a board first suite when most of these are true:
- The roadmap is voted. Requests, duplicates, and “who asked for this” are your weekly objects. Announcing a ship without notifying the voters would break the product you actually bought.
- The announcement’s job is “we built what you asked for”. Retention comes from closing that loop, and the suite knows exactly who to close it with.
- You want one vendor for boards, roadmap, and announcements. A second tool so the changelog can read GitHub is overhead nobody on the team will staff.
- Git is not where the story lives. Work happens in tickets, calls, and the board. Commits are an implementation detail.
The honest failure mode: a suite does not become aware of your repository because it grew a “What’s new” tab. Every entry still starts from a closed request. Features nobody filed stay invisible until someone remembers to type them, and at the pace AI coding tools now produce commits, someone forgets. For a shopping list inside this family, see the Canny alternatives post.
When your product changelog should start from the repository
Move to a repo first tool when most of these are true:
- Releases already live in GitHub. The truthful draft is the commits and pull requests between two tags, not the three tickets that happened to close that week. That is the GitHub integration job.
- Users do not have a voting account. They log into a web app. They will notice a badge in the product or they will not notice the release at all. There is no voter list to email.
- Writing the sentence for users is the bottleneck. Commit volume went up with AI coding tools, and a blank editor at the end of a feedback loop does not keep up. You want a draft from what shipped and a human edit before publish.
- Search and assistants need a public URL. A changelog locked inside a feedback portal is a weak surface. A hosted page plus Markdown is how the same entries reach Google and the agents.
Three of the four true means a board first suite is the wrong product changelog software for you, however nice its widget screenshots are. You can still keep a board for prioritization. Publish the changelog from what shipped, and let the board be the board.
Where ReleasePad fits
This is the only place ReleasePad belongs in the decision, and only if the previous section described you.
ReleasePad is changelog only software for teams whose releases already live in GitHub. It reads commits and pull requests, drafts an entry in user language, and waits for you to edit and publish. The same entry then appears on a hosted page, in a 4.3kb widget inside your app, and as Markdown, RSS, and JSON at stable public URLs. If you would rather draft from your editor, the MCP server lets Claude or Cursor write and publish entries for you.
There are no feedback boards, no voting, no NPS. If you want those, buy Canny or UserJot. Pricing is a flat $35 per month per product on Pro, with a free tier that does not expire after two weeks. No seat fees and no meter on monthly active users. GitHub is the only git host today, so GitLab and Bitbucket teams write entries by hand or through the MCP server. Questions go to felix@releasepad.io.
The decision in one table
| If this is true | Your product changelog should |
|---|---|
| The roadmap is voted, and announcing a ship means emailing voters | Come from a board first suite such as Canny, UserJot, or ProductLift |
| Work lives in tickets and a board, and git is an implementation detail | Same family. Start from the board |
| Releases already live in GitHub, and users never vote | Come from a repo first tool that drafts from commits |
| Writing entries from commits is the weekly bottleneck | Repo first, with AI drafts and a human edit |
| You only need a CHANGELOG.md for people who clone the repo | Not this purchase. See Keep a Changelog and the CLI vs SaaS fork |
| You have picked a family and want names and prices | Come from the ten tool roundup |
Two artifacts for two jobs is allowed. Keep the board for deciding what to build. Publish the product changelog from what you actually shipped. One changelog tab stretched across both jobs usually fails the one you have.
Further reading
- The 10 Best Changelog Tools in 2026: the shopping list once you know which family you are in.
- ReleasePad vs Canny: the board first end of this fork, in detail.
- Changelog Management Tool: CLI vs SaaS: the other fork, a repo file versus a customer page.
- Keep a Changelog: The Format Explained: the file convention for developers.
- Changelog vs Release Notes: the definitional split, if it is still fuzzy.
- AI Agents Are Reading Your Changelog: why the Markdown URL is part of the job now.
- Changelog App: the product page, if you already chose a repo first tool.
Frequently Asked Questions
What is a product changelog?
A product changelog is a public, dated list of the changes that reached your users, written in their language rather than in developer language. Each entry names one shipped change, explains what it does for the reader, and says where to find it. It runs newest first and is published on a page, in a widget inside the product, by email, and as Markdown that AI assistants can read.
Is a CHANGELOG.md file a product changelog?
No. A CHANGELOG.md follows the Keep a Changelog convention and lives in the repository for people who clone it. It is grouped by version and written by developers for developers. A product changelog is written for customers and lives where they are: a public page and a widget inside the app. Many teams keep both, because the two audiences never overlap.
What should a product changelog entry include?
A title that states the outcome, a date, a type such as New, Improved, or Fixed, and two to four sentences that say what changed, what it does for the reader, and where to click. Add who gets it, such as every plan or Pro only, and a screenshot when the change is visual. Leave out ticket numbers, commit hashes, and internal work nobody can see.
Which product changelog software should I choose?
It depends on where your entries start. If your roadmap is voted and the announcement's job is to tell voters you built their request, a feedback suite such as Canny, UserJot, or ProductLift is the right product changelog software. If releases already live in GitHub and users never vote, choose a tool that drafts from commits and pull requests and publishes to a page, a widget, and Markdown. Treating the two as substitutes is the most common bad purchase.
Can I run a feedback board and a repository based product changelog together?
Yes, as long as you actually run both jobs. Keep the board for collecting and prioritizing requests. Publish the product changelog from what shipped in git, so features nobody filed still get announced. The two share a moment, the ship, but not a source or a reader, so do not expect either tool to do the other's job.
Ready to put this into practice?
Your changelog shouldn't be an afterthought.
ReleasePad makes it easy to publish great release notes — from a public changelog page to an in-app widget, GitHub integration, and analytics. Free to get started.
Get started — it's free