On Writing Great Product Release Emails

If you release software, you’ll need to communicate new features and bug-fixes to your users. Eleni has written about how OfficeLuv practices writing our customer-facing blog posts announcing features before we build, but we don’t announce every feature in our customer-facing changelog. We do, however, put out an internal product release email every week. It has remained a constant pulse over our 4 years, but we’ve improved the structure and content over time.

I think every team should put a good deal of effort into their internal communications, and the product release email format is a good standard channel to optimize. If I can get the rest of the company to look forward to our week email, that’s a huge win. Here are some aspects of our product release emails that get others reading and engaging.

Summarize First

One of the most-appreciated additions we made was to add a summary section at the very top of our emails. We simply include a greeting, mention the release name, and then go right into a bulleted summary of what was released since the last email. Each bullet is one complete sentence describing a new feature or squashed bug. We also only mention features or bugs that are visible/engaging to internal or external users.

This section is for executives, board members, or other readers wanting just a quick reference for what got out this week.

Mention Upcoming Work

After our summary, we always include a section titled Upcoming where we mention features or bugs that will likely be worked on next. We usually limit this to 2-4 topics, bulleted and written in the same tone as the summary above. We found that it’s better to mention fewer, higher-priority topics here rather than including a full list of what you’ll be working on.

This section is especially useful for leadership, allowing them to gauge product’s priorities and timeline.

Explain in Detail

From there we transition into details of each feature or bug-fix in the release. We generally have a paragraph or two for each, expanding on the one-sentence summary from before. With these explanations, we restate our original problem, and describe any steps to access or use new features.

We generally have 2 audiences for these details: the stakeholders of the feature or bug, who need to operate the feature or modify operations after a bug-fix; and our support team, who need to explain the feature to customers. We include more than just a basic description, though.

Thank Stakeholders and Contributors

In the details for each feature or bug, we make a point to thank the stakeholders by name. It seems small, but has had a great reception within the company. Calling out the person who reported a bug or had an idea for a feature encourages them to do more of the same. We’ve also seen that some feature requests get more usage if we name their champion and they feel accountable for its uptake.

Heavy on The Visuals

In the detail section, we have learned not to skimp on the visuals. Whenever possible, we include a GIF or video of new features in use. If there’s not change or motion involved, we include a screenshot. If we receive any questions in response to a product release email, it’s likely to asking how something will appear to users. It’s easiest to address that with multiple visual examples as you announce it.

We’ve also learned that a well-chosen and well-placed funny/topical GIF at the opening of the email and one at the close really drive opens of the email. It seems trivial but honestly is just a fun & easy way to make the product release email even more enjoyable.

Rotate Authors

We rotate authorship on our release emails. Each member of the team takes one week’s release and sends out the email to the company. It’s a nice way for junior team members to gain authority within the company and gain practice describing results to stakeholders.

Getting involved as the author of these emails also forces team members to reflect internally on what the whole team has accomplished. The author reaches out to others, works on a description for one feature or another, and has to practice pulling together a narrative of the group’s work.

It also allows us to gain a bit of experimentation with the style of the email. Different authors will choose different tones and we get to slowly see their reception with other teams. For authors without several release emails under the belt, we ask that a team lead review the content before sending it out.

Through rotating authors, we also focus the email’s authorship as the voice of the team. We don’t have only one person speaking for the team, the team members represent the team together and write as such.

Mention Long-running Work

Finally, we make a point to describe, briefly, any long-running projects in our detail section. This means that we’ll mention a multi-month project, even if nothing specific was released in a given week. This allows stakeholders to get a handle on the progress of their interests and know that we still have attention on long-lead features.

Our release emails originally were just a couple paragraphs, briefly mentioning new features. After asking for feedback and gauging the response to our experimentation over years, we’ve expanded them significantly. But with the extra time we put into them, we see greater involvement, investment, and enjoyment from the rest of the company.