The product update email template that gets read
6 min read updated
The product update email that gets read is the one sent to somebody who asked for the thing it announces. Everything else competes with the rest of the inbox on interestingness, which is a contest a release announcement loses most weeks. That single fact should decide the shape of the email before any wording does: who is receiving it, and what did they do to end up on the list.
What is a product update email?
It is a message telling existing users what changed in a product they already use. There are four distinct kinds, and treating them as one list is why open rates decay. Each has a different trigger, a different audience and a different acceptable frequency.
| Kind | Trigger | Audience | Frequency |
|---|---|---|---|
| Targeted notification | A specific person’s request shipped | One person | Whenever it happens |
| Breaking change notice | A change that costs the reader work | Only affected accounts | Whenever it happens |
| Digest | Time passing | Opted-in users | Monthly at most |
| Launch announcement | A launch worth interrupting for | Segment or everyone | Rarely, and it should feel rare |
Most teams only build the third one, send it to everybody, and conclude that product update emails do not work. The first two carry almost all the value, because the reader has a prior reason to care and the message arrives when that reason is live.
All four rows here are written for customers. Sales, support, and success teams need to know what shipped too, and usually in a different shape than any of these; internal release notes covers what that document should say and why it needs to land before the customer-facing one goes out.
Email is one of several channels a launch announcement can use, not the only one. How to announce a new feature covers the others, and how to pick between them by how big the feature actually is.
What goes in the template?
Six blocks, in this order. The first is the one usually missing and it is the one doing the work.
Subject: <what changed, in the reader's words>
1. Why you are getting this
"You asked for CSV export in March." or
"Your integration calls /v1/invoices, which changes on 15 January."
2. What changed
One sentence. What is now possible, or what now breaks.
3. What you need to do
Often "nothing". Say so explicitly rather than leaving it implied.
4. Where to see it
A link to the changelog entry, not to the homepage.
5. When
The date it shipped, or the date it takes effect.
6. How to stop receiving these
One click, and honour it immediately.Block 1 is the difference between a message and a broadcast. A reader who is told, in the first line, that this is the resolution of something they personally raised reads the rest. Without it, blocks 2 to 5 are a newsletter regardless of how well written they are.
Keep the whole thing under roughly 150 words. The email is a pointer to the changelog entry, and the entry is where detail belongs. An email that reproduces the full entry gives the reader no reason to click and gives you no signal about whether anyone cared.
What does the template look like filled in?
The targeted notification, which is the highest-value product update email and the one most teams never build:
Subject: CSV export is live
Hi Dana,
You opened a request for CSV export back in March.
It shipped this morning. Reports now have an Export button that
produces a CSV of the current view, filters included.
Nothing to do on your side. It is on for your account already.
Details: example.com/changelog#csv-export
Shipped: 2 September 2026
You are getting this because you asked for it. Unsubscribe from
request updates: <link>Ninety words, and the reader is told in the first line why this arrived. Compare it with the same change in a monthly digest, where it appears as one bullet among nine and Dana has no reason to notice her own request went out.
What should you measure?
Not the open rate on its own. For a targeted notification the question is whether the person who asked came back and used the thing, so the number worth watching is the click through to the entry and the feature being used by that account within a week. For a breaking change notice it is coverage: what share of affected accounts opened it before the date, and who did you follow up with individually.
A digest is the only one of the four where an open rate means much, and even there it is more useful as a trend against its own history than against an industry benchmark. Different kinds of product update email have different jobs, so a single blended figure across all of them describes nothing that can be acted on.
What subject lines work?
Name the change, not the release. “CSV export is live” outperforms “September product update” because the first is a fact the reader can evaluate and the second is a container. Version numbers in the subject line are useful to callers of an API and noise to everyone else, which is another reason the audiences should be split.
Avoid stating a benefit the reader has not agreed to. “Your reporting just got faster” asserts something about their experience; “Reports over 10,000 rows now load in under a second” reports a change and lets them decide whether it matters.
When should you send one, and to whom?
Send a targeted notification the moment the thing ships, to the people who asked, individually. Send a breaking change notice as early as the date is certain and again close to it, to the accounts actually affected rather than the whole list. Send a digest only if you have enough changes that a reader would otherwise miss something, and let people opt into it separately.
The list you should almost never use is “all users”. It converts a specific message into a generic one, and it trains the unsubscribe. Segment by behaviour you already store: who requested this, who uses this endpoint, who is on this plan.
Do you need consent to send it?
For existing customers, an update about a service they use is usually a different legal question from marketing to a prospect, and the answer depends on where they are and what you told them at signup. In the EU the relevant question is which lawful basis applies under Article 6 of the GDPR, and in the United States commercial messages carry specific requirements set out in the FTC’s CAN-SPAM compliance guide. Both make the same practical demand: say who you are, make the purpose clear, and let people stop.
Whatever the basis, keep transactional and marketing streams separate at the sending level. A breaking change notice that a customer has unsubscribed from because it shared a list with a promotional digest is a support incident waiting for its date.
How is this different from release notes?
Release notes are a document that stays available. The email is a delivery mechanism that happens once. The same change produces both, and the email should be shorter than the note it links to. Release notes best practices covers the document, and changelog vs release notes covers which one you are writing.
The relationship worth getting right: the changelog entry is the canonical text and the email quotes it. When those two drift, the reader who clicks through finds a different description of the change and stops trusting both. Publishing the entry first and generating the email from it removes the drift by construction. Changeloop works the same way on its side: an entry is reviewed and published to the feed, the widget and the hosted page once, and the person who asked for it through the widget is told on the GitHub issue their feedback became, and in the widget itself. Changeloop does not send the email; your email tool quotes the published entry.
FAQ
How often should a product update email go out? As often as there is something the recipient specifically wants to know, which for a targeted notification is whenever their request ships and for a digest is monthly at most.
Should the email contain the full changelog entry? No. One sentence and a link. The entry is the canonical version, and a full copy in the email means two texts to keep in agreement.
What open rate should I expect? Compare each kind against itself rather than against a benchmark. A targeted notification and a monthly digest are different products, and averaging them hides the only number worth watching.
Do I need a separate list for breaking changes? Yes, and it should be the one list people cannot casually unsubscribe from without understanding the consequence, because it is the one that costs them an outage.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.