Template

Product update email

The regular note to people already using the product. Smaller than a launch, more often, and written for somebody who already knows what the words mean.

Your Product <[email protected]>

to [email protected]

Faster exports, and two things you asked for

Three changes from the last two weeks. About a minute.

Your Product

What changed in the last two weeks

Three things, and one of them is the export speed complaint several of you have raised.

Exports over 50,000 rows now stream instead of building in memory. A file that took four minutes takes about twenty seconds.
You can duplicate a saved report, which was the most asked-for thing in replies to these emails.
Date filters remember the last range you used, per report rather than globally.

The export change needs nothing from you. The other two are already on your account.

See the full changelog

Something in here not doing what you expected? Reply and tell me which one.

Alex, Your Product

Your Product Inc, 1 Example Street
Unsubscribe from these emails

A worked example of the blueprint below. The brand, the names and the numbers are placeholders; the structure is the part to copy.

The blueprint

Rebuild it anywhere

Subject lines (5 options)

Faster exports, and two things you asked forshown above
What changed in the last two weeks
Exports are about twelve times faster
Three changes, one of them yours
Product update: exports, duplicates, date filters

When it fires

Trigger: Fires on your own cadence, to people who have used the product recently: this is a scheduled send to an active segment, not an event-driven email.
Timing: Every two to four weeks, on the same weekday, and skip a cycle rather than padding one. A predictable slot is what makes it get opened.
Conditions: Send only to accounts active in the period. An update about changes to a product somebody stopped using is a win-back email wearing the wrong clothes, and it performs like neither.

The body, block by block

The period, and the count
"Three things from the last two weeks" sets the size of the email in the first line. A reader who knows it is short reads it; a reader who cannot tell scrolls to check and often stops there.
The best one first
Not chronological, not by effort. Lead with the change most of the list will notice, even when it was the smallest job.
One line each, with the concrete effect
"Four minutes to about twenty seconds" is a change. "Improved performance" is a category. Where you have the number, use the number.
Whether anything is required
Say explicitly what the reader has to do, including when the answer is nothing. This single line is why an update email gets read by people who skip launches.
One link, to the full list
The changelog carries everything that did not make the email. That is what lets you keep the email to three items without hiding the rest.
The reply prompt
Ask about what is not working rather than what people liked. It is the question that returns usable answers, and it turns the update into the cheapest bug channel you have.

When to use it

For the steady stream of changes that matter to people already using the product and would mean nothing to anybody else. That is most of what you ship. The distinction from a launch email is the audience and the size: a launch is aimed at people who do not yet use the thing and it carries one idea across several emails, while an update is aimed at people who do and carries several changes in one.

Sending both keeps each one honest. Without a regular update slot, small improvements get promoted into launches they cannot carry, and the list learns that an announcement from you is not worth opening. With one, the launch sequence stays reserved for the few changes that genuinely deserve it, and the update carries the rest to the audience that actually wanted them.

What kills this email

Listing everything that shipped
A complete list is a changelog, and it belongs on a page. Three items in the email and a link to the rest gets more of the three read than fifteen items gets any of them.
Writing it in release-note language
Ticket numbers, component names and codenames are for the team that built it. The reader wants the effect on their Tuesday, described in the words they would use for it.
Naming the change without the consequence
"Improved the export pipeline" tells a customer nothing they can act on. Say what is different when they do the thing they were already doing.
Sending it to inactive accounts
People who stopped using the product do not want a list of changes to it, and including them drags the engagement numbers on your best-performing email. They need a win-back, which is a different email with a different question.

When not to send it

Do not send it in the same week as a launch sequence to the same segment. The update will be read as part of the launch and the individual changes in it disappear.

Do not send it on a fixed schedule when nothing has changed. A cycle with three real items skipped once beats two cycles padded to look busy, and the padding is what teaches a reader to stop opening.

Read Drip Campaign Examples: The 5 Email Sequences Every SaaS Needs

Browse All 11 email templates

Private beta