Every single person who has ever been involved with building and delivering a product has suffered the inevitable heartbreak of creating something great — maybe even better than great — and then a few weeks or months later realizing very few customers are using it, and even fewer like using it.
Sure, sometimes this kind of failure can be chalked up to a terrible idea that never should have left the digital paper it was hastily sketched out on. But other times — a lot of the time in my own experience working with startups and other product innovators — it happens not because of a bad idea, but because of a great idea executed poorly.
You can’t fix this once it happens, or it’s at least extremely difficult and usually not worth the effort. But an ounce of prevention is always worth more than a pound of cure.
If you don’t have the bare bones of a companywide release management process in place, stop everything you’re doing and create one. Don’t wait for that next brilliant idea to die on a vine of apathy.
Here’s how to get started delivering great products to grateful customers.
Release Management Is Not Just For Engineers
I hope I haven’t lost the non-engineering or non-software-development crowd just yet. When I talk about release management to the technical folks, I’m preaching to the choir, in that it’s rare that I find tech teams who haven’t put a lot of thought and machinery into documenting the build path from low-level code to high-level end user.
But have you ever read the documentation they produce? It doesn’t stray too far from the technical language they’re all used to. It certainly doesn’t speak to your customer, or your marketing, or your revenue. And so that documentation rarely, if ever, gets to the end user. It usually just winds up sitting on a Confluence page somewhere that never leaves the view of the development team.
(I can almost see you builder types nodding in agreement.)
But proper company-wide release management isn’t just about creating more digestible documentation, it’s about getting the information contained in that documentation into the minds of every contributor along the chain from code to customer in a way that encourages understanding and, hopefully, engagement.
Don’t burden your hardworking engineers with this monumental task.
Create a Constituency of Product Engagement
The first and most difficult task is finding the right champion at each point in that code-to-customer chain. In an ideal and simple world, that chain looks like this: Build → Product → Marketing → Sales → Operations → Support → Customer Success.
That can break down to any number of teams or departments or even people, and in smaller companies you’re going to have a single person champion two or more of those areas. Regardless, those are the conceptual steps any new product or new feature release should take.
If you have a product team, the leader of this team should have responsibility and accountability for disseminating information down this chain, even if they might not have a hand in creating any of the documentation or delivery process along that chain. Those tasks are usually best left to the champions themselves, with your product leader designated as translator from engineering across to the various teams.
If you don’t have a product team, this responsibility is best left to the CEO or COO. It’s that important. (Don’t leave it to the CTO. Their job is to build great things, not explain them.)
Each champion in that chain should be able to take the release notes from the builders and work with the product team to create the basic informational structure pertaining to how the new product or feature impacts their own goals.
- For marketing, it’s “How do we introduce this?”
- For sales, it’s “How do we sell this?”
- For customers, it’s “How does this help us do what we need to do?”
Not: “Welcome back customer! Here are the developer release notes for you to ignore real quick!”
Don’t Create Chaos and Noise
If the biggest mistake in release management is not having it, the second biggest mistake in release management is having too much of it. Or rather, it’s throwing documents over a wall and expecting the end user at each point to engage with it.
Beyond the task of just translating what the new build means for each constituency, your champion also needs to figure out how to make it stick. In other words, if you throw everything onto a release wiki, even one for each department, you are ensuring that it never gets accessed or engaged with. It just becomes another email notification to delete.
Each area or team within your company should develop a release management process that gets the right information to the right people — and ensures they only get what they need to know in a manner that compels them to engage with it.
For example: Your support team doesn’t need to know how a bug got fixed, only that they can immediately assure customers it won’t happen anymore.
These champions are also going to be your first line of feedback, long before the impact of mistakes are felt by your customers. They’ll also be the front lines of opportunity, giving you insight into how each new build increases your ability to reach a broader market.
Release management is a companywide exercise, and when done right, it creates efficiencies that maximize the impact to the top and bottom line of the company for each new product, each new feature, even each new bug fix.
Start a solid release management process now, and you won’t just be delivering new features perpetually, but you’ll be delivering great features perpetually.
