A good release note tells a customer what they can do now that they couldn’t before, in a sentence they’ll actually read. That’s it. Below is a free release notes template you can copy, three filled-in examples, and the handful of rules that make release notes worth writing.
The release notes template
Copy this, fill in the brackets and delete what you don’t need. It works for a changelog page, an in-app announcement and an email.
[Label: New / Improved / Fixed]
[Headline: what the customer can now do, in plain words]
[One or two sentences: the problem it solves, and who asked for it.]
How to use it:
1. [First step, with where to click]
2. [Second step]
[Screenshot or short clip]
[Thanks line: "Thanks to everyone who voted for this on our roadmap."]
[Link: "Try it now" or "Read the help article"]Three parts do most of the work: the label, the headline and the first sentence. Many people read nothing else, so make sure those three alone tell the story.
Three examples, filled in
Here’s the template used for a made-up product, Fieldnote, a note-taking app for researchers.
A new feature
New
Share a notebook with a link
You can now share any notebook with someone outside your workspace, read-only, with a single link. It was the most-voted idea on our roadmap, so thank you to the 214 of you who asked.
Open a notebook, choose Share, then Copy link. Turn the link off any time from the same menu.
An improvement
Improved
Search finds words inside your attachments
Search now looks inside PDFs and images you’ve attached, not just your notes. Type as usual; matches in attachments show with a paperclip.
A fix
Fixed
Exports no longer stop at 500 notes
Large notebooks were exporting only their first 500 notes. Exports now include everything. If you exported a big notebook recently, run it again to get the rest. Sorry about that.
Notice what they have in common. Each headline starts with what the customer gets, not the name of the feature. Each one is short. And the fix owns the mistake in one line, without a paragraph of apology.
Seven rules for release notes people read
- Lead with the outcome. “Share a notebook with a link” beats “Link sharing v2”. Write what the customer can do.
- One change per entry. A note that announces nine things gets read for one. Group small fixes into a single “Fixes and polish” entry if you must.
- Label everything. New, Improved and Fixed let people skim to what matters to them.
- Name who asked. If customers requested it, say so. People who voted feel heard, and everyone else sees you listen.
- Show it. A screenshot or a ten-second clip explains more than a paragraph.
- Skip the internals. “Migrated the search index to a new cluster” is for your team. “Search is twice as fast” is for customers.
- Ship notes as often as you ship code. A changelog that hasn’t moved in three months looks like a product that hasn’t either.
Where release notes should go
Writing the note is half the job. Getting it in front of the right people is the other half.
- A public changelog page. The permanent record. Prospects read it to see if you’re still shipping.
- Inside your product. A small “What’s new” badge or popup reaches people while they’re using it, which is when they care most.
- Email to the people who asked. The most valuable message you can send is “the thing you asked for is live”. It turns a feature request into a happy customer.
- Email to subscribers. For bigger releases, a short roundup to everyone who opted in.
Release notes vs changelog: what’s the difference?
People use the words loosely. A changelog is the running list of every change, usually on one page. Release notes are the individual entries in it, written for customers, often grouped by release. Developer changelogs, the kind generated from commit messages and described well by Keep a Changelog, are a third thing: useful for engineers, unreadable for customers. Keep them separate.
How we write ours
In Rectify, the changelog is part of the same workspace as your feature requests. When something ships, you link the requests it delivers, or give Quanta, Rectify’s AI teammate, a one-line prompt, and it drafts the entry in your tone with New, Improved or Fixed labels. You publish it to your portal and in-app widget, and Rectify emails your subscribers plus everyone who followed the linked requests, in a message that names what they asked for. An unread dot and an optional “What’s new” popup make sure people see it inside your product.
See it on the changelog page, and how requests get there on feature requests and roadmap.
Questions founders ask
How long should release notes be?
As short as they can be while still answering “what can I do now?” For most changes that’s a headline and two sentences. Save longer write-ups for big launches, and link to a help article for the how-to.
How often should a SaaS publish release notes?
Whenever something customers would notice ships. For a small team shipping weekly, that’s roughly weekly. Batching everything into a monthly post is fine too, as long as each change still gets its own clear line.
Should release notes mention bug fixes?
Yes, especially ones customers reported. Telling someone “the bug you reported is fixed” is one of the cheapest ways to win their trust.
Ship it, then tell everyone
You shipped it on Tuesday. Make sure someone notices. Hire Rectify free and Quanta writes the release notes while you build the next thing.
