What is a changelog and who reads it?

What is a changelog?

A changelog is a dated, chronological list of changes to a product. Each entry says what changed, when it shipped and, in plain words, why someone who uses the product would care. Its purpose is to keep people informed about a product that keeps moving, so they can see progress and find new features without reading commit messages.

A changelog is written for people who use the product, not for the developers who wrote the code. A line such as "fixed null pointer in the export module" belongs in a commit. A line such as "Exports no longer drop the last row of a large file" belongs in the changelog.

Who reads a changelog?

Three audiences read a changelog, and each one uses it differently:

• Customers check it to learn what is new, to confirm that a bug they reported was fixed, and to decide whether to try a feature they had ignored.
• Support staff use it to answer questions quickly. If a customer asks why a button moved, the changelog entry is the explanation.
• Sales and success teams use it to show momentum to prospects, and to remind existing customers of value they may have forgotten.

These readers want different things from the same entry. Customers want the benefit. Support wants the scope and any workaround. Sales wants the headline. A good entry gives each reader enough to act, without writing three separate versions.

What should each entry say?

Each entry should follow a simple pattern: the change, the benefit, and the scope. Keep it short enough to scan in a few seconds.

1. Start with one plain sentence describing what changed, such as "You can now export feedback to CSV from any product inbox."
2. Add one sentence about the benefit, in the reader's terms.
3. Note any limit, behavior change or step customers must take, so support is not surprised.
4. Link to the feature or to the place where it lives.

Avoid internal names, ticket numbers and vague phrases such as "various improvements." An entry that says nothing specific does not earn a reader's attention.

How do you link entries back to the feedback that caused them?

Linking is what turns a changelog from a list into a loop. When a change shipped because customers asked for it, record that connection on the feedback item itself. Then the reply can point to the entry, and the entry can show that the request led to the change.

In practice, keep a short internal note on each feedback item that names the changelog entry resolving it, and paste the entry's link into that note. When the change ships, set the item to done and send the reply that points to the entry. Do not name a customer in the public entry unless they have agreed to it.

Link the entries that changed behavior someone asked about. Leave routine fixes unlinked, because a changelog that cites every ticket becomes hard to read.

Changelogs also serve as a record for your own team. Six months later, a new hire or a returning founder can read the list and see how the product grew, which decisions were made and why. That history is valuable only when entries are specific enough to make sense without the original conversation. A vague line such as "updated the editor" tells the future reader nothing, while "the editor now keeps line breaks when you paste from a document" says exactly what changed and why it mattered.

Treat the changelog as a written promise. Each entry should be true when it is published. If a later change reverses it, add a new entry instead of quietly editing the old one. Readers notice when entries quietly disappear, and that erodes trust faster than an honest correction.

How often should you publish a changelog?

Publish on a rhythm your team can sustain. Many small teams publish one entry each time a meaningful change ships, and gather minor fixes into a periodic summary. Consistency matters more than frequency. A changelog updated every two weeks reads as active. One updated once a year reads as abandoned.

Batch the writing if you ship often. Draft entries at the end of each week from the items marked done, then review them together. The guide on writing a changelog that customers read covers structure and tone in more depth, and the note on release notes and feedback explains how the same entries can invite the next round of replies.

Tracing changelog entries to feedback in Escuta Produto

Escuta Produto covers the feedback side of this loop, not the publishing side. The changelog itself lives wherever you publish it. What Escuta Produto gives you is a record of the requests behind each change. Every item has a type, a status from new to done, and private internal notes where you can paste the changelog link.

Marking an item done in the inbox leaves a record you can filter for when you write the next entry. Filter by done to find the items that are ready for a reply, and use the search box to find related messages before you write the entry. Escuta Produto has no tags, so keep the connection in the note on each item. The widget documentation explains how messages arrive in the first place. For the reply step that follows the entry, read how to tell customers their request shipped.