Skip to main content

Product update email templates, starting with the customer who asked for it

Seven product update email examples for a software product, from the note to the customer whose request just shipped to the new feature announcement and the monthly roundup. Send the personal ones first.

The templates

Each one copies with its subject line. The parts in brackets are the parts to change; everything else can go out as written.

The feature they asked for has shipped

Subject: Re: [their original subject line]

Hi [Name], You asked for [feature] back in [month]. It is in [Product] [version number], out today. [One or two lines on how it works, in their words rather than yours, for example: You can now export to CSV from the File menu, and the export includes the tags you mentioned.] To get it, [update from link / open Product and choose Check for Updates / nothing, it is already live in your account]. Thank you for asking. Requests like yours are a big part of how I decide what to build, and I wanted you to hear this from me rather than from the changelog. If it does not quite do what you had in mind, reply and tell me. Yours is the opinion I most want on this one. [Your name]
The short version, for someone who asked

Subject: Re: [their original subject line]

Hi [Name], [Feature] is in [version number], out today. You asked for it, so I wanted to tell you myself. Thanks for the push. [Your name]
Shipped, but not exactly what they asked for

Subject: Re: [their original subject line]

Hi [Name], You asked for [what they asked for] a while back. I have shipped something close to it, though not exactly that, and I wanted you to hear about it from me. In [version number], [what you built, in one line]. It does not [the part of their request it does not cover], because [one honest sentence on why]. For what you described, [how to get most of the way there with what exists now]. If it misses the point of what you needed, tell me. That is useful to hear, even now. [Your name]
New feature, to everyone

Subject: New in [Product]: [feature, in a few words]

Hi [Name], New in [Product] [version number]: [what the feature does for them, in one line, for example: you can now have a report arrive in your inbox every Monday]. Why it exists: [one sentence, for example: many of you told me you were opening the app every week just to copy the same numbers]. How to use it: [the two or three steps, or a link to a short guide]. [To get it: update from link. / It is already live in your account.] As always, reply if something is not right, or if it is not quite what you needed. It comes straight to me. [Your name]
Monthly update or release notes

Subject: What is new in [Product]: [month]

Hi [Name], Here is what changed in [Product] in [month]. New - [Feature]: [what it does for them, in one line] - [Feature]: [one line] Improved - [Improvement, for example: search is much faster in large libraries] Fixed - [Fix, described as the symptom they would have seen, for example: the app no longer forgets your window size] The full list is at [changelog link]. To get all of it, [update to version number / nothing to do, it is live]. Next up: [one thing you are working on, if you are happy to say it in public]. [Your name]
A change customers will not like

Subject: A change to [feature] in [Product] [version number]

Hi [Name], A heads-up about a change that some of you will not like. From [version number / date], [what is changing, plainly, for example: the compact layout is being removed / new projects will be private by default instead of shared]. Why: [the honest reason in one or two sentences, for example: very few people used it, and keeping both layouts working was slowing down everything else]. What it means for you: [the practical effect, for example: if you used the compact layout, the app will open in the standard one after the update, with your other settings unchanged]. What you can do: [the closest alternative, a setting that gets most of the way there, or: stay on version number for now, which keeps working until date]. If this breaks something you rely on, reply and tell me how you use it. I read every reply, and this is the kind that can change the plan. [Your name]
A change to plans, not to the price

Subject: A change to [Product] plans on [date]

Hi [Name], On [date], [what changes in the plans, for example: a new Team plan arrives, and the plan you are on stays exactly as it is]. What it means for you: [the one-line answer to "does this change what I pay or what I get?", for example: nothing changes for your account / feature moves to the Pro plan, and you keep it at your current price]. You do not need to do anything. [If they can choose: If you would like to switch, you can at link.] Any questions, reply here. It comes straight to me. [Your name]

If the change is a higher price, that email has its own rules (the old and new number, the date, and a way out), and they are on the price increase email templates page rather than squeezed in here.

Subject lines that name the feature

Name the change in the subject. “Our latest update” and “Big news from [Product]” tell the reader nothing, so they judge by the sender alone. For the customer who asked, reply in their own thread: their words at the top are the best subject line you have.

  • Re: [their original subject line] (for the customer who asked)
  • You asked for [feature]. It is here.
  • New in [Product]: [feature, in a few words]
  • What is new in [Product]: [month]
  • A change to [feature] in [Product] [version number]

What makes a product update land

  • Lead with what it does for them. “You can now schedule a report” beats “Introducing Scheduled Reports”. The benefit first, the feature name second, if at all.
  • Tell the people who asked, personally. Before the announcement or alongside it, in their own thread. It is a minute each, and it is the version they remember.
  • Say how to get it. Update, refresh, turn it on in settings, or nothing. A feature someone cannot find has not shipped, from where they sit.
  • One headline change per email. If you shipped five things, lead with the one most people will use and list the rest in a line each.
  • Bad news gets its own email. A removed option as the fourth bullet of a feature announcement reads as hidden, and the replies will say so.
  • Send it from an address people can answer. A product update that invites replies is where the next feature request comes from.

The email that closes the loop is the one that never gets sent

A feature request arrives months before the feature. You replied at the time (“good idea, it is on the list”) and the thread went into the archive with everything else. When the feature ships, you remember the feature. You rarely remember who asked, and nothing in the inbox says that person is still owed an answer.

That is the idea Moorline is built on. It does not send announcements to your list; use whatever you already send product email with. What it does is give every conversation two facts: is the work handled, and has the customer been told. A shipped feature with a customer who has not heard is a reply owed, the state no mail client shows, and Moorline keeps that customer on your list until you have written back. It is the same gap as the issue resolved email: a fix that ships long after the report, to someone who has stopped expecting to hear.

Questions people ask

What should a product update email include?

What changed, described as what the reader can now do; how to get it (update, refresh, or nothing); and a way to reply. For a single feature, that is three short paragraphs. For a batch, lead with the change most people will use, list the rest in a line each, and link to the full changelog.

How often should I send product update emails?

When there is something worth telling, not on a calendar. A monthly roundup works if you ship steadily in small pieces; a separate email is worth it for a feature many customers asked for. An update with nothing in it teaches people to skip the next one.

Should I tell customers who requested a feature when it ships?

Yes, personally, and in their original thread if you can. It is the easiest product email to get right, because it is about something they asked for, and it tells them their next request is worth making. Send it even if they will also get the announcement to everyone.

How do I announce a product change customers will not like?

In its own email, before it happens: what is changing, the honest reason, what it means for them, and what they can do instead. Do not bury it in a feature announcement or wrap it in "exciting" language. Answer every reply, and read closely the ones that explain how people used what you removed.

What is the difference between a product update email and release notes?

Release notes are the complete record: every change, fix and version number, usually on a changelog page. A product update email is the selection a customer should actually read, in plain words, with a link to the full notes for anyone who wants them.