Product update emails are one of the most under-leveraged tools in SaaS retention. They're not as glamorous as acquisition campaigns, but a well-written product update email to your existing users is worth more per open than almost any other email you send.
Here are five templates for different scenarios. Copy and adapt them for your own product.
Before the templates: what makes them work
A few principles that separate product update emails that get read from ones that get deleted:
1. Lead with the benefit, not the feature. "You can now bulk-delete contacts" not "We added bulk deletion support to the contacts module."
2. One main thing per email. Email with five equal items gets read as email with no important items. Pick the most important update and put it first. Everything else is secondary.
3. Be specific. "We've made several performance improvements" says nothing. "Dashboard loads 3× faster on mobile" says something.
4. Tell users how to access it. Don't make them hunt. "You'll find it under Settings → Integrations → Zapier."
5. Include a direct CTA. One button. "Try it now" or "See what's new", not five links competing for attention.
Template 1: Major feature launch
Subject: New in [Product]: [Feature name]
Hey [First name],
We've just shipped [feature name], and it's something you've been asking for.
[Write one sentence explaining what it does, framed around the user outcome.]
Here's how to find it: [short path: Settings → X → Y, or just "click the new [icon] button in the top nav"]
[One sentence on why you built it / what problem it solves. A humanizing detail.]
[Optional: one-line teaser of what's coming next]
[Your name], [Your role at Product]
[Button: Try [Feature] now]
You're receiving this because you have an active [Product] account. [Unsubscribe]
Example filled in:
Subject: New in Patchlog: your commits now write the first draft
Hey Sarah,
Connect a repo and every push comes back as draft changelog entries, one per user-facing change, waiting for you to review before anything goes live.
You still decide what ships and how it's worded. You just don't start from a blank page on a Friday afternoon.
Open your project, go to the GitHub tab, and add the action to your workflow. Lockfiles,
.env, vendor and build output are stripped on the runner, so they never leave your repository.We built this because writing the notes was the reason changelogs went stale, not installing one. Every bit of feedback said the same thing.
Michael, Patchlog
[Connect a repo →]
Template 2: Minor update digest (monthly)
Subject: [Month] updates: what we shipped
Hi [First name],
Here's a quick rundown of what we shipped in [Month]:
[■ Biggest feature] [One sentence. What it is and what it does.]
[■ Second feature or improvement] [One sentence.]
[■ Bug fix or performance improvement] [One sentence, optional. Include only if notable.]
Full details are in the changelog: [link]
As always, reply to this email with feedback. We read every message.
[Team or name]
[Button: Read the full changelog]
Notes on this template:
- Three items maximum. More than three becomes a wall of text.
- The "reply to this email" line is important. It makes the email feel like a conversation, not a broadcast, and it genuinely generates useful feedback.
- Link "the changelog" to your actual public changelog page (not just your marketing site).
Template 3: Bug fix / reliability update
This template is specifically for when something was broken and you've fixed it, an opportunity most teams miss to actually rebuild trust rather than just silently ship a fix.
Subject: We fixed [specific issue], here's what happened
Hi [First name],
We want to give you a quick update on [specific issue].
What happened: [One paragraph. Be specific. "On [date], users who tried to export reports larger than 50MB encountered a timeout error." Not "some users experienced issues with exports."]
What we did: [One sentence. What was the fix? When was it deployed?]
What we're doing to prevent it: [Optional. One sentence. Only include if you've genuinely made a process change. Do not make this up.]
We know this was frustrating, and we're sorry it happened. If you were affected and want to talk about it, reply directly to this email.
[Name]
Why this template matters:
Most teams treat bug fixes as something to be buried. But users who experienced the bug and then get a clear, honest explanation feel more trust in the product afterwards than they did before the bug. The transparency is the product.
Template 4: Feature announcement for a specific segment
For when a new feature is only relevant to a subset of your users: developers, admins, a specific plan tier, and so on.
Subject: [Segment-specific subject, e.g., "For teams on the Business plan: [feature]"]
Hi [First name],
This one is specifically for [Business plan customers / API users / admins. Be specific].
We've shipped [feature], which [one sentence outcome].
How to access it: [Specific path or link]
Who does this affect: [Short description of which users will see this and under what conditions]
If you have questions about how this works with [their specific use case], reply here. Happy to walk you through it.
[Name]
[Button: Go to [Feature]]
Key principle: When you segment, say you've segmented. "This one is specifically for X" tells the user they're getting a targeted message, which makes them more likely to read it.
Template 5: The re-engagement changelog email
For users who have gone quiet and have not logged in for 30 to 60 days. Show them what they've missed without being pushy.
Subject: Here's what you missed in [Product] while you were out
Hi [First name],
It's been a while, and we've been busy.
Here's what's new since you last logged in:
[Feature 1]: [One sentence benefit] [Feature 2]: [One sentence benefit] [Feature 3]: [One sentence benefit]
[If your product has a specific job to be done, connect one of these features to it:] In particular, [Feature X] was built for [their specific use case], and it might change how you think about using [Product].
No pressure. But if you want to see how [Product] looks today, we'd love to show you.
[Name]
[Button: See what's new]
If you'd rather we not send these emails, [unsubscribe here].
What makes this work: The "here's what you missed" frame is non-threatening. It's not "please come back", it's "here's information." The CTA is soft. Users who were thinking about cancelling and then see three features that solve their problem change their mind here.
One final note on frequency
The templates above work best when they're supplementing, not replacing, an in-app changelog widget. Email is how you reach users who aren't in the product often. The widget is how you reach users who are.
If you're using both together:
- Monthly digest email → summary of the month's updates
- In-app widget → every individual update, announced immediately when it ships
The email drives re-engagement. The widget drives daily discovery. They serve different jobs.
Need a changelog that powers both? Patchlog gives you an embeddable widget and a public changelog page, free forever →