How I organise my product releases

Communicating a release to all stakeholders is an important part of the PM job (Airbnb agree). The release approach I've put together ensures:

1. Everyone's aware of the good work my team's doing, from customers to the senior leadership team.

2. Internal teams are informed of our release in a way that's relevant to them.

3. Product & marketing are aligned.

4. Key individuals are personally informed of changes important to their success.

Public release notes

I write & publish release notes on our documentation site. These release notes are public and accessible to both customers and prospects. 

In my release notes, I include:

1. Big features. There are usually one or two of these per release. I illustrate this section with screenshots and provide a lot of context, use cases, links to implementation docs, etc.

2. Enhancements. These are small-ish things we've changed. I'll typically use bullet points to list them out as there may be anywhere between 5 and 20 of those per release.

3. Bug fixes. These are quite self-explanatory. I also use bullet points to list them out.

Because my public notes are, well, public, I lean towards marketing copywriting. I focus on the pain points this release is solving, and use beautiful screenshots to illustrate the features. I also sprinkle some of the brand's personality into it.

Linear’s changelog is a great example of non-technical public release notes

I lean away from technical 'stuff' as much as possible. This means no technical language nor listing enhancements or bug fixes that are too technical. No one cares that you've migrated a database or reduced SQL query response times by 27 nanoseconds.

Finally, I write a marketing release email to go out to all our users. I limit the email content to a handful of highlights, typically 2-5, each with an illustration and a short bit of text.

Internal release package

Announcing the same release internally takes a slightly different format.

I prepare a release package for each of the key teams. 

For each package, I tweak the content slightly to better address what each team specifically cares about:

• Sales: focused on why X feature is a value-add, any impact on prices, new use cases, potential market expansion, etc.

• Customer service: focused on supporting resources, documentation, questions they should expect from customers, etc.

• Product: focused on informing the wider product team of my product's progress towards our common strategic goals.

• Senior leadership: incredibly succinct email focused on business impact. I try to literally keep it to 2-3 sentences.

In the same email, I attach a video walk-through of the new feature(s). Because this is internal, it doesn't need to be fancy. A simple 2-3min Loom does the trick. 

Although not technically release notes, Amir, CEO of Todoist, shows how a simple video walk-through can help illustrate a new feature. Here’s an example.

Finally, our entire product department hosts regular company-wide release sessions. We walk through a short slide deck covering the new features, use cases, and live demos. 

Ad hoc communication

New features, enhancements, and bug fixes can be a real unlock for some individuals across the business. A salesperson might be waiting for feature X. A customer service rep might be waiting for bug fix Y.

I track these requests in a Jira ticket, noting which customers (and/or colleagues) made the request. 

When the feature/enhancement/bug fix goes live, I refer to my notes and privately contact the individuals involved. This is on top of the wider communication above, as an 'in case you missed it' nudge. 

Product release note inspiration

• Meta. They lean much further into the technical side than I do, but this is required for a product like Llama.

• Linear. Great format, immaculate illustrations, and language that focuses mostly on solving pain points.

• Productboard. Specifically, the Productboard blog releases. This is a slight departure from the two examples above. I do like the approach of a fully marketing-y blog post to go along with their 'normal' release notes.

• Todoist. Todoist’s changelog does an excellent job of communicating changes and bug fixes using their brand’s friendly voice.