What Belongs in Your B2B SaaS Release Notes?

Does anybody actually read your product changelog?

Three groups do, and none of them is the one you write it for. Existing customers checking whether a specific complaint was fixed, prospects in an evaluation checking whether the product is alive, and your own sales team looking for something to say. Write for those three and the page earns its place.

Most release notes are written for none of them. They are written for the engineering team that shipped the work, in the vocabulary of the ticket that described it, and they read as a list of internal events rather than as news anybody outside the company can use.

That is a shame, because a changelog is one of the few marketing pages that gets a reason to be updated every week, and pages with genuine reasons to be updated are rare.

What is a changelog actually for in a B2B context?

It is proof of momentum, and momentum is one of the few things a prospect cannot verify any other way. Case studies can be curated, testimonials can be selected, and a roadmap is a promise. A dated record of shipped work is the one claim about your pace that is checkable.

Buyers evaluating small vendors are genuinely worried about abandonment. They are deciding whether to build a process on top of your product, and the question underneath that decision is whether you will still be here and still improving in two years. A thin changelog answers that badly, and a missing one answers it worse.

I would treat that as the primary job and everything else as secondary. If a reader can tell at a glance that the product ships regularly and that the shipping is substantive rather than cosmetic, the page has done its work before they read a single entry.

What belongs in an entry, and what does not?

What changed, who it affects, and what they should do about it. Three short lines, in that order. The internal ticket number, the name of the engineer who shipped it, and the architectural detail all belong in your repository rather than on a page a paying customer reads.

The who-it-affects line is the one almost everybody omits, and it is the one that makes the page scannable. A reader with a specific setup wants to know within a second whether an entry is about them. Naming the plan, the integration, or the workflow an entry touches lets them skip nine out of ten items without reading the detail.

The what-to-do line matters more than it sounds too. Most changes require nothing, and saying so explicitly is valuable. The ones that require action are the ones people will otherwise miss, and a changelog where every entry states its required action makes those stand out by contrast rather than by shouting.

How should you write about a bug fix?

Plainly, naming the symptom the customer experienced rather than the cause you found. The person searching your changelog is searching for what went wrong for them, not for the internal reason it happened, and matching their language is the entire point of the entry.

There is an instinct to soften this, and I would resist it. Fixed an issue where some users occasionally experienced unexpected behaviour is a sentence that has been written thousands of times and has never helped anybody. Fixed a problem where exports over a certain size failed silently is useful, honest, and reflects better on you than the vague version does.

Vagueness reads as evasion to exactly the audience you care about. A technical buyer who has seen a lot of changelogs knows what the euphemisms mean, and specificity is the cheapest credibility available to a small vendor. It is the same argument as why customer logos are not proof, which is that vague signals are read as weak ones.

How often should you publish it?

On a rhythm you can hold, which is almost always less often than you ship. Weekly or fortnightly batches read better than a continuous stream, because a batch has a shape and a stream is just a feed. The rhythm matters more than the frequency.

Irregularity is what does the damage. A changelog with entries in January, February and then nothing until June tells a story you did not intend, and the gap is more visible than any individual entry. If you cannot sustain weekly, publish monthly and publish every month.

Batching also lets you group related work into a single entry that describes a capability rather than a sequence of commits. Readers care about what they can now do, not about the four increments that got you there, and the grouped version is both more honest about the value and easier to write well.

Should it live on your marketing site or in your docs?

On your marketing site, with a copy or a link in the docs. The changelog is a sales asset that happens to contain technical content, and burying it behind a login or inside a documentation subdomain removes it from the evaluation it was most useful for.

The practical argument is about who arrives. Prospects rarely wander into documentation. They look at your homepage, your pricing page, and if they are being careful, something that tells them whether the product is moving. If that third thing does not exist in the places a prospect visits, it may as well not exist.

It also wants to be a real CMS collection rather than a single long page that somebody edits. Entries with their own dates and their own URLs can be linked from support conversations, cited by an answer engine, and filtered by category, none of which works when the whole history is one document.

Does a changelog help with AI search visibility?

It can, for a narrow and specific set of questions. People ask assistants whether a product supports a particular thing, and a dated entry saying it now does is exactly the kind of short, factual, attributable passage that answer engines quote well.

The conditions are the same as anywhere else. Each entry needs its own URL, a clear date, and a self-contained statement that makes sense without the surrounding page. An entry that reads as a fragment of a list gives a retrieval system nothing to work with, and that is how most changelogs are structured.

I would not build a changelog for this reason alone. It is a genuine secondary benefit of doing the primary job well, and the primary job is telling a human buyer that the product is alive. Optimising the page for retrieval while writing entries nobody can understand gets you cited saying something useless.

Who should own it?

Product marketing, with engineering as the source. The failure mode where engineering owns the changelog is not laziness, it is vocabulary. People describe work in the language they did it in, and the language of implementation is not the language of consequence.

The workable process is that engineering supplies what changed and product marketing writes what it means. That translation step is five minutes per entry and it is the entire difference between a page customers read and a page nobody opens twice.

Give it a single named owner and a slot in the week. A changelog is exactly the kind of artefact that everybody agrees is valuable and nobody is responsible for, which is how it ends up three months stale while everyone assumes somebody else is handling it.

What should you do next?

Open your own changelog and read the last five entries as a prospect would. Can you tell who each one affects, and whether you need to do anything? If the answer is no for three of the five, the fix is rewriting the format rather than shipping more.

Then check the date on the most recent entry. If it is more than a month old, that page is currently arguing against you in every evaluation, and either updating it or removing it is better than leaving it as evidence of a stall.

Finally, decide who owns it and when they write it, because everything above depends on that and nothing above survives without it. A changelog sits alongside your other evaluation surfaces, including a security page that answers the questionnaire in advance and a pricing page that has decided what it is. If you want a second opinion on how your evaluation pages read to a careful buyer, reach out.