Tips for Communicating Product Releases *Inside* Your Company
A good way to inform users is to inform colleagues first.
TL;DR - Communicating product releases inside a company can be as important as communicating them externally, because especially in a B2B company many users will find out about changes from salespeople, customer success managers, support engineers, and marketing content. As PMs, if we don’t properly prepare our colleagues then they can’t prepare our users!
Most modern SaaS companies operate in an Agile or continuous-integration process where they ship new features and fixes at least once per month. There’s a lot written online about how to communicate product changes externally. But one thing I haven’t seen much written about is how to help folks inside your company. That’s what this post is about.
Release Emails 101
When I was Head of Product at Cantaloupe, I or someone on my team would typically send a company-wide email a week or so before every release. Here’s the structure we honed via years of experimentation and feedback:
First, a one-sentence TL;DR summary for the large percentage of the company who like to stay informed but who may not have the time or interest to dig into the details. For example: “This release addresses customer requests for improved custom reporting by speeding up custom reports by 30%-50%, by adding a custom filtering option, and by adding 45 new reports to our report catalog.”
Next, a high-level list of features and major bug fixes in the release. Ideally, the features are described in non-technical terms from the customer’s point of view, which enables non-technical employees (which are most employees!) to understand what the features are and why they matter. For example: “Custom Report Filtering - reports can now be filtered by any field in the report, using the same easy-to-use column search interface we use to add columns to a report. This was requested by Acme Inc, Consolidated Corp., and many other customers and will reduce the custom reporting work that our sales engineering team has previously had to do.”
Next, a link to release notes, documentation, training videos, and/or other detailed info about each feature, so that folks who want or need more detail than your short bullet points. You are writing user-friendly release notes and documentation, right? If not, start! I’ve found that having PMs write the first draft of technical documentation can save a *lot* of time—from PMs as well as others like Support or Sales—by answering questions without having to respond to each question individually.
Next, a heads-up about what’s coming *after* this release, again keeping things high-level. For example: “The next release will include the first beta release of our new mobile app that you’ve probably seen a demo of in the last all-hands meeting. If you have customers in mind who you think would be good candidates to try the new beta, please let Joe know.” One reason we did this was to address feedback from colleagues who complained that hearing about new stuff a week ahead of time wasn’t enough advance notice. I was skeptical that people would really use the extra time to educate users; I thought it was just an excuse to complain. But after we started previewing future releases the complaints stopped so from my perspective it was Mission Accomplished! 😃
Finally, and this is really important: thank people! Public recognition for good work is incredibly meaningful, especially to junior engineers and other employees who may not interact with customers directly. It’s your job to show them how valuable their work is to your company’s customers and to the rest of the company. For example: “This release was a cross-company effort, but I especially want to thank Elliott and Jennie on the engineering side and Chuck on the Sales side partnering together to figure out which reports should get built, and Billy from Sales Engineering chipping in to build 37 reports in 4 loooooooong days. Way to go, team!” I’ve heard concerns that public thanking of individuals is risky because you inevitably forget someone. YMMV, but this didn’t turn out to be a problem for us, perhaps because we thanked people so often. Even if we missed someone once, they knew that their next chance in the limelight wasn’t too far away.
The common thread across all the bullet points above is to minimize the level of detail so skimmers can get the gist without putting in a lot of effort, while allowing curious or conscientious colleagues to dig in and learn more.
I found it useful to think of my colleagues like I think of my product’s users: as well-meaning, busy people who have a lot on their plate and who are depending on PM to respect their scarce time by pre-chewing information so it can be digested easily.
Emails Are Not Enough To Train The Company
You’ll probably find out sending out emails for every release is necessary but not sufficient to inform your colleagues. People are busy, and many of them simply won’t read your release emails. Also, some people—I see this a lot from non-technical folks like salespeople—may have a different learning style that works better by learning with meetings or videos versus reading emails. We found that we needed to supplant regular release emails with a more multi-media approach. Over the years we tried many different non-email solutions. Some worked better than others. Here’s what we learned:
Live “Training sessions” worked very well and were well-attended. For every major release (every 2-3 months, usually) we’d do a combined training session for Sales, Customer Success, Support, and anyone else who was interested. There was usually a mix of in-person and remote attendees. While folks were in the room, they would often ask questions unrelated to what’s new in that release, which was helpful to backfill knowledge missed previously.
We’d record the training sessions and folks could watch them offline. Remote salespeople in particular appreciated this because they were often traveling during our live sessions.
For big milestones or events (e.g. annual industry conference) we’d host training meetings (ostensibly for booth workers) that we also recorded. These recordings served as demo training for salespeople throughout the year, and because we had annual industry conferences it ensured that our demo trainings didn’t get too stale. There was also Q&A during these sessions too which helped with backfilling knowledge as noted above.
We’d attend Sales meetings at least quarterly so we could exchange knowledge with the Sales team and go over what’s coming soon in the roadmap. This was also a good venue for wide-ranging Q&A and “spot training” on features that the room was interested in.
Office hours / fireside chats didn’t work well because they require attendees to be proactive to attend. There wasn’t enough uptake to be worthwhile in our small company.
The overall lesson here is that repetition—especially across time and across different media—can be really helpful to facilitate learning at scale across your company. And providing opportunities to engage in real time—which can be recorded and re-used later—was a cheat code to cheaply educate our team in the future.
Focus on information, not PM self-congratulation
A caveat: the focus of communications to the company should not be “about what the product team is up to/has accomplished”. That’s self-promotion, which won’t help the company. Instead, you should think of release and roadmap communication as a way to help *other* parts of the company to be successful by giving them the information they need to do their jobs better. For example:
If the Support team knows about how a new feature is supposed to work— and why it was designed the way it was—then they’ll be better prepared when customers contact them for assistance.
If the Sales team knows what features are being launched, why these features will benefit customers, and which customers are likely to care most about the improvements, then they’ll have useful talking points to reach out to hot prospects.
If the Engineering team sees that their work is being publicly lauded inside the company, they may be more likely to forgive you for pushing so hard before a big release! Also, more seriously, a problem I sometimes hear from engineers is that they’re not sure anyone cares about the work that they’re doing. I find that these communications—and congratulatory reply-alls from exuberant salespeople, marketers, and executives—are helpful to remind engineers how much their work is valued by the rest of the company.
If the marketing team has good release notes and a clear roadmap, it will be much easier for them to craft press releases, blog posts, sales training materials, and other communications they need to get leads and to support the Sales team.
And so on. As PMs its our job to ensure that products are successful, and products can’t succeed if the rest of the company doesn’t know about them. So focus on that. Don’t worry about the rest of the company appreciating your work, because if the products are good and customers like them and the company is well-prepared (by you!), then you’ll get lots of appreciation!