Most release notes templates are a grid of empty boxes: version, date, New, Improved, Fixed. The boxes are fine. What is missing is the rule for each one, so the same template produces a sharp note from one person and a pasted list of ticket titles from the next. Below you get the template, then the rule and a quick test for every field, then two fields that almost no template includes.
What fields should a release notes template include?
A release notes template should include a version and date, a one-line summary of why the release matters, changes grouped into New, Improved and Fixed, known issues, and any action users must take. Two internal fields make it more useful: Requested by, naming who asked for each change, and How we'll know it worked.
The first six fields are what your customers read. The last two are for your team, and you strip them out before anything is published.
The release notes template (copy and paste)
# [Product] [version] - [Month Day, Year]
[Summary: one sentence on what changed for the reader and why it matters.]
## New
- [What you can now do], [where to find it].
## Improved
- [What works better], [in which situation].
## Fixed
- [The problem you may have hit], [now fixed].
## Known issues
- [What is still wrong], [the workaround], [when we expect a fix].
## Action needed
- [Who must do what], [by when]. Write "None" if nothing.
<!-- INTERNAL: remove everything below before publishing -->
## Requested by
- [Item] - [accounts or request links that asked for it] - [told them: yes/no]
## How we'll know it worked
- [Item] - [the signal you will check] - [what counts as success] - [check date]If you would rather fill in a form than edit Markdown by hand, the free release notes generator can produce the public part for you. It takes a version, a date, a summary and your New, Improved and Fixed lines and gives you clean Markdown to paste.
The rule for every field
A field without a rule gets filled with whatever is closest to hand, which is usually the ticket title. The table below says what belongs in each field, what to leave out, and a test you can run on the draft in a few seconds.
| Field | What goes in | What to leave out | Test |
|---|---|---|---|
| Version and date | The version users see in the product, and the date it reached them | Internal build numbers, branch names | Can a support agent match a customer's screen to this note? |
| Summary | One sentence on the change that matters most to the reader | A list of everything; "various improvements" | Could a customer repeat it to a colleague without opening the app? |
| New | Capabilities that did not exist before, phrased as what the user can now do | Internal refactors, ticket IDs, team names | Does each line start with the user, not with what the team built? |
| Improved | Existing things that now work better, and in what situation | Changes no user would notice | Would someone who uses this every day see the difference? |
| Fixed | The symptom the user hit, described the way they would describe it | Root-cause detail, blame, stack traces | Would the person who reported the bug recognize their problem? |
| Known issues | What is still wrong, with a workaround or an expected date | Problems you have not confirmed | Does every line give the reader something to do or wait for? |
| Action needed | Anything a user must change, migrate or re-enable, with a deadline | Optional tips; those go in New | If a reader skips everything else, will they still avoid breaking something? |
| Requested by (internal) | The accounts or request records behind each item | Customer names in the public version without their permission | Can you open the original request from this line? |
| How we'll know it worked (internal) | One signal, a success condition and a check date per item | Vanity counts like page views of the note | Could someone else run the check on that date and get a clear yes or no? |
Two rules apply across the whole note. Write benefits, not tickets: "You can now filter the board by customer" beats "BOARD-412: add customer filter". And design for scanning: many readers stop after the summary and the first few lines, so put the change with the widest impact first.
Why add "Requested by"?
Much of what you ship started as a request. A customer wrote in, a prospect raised it on a call, a support thread kept coming back. When the change lands, those people are the ones most likely to use it and the ones who most deserve to hear about it directly, not through a changelog they may never open.
The Requested by field forces that list into existence while it is still easy to build. For each item, link the original requests or name the accounts, and mark whether you have told them. That last column turns the release note into a to-do list for closing the loop: a short personal message to each account that asked, saying it shipped and where to find it.
Keep this field internal. Customer names do not belong in public notes unless the customer has agreed. The value is in the follow-up, not in the publicity.
Why add "How we'll know it worked"?
Shipping is not the same as working. A feature can launch cleanly and still go unused, which is the problem we cover in why nobody is using your feature. Writing down the signal before you look at the data keeps you honest about what success meant.
Each line needs three parts: the signal, the success condition and a check date. A hypothetical example: "Saved views - accounts that requested it have created at least one saved view - check four weeks after release." Pick a signal that reflects real use, not attention, and put the check date in a calendar rather than only in the note. For more on choosing the signal, see how to measure feature adoption.
The release note as the last step of the loop
Treated this way, the release note stops being a chore at the end of a sprint. It is the step where the work comes back to the people who caused it: feedback became a roadmap item, the item was built, and the release tells the customers who asked and sets up the check on whether it helped. We walk through the full chain in connecting feedback, roadmap and delivery, and the step before it in turning customer feedback into product changes.
The two internal fields are only cheap to fill if the links already exist. When requests live in one tool, work in another and usage in a third, filling Requested by means searching three places. In AIOProductOS every backlog item carries the customer request and the revenue behind it, and every shipped feature carries an outcome verdict on its task card: adoption, MRR adopted and retention lift. That lift is correlational, not proof that the release caused it, and it should be read that way.
Ask an AI assistant to draft the Requested by list
If your product data is reachable over MCP, an assistant can do the first pass. AIOProductOS exposes releases among its MCP writes, alongside the full PM read surface. Ask something specific:
"For the items in release [version], which accounts requested each one? List the request, the account and the date it was raised."
Then check it. Open a sample of the requests the assistant listed and confirm each one really asked for that change, and look for requests you remember that are missing. Only then send the follow-up messages. An assistant's list is a draft to verify against the records, not the record itself.
When a plain changelog is enough
This template is built for products where the reader is a user and changes need explaining. Not every product is like that.
For developer tools, API libraries and SDKs, a terse versioned changelog is often the right call. Developers want the version, the breaking changes and the diff, in a predictable format, and many teams generate it from commit messages or pull request titles. Rewriting that as benefit-led prose can make it harder to scan, not easier.
For a small team shipping several times a day, a note per release is noise. Customers will not read ten notes a week. A weekly or monthly digest that groups the user-visible changes works better, and the two internal fields can move to that digest instead.
In both cases the internal fields still earn their place. A changelog can be terse in public while your team still tracks who asked and what you will check.
Start with the next release
Copy the template into wherever your next note will be drafted, fill the internal fields first while the context is fresh, and strip them before you publish. When you are ready to format the public part, use the free release notes generator to turn your summary and changes into clean Markdown.