Let me know if this sounds familiar. Your team delivers an amazing new product feature that customers have been demanding for months, then nobody uses it. Or they use it incorrectly. Or they complain that it doesn’t work like they wanted.
Key Steps for a Great Product Release
- Create dedicated customer-care and engineering release-management teams.
- Include sales, marketing and finance in communications.
- Include HR in internal communications.
- Tailor support documents to different types of customers and their needs.
Most of the time I see this scenario play out, especially with startups, the mistake isn’t in the build, it’s in the delivery.
Or lack thereof. Let’s fix that.
Release Management in a Nutshell
Releasing a new product or a new feature to a real customer market isn’t all that difficult anymore. This is especially true with software and digital products, where “release” has evolved from an overnight multi-hour process to a button push and an automated warning to customers to refresh their screens.
Even with hardware and physical products, changes that used to take months to cycle through a manufacturing process can now be done in days. It’s just a matter of when you want that new version rolling off the line.
That doesn’t mean release management is just as simple. It’s still a convoluted process that gets misconstrued and ignored more often than not.
I’m not talking about user acceptance testing and production scheduling. I’m not even talking about customer notification and awareness. Most companies, even startups, already do this.
I’m talking about stepping all the way back to the reasons why you adopted that new feature in the first place — the benefits it brings to your company and your customers — and making sure those benefits are immediately presented, and more importantly, absorbed and understood by each party in your delivery chain.
This requires much more work than attaching developer release notes to an email. But because startups are always hell-bent on two-week agile cycles and continuous improvement, they tend to rush through anything outside of passing that improvement along and saying, in effect, “Here, this is what you wanted.”
Having founded several of my own startups and worked for dozens more, I know why this happens. Much like how dedicating time and resources to building a coherent, goal-based product roadmap can put a major damper on a startup’s velocity of production and sales, the same effort put into release management can turn those two-week delivery cycles in two-month delivery cycles, with a big mess of unread documentation strewn across the company and its customer base.
It took me about 16 months to spin up a working, efficient release-management model at the fast-moving VC-backed startup where I’m head of product. I’m not done quite yet, but I haven’t slowed down our velocity at all. In fact, I’ve sped it up in places, by increasing engagement inside and outside the company, reducing mistakes and rework and generally improving the understanding of what we do and how it hits our customers and prospects.
This is what release management is supposed to do. So let’s take a deep breath and do it right. In this post, we’ll start with defining the chain of delivery.
Address Every Link In the Delivery Chain
As a customer of dozens of software products, every time I see developer release notes thrown at me in a pop-up when the vendor releases a new version of the software, I shake my head right before I click it away without reading it. This is because what I need from the new release is not what the developer intends. A bunch of translations need to occur along the way. And the first translation is the responsibility of the product team.
When I decided to get serious about release management, I began by having a weekly meeting with the lead engineer or our core product because she was the one responsible for both the delivery of the release and the release notes. This meeting took 15 minutes, and consisted of her and me reading over her notes so I could absorb and understand each new tweak. The only output from this meeting was another weekly meeting of our operations management, where I had two minutes to translate what she had told me so they could absorb and understand it.
This was by no means a solution, but it was the start of structured communication along the delivery chain. It didn’t slow us down at all (a grand total of 17 extra minutes), and it’s where I suggest you start.
Today, 16 months later, we have a fully formed communication strategy for our delivery chain and a plan to begin an automated means of communication. The end result might even be that same customer pop-up I have scorn for, only one that speaks directly to our customer’s needs and expectations.
Your delivery chain is likely different from ours, so here’s the high-level breakdown.
Internal Constituents
Because we build SaaS software with both internal and customer-facing apps, we started out by directly translating and communicating to our internal operations team. Over time, we added B2B customer care, B2C customer care, partner success and internal training teams.
On a side note, over the 16 months as our company matured, we also built a dedicated engineering release management team to formalize the release process on the technical side. This made our information coming in much more robust and frequent, but didn’t change our strategy for information going out.
Internal To Customer Touchpoints
We developed a different model of communication for teams that worked directly with the customer, outside of customer care, which was already more tightly involved. This is sales, marketing and finance. And because our employees are also our internal customers, we included HR as well. While these folks aren’t involved in the week-to-week rhythm, we make special accommodations when they’re affected.
Customers
Of course, your customers aren’t in a direct two-way communication loop like your internal team, so this effort is all about support documentation and that dreaded new-release pop-up window.
Again, we don’t want to treat every customer the same, because the goal here isn’t just about getting the information across to the customer. It’s about the customer absorbing and understanding what they’re getting so they’ll use it to their advantage and succeed.
To accomplish this, I broke down our customer base into four groups.
Engaged Customers. Here we anticipate what they need to succeed and present the information in a way that they’ll use what we’re giving them to meet that need.
Existing Customers. For everyone else, we let them know what we’re offering in a way that will encourage additional engagement.
Interested Prospects. If a prospect is visiting our website, chances are it’s not their first touch. This is information that may go into a FAQ, a knowledge base, or a newsletter.
New Prospects. This is an extension of what we deliver to marketing, detailing how our new features might attract new customers or even a new market.
The Channel and the Message
Now that we’ve identified our constituency for new releases, or the “who” of the process, in future posts on release management I’ll cover what that information should be and how it should be delivered.
