How to effectively communicate product updates company-wide

We’re very lucky to be a part of a fast-growing SaaS B2B2C business - the work is interesting, exciting, challenging, and rewarding. As product managers, we’re smack bang in the middle of everything and we play a central role in driving the business’ growth. But with rapid growth comes growing pains.

One area we’ve recently noticed has been under strain is how we communicate changes to our product to the wider business.

Every quarter we dedicate 10% of our objectives to improving how we work, so for the first quarter of 2021, we decided it was time to tackle our communication process for product releases.

Establishing the problem areas

We use Kanban to manage our workflow and practice continuous development, releasing new features and updates daily. Some of these releases go pretty much unnoticed, but a fairly large chunk will change a part of the user experience.

Communicating via Slack

We have a company-wide Slack channel called #productupdates where we post about each release, so people could know when a change was live.

We also sent out a weekly Product Newsletter on Monday mornings with a roundup of the features released the previous week.

For bigger or more complex releases, we would hold training sessions for the teams that would be impacted by these changes.

The problem with the current process

With the volume of changes we were making to the product each week, we started noticing a few problems:

1. We were becoming inundated with messages from various teams with simple questions about the releases such as “When did this go live?”, “How does it work?”, and “Who does the change affect?”
2. People were assuming things about the changes we made that went well beyond the scope of what we actually released
3. People had to contact the product managers to get the information they wanted, which meant we were spending a lot of our time answering the same questions for multiple people

We wanted to understand and address what was causing these problems, and understand how to better communicate product changes, so our colleagues could self-serve and so that we could reclaim some of our own time.

How to understand the problem

As always with product management, we started by trying to understand the problem. We spoke to a bunch of our colleagues from all areas of the business about what they want to know when we release an update to the product.

We learned that people were contacting us directly because:

• Past releases were hard to find in the Slack channel, especially with the volume of releases we do
• There wasn’t enough detail about functionality in the announcements in the Slack channel or Product Newsletter
• If additional documentation was provided with the announcements, each product manager used a different format and provided different levels of information

From this feedback we formed the following hypotheses:

• Our colleagues want to be informed about changes to the product and, if given the opportunity, will self-serve to find out the information.
• Having a centralised place for this information that’s easily accessible will encourage our colleagues to self-serve, reducing the amount of contacts we received for each release.

Testing our hypotheses

To get the ball rolling, we created a centralised place where all the information about releases could go, so that people could self-serve right straight away.

Creating a central location for product releases

When we discussed what we should use as our centralised place all sorts of ideas were thrown out, including tools like Notion or internal wikis, but we wanted to test a hypothesis and the fastest way to do that was to start simple: we created a spreadsheet.

In it, we categorised and added links to any release notes we created in the previous quarter (regardless of quality), and shared it in our #productupdates Slack channel.

Improving our release notes

Next, we looked at improving the quality of our release notes to ensure that our colleagues had the answers to their questions in the first place.

We felt it was important to do this in a standardised way so that the information wouldn't be impacted by the different styles of each product manager and which would also make it harder to measure the impact of changing our process.

Sharing the right information about our product updates

During our earlier discovery, we asked our colleagues exactly what information they wanted about a release. Based on this feedback, we created a release notes template on a Google doc which acted as a checklist for the information we needed to include and committed to using this template for every new release.

The new release notes template contained the following:

• Release date
• Product manager in charge
• A summary of the feature (why we did it and what it does)
• Step-by-step instructions (with screenshots)
• Scope and limitations
• Useful resources (such as a link to related releases, videos of the feature in action)

Our new release communication process now looked like this:

• Write release notes using the Google doc release notes template
• Add a row in the centralised place spreadsheet
• Post in #productupdates with a link to the release notes
• Add a link to the release notes in the Product Newsletter’s ‘Highlights - Features Released’ section 

Did Goodlordians find it easier to locate the product update release notes?

After a few weeks of following this process we did see a slight drop in people contacting us with simple questions, but not as significant as we had hoped.

We went back to our colleagues to find out more. The response was mixed.

Surveying Goodlordians to understand the impact of our changes

Out of 18 people who answered the question: ‘Would you know where to find the product release notes?’

• 10 said in the #productupdates channel on Slack
• 1 said in the product newsletter
• 3 said both the #productupdates channel on Slack and product newsletter
• 4 said they’d have no idea where to find them
• 0 mentioned the centralised place

Out of 25 people who answered the question: ‘Do you use the release notes?’

• 18 said yes
• 7 said no

So far, so-so, but not the impact we were aiming for. We were encouraged by the number of people who used the release notes, particularly as the people who said they didn’t, tended to be more senior members of staff who don’t need to know the intricacies of each new release (as they’re not on the phones to customers).

Issues in the new process

However, we were worried that people still weren’t aware of the centralised spreadsheet and were still struggling to find past release notes, because they were still coming directly to us with questions.

We also received feedback that, while the new template was good, there was information people wanted that was still missing.

Making further improvements to our product update processes

Armed with more data and a better understanding of what our colleagues were looking for, we made a few adjustments:

1. We re-shared the centralised place, pinning it to the #productupdates channel, adding it to the channel’s description, and setting up a fortnightly reminder in the channel to keep it fresh in peoples’ minds.
2. We added a few more things to our release notes template, including who to reach out to if there are any problems with a release, a requirement for a link to a video showing the feature in action for more complex changes, a link to the centralised place, a section for any future planned work relating to the release.
3. We sent out an email to the whole company detailing what a release note is, what our process is, and how people can access them.

Conclusion: A drop in questions around new product updates and releases

We’re tentatively calling our new process a success as we’re still measuring its impact, but we have all seen a substantial drop in questions about recent updates to the product and we’ve received some positive feedback from the people across the business who have been using our new release notes.

More visibility for all

The Google Docs activity dashboard has provided us with visibility about who has viewed our release notes so we can see that they’re being used and by whom - and also who isn’t using them - so we are able to get more targeted feedback.

Ideas for improving the product release process further

Now that we have validated our hypotheses, the next step is to invest in making the process better.

For example, building an internal wiki which might make categorisation and searching for specific release notes easier, particularly with the high volume of releases.

The next steps for improvement

Going forward we will continue to track engagement, collect feedback, and ensure our team members have the information they need at their fingertips. This process has been a great way for us to apply lean development principles and shows that you don’t have to be building a new product to implement them yourselves.

Want to advance in your tech career? Check out the jobs we have available.