Planning for Success – How to Master Release Planning
Release planning can be frustrating, because it’s essentially an attempt to structure something that’s complex and unpredictable.
Sure, release planning provides an execution and phased rollout structure for the product roadmap. It helps you plot out what gets released to the market and when. But the process can also create a lot of stress and confusion among your team and users.
To avoid this, there are two fundamental best practices that I think every product and development team should adopt right away: separate hard and soft launches, and a release train cadence.
I explain these two practices in-depth below, then touch on three follow-up steps you should take after a launch and three common mistakes in release planning.
By the end of this article, you’ll know how to master release planning and see more success with your product.
Release planning best practice #1: Separate soft and hard launches
Release planning is always beholden to the development process, which can be unpredictable. When things don’t come down the pipeline as planned, marketing is left wondering what’s going on (and their budget might take a hit, too).
One key to successful planning is to separate the soft launch and the hard launch for any software release. In effect this is separating the project management of the app release from the project management of the marketing release.
Here’s how it can go:
During the soft launch, a function is built and deployed behind a feature flag, available for a few users only. Marketing is informed and can select some favorite users, maybe a beta group.
These select users test the feature and ensure it’s working. Bugs come to the surface (and fixes are deployed) before any official announcement and before your entire user base starts fiddling with it and filing customer support tickets.
In the meantime, marketing can plan an official release—the “big bang” release—which might involve a new landing page, email campaign, or plane in the sky.
When the time comes, the “hard launch” of this feature is just a matter of pressing a button to remove the flag in the app. And marketing knows they can confidently move forward with their side of the plan.
Release planning best practice #2: Adopt a release train cadence
When a train comes every 20 minutes, you’re less stressed about missing it than if the train comes once every two hours. The same is true in release planning.
The release train process sets a frequent pace for routine software releases, prioritizing development work over deadlines. Whatever development work that’s 100% ready will go out. If you miss one, no biggie! There’s another release coming up soon. This week’s release might be just a few bug fixes, next week’s might be huge features.
Continuously releasing in this “train” method is a great way to:
- simplify your release planning
- ensure better quality code
- and take the pressure off pretty much everyone.
When releases are less frequent, developers might rush a specific project so it makes the release date, for fear of getting in trouble. They’re under tight (and often arbitrary) deadlines with high stakes, and that’s stressful! This leads to lackluster code and technical debt.
Instead developers should approach their work thinking, “Let me get this to a quality that satisfies the requirements with good code.” With the release train cadence, developers might spend a little more time and deliver stuff they’re proud of. If the feature doesn’t come out today, that’s fine. It will come out tomorrow.
As for cadence, the more frequent, the better. The quicker the pace, the less pressure on each individual task, developer, and release. This could be every day, every week, or whatever is reasonable for your team.
With this method, your product is constantly getting better and it’s no stress for developers or users.
3 steps after a release goes live
Successful release planning doesn’t end with the launch. Just like in baseball, basketball, and golf, follow through is important if you want to hit your target outcome.
These three steps are my recommendations to ensure not only a smooth product rollout, but also a healthy work culture where each person feels their time and effort are valued. Taking care to touch base and show appreciation are key to a high-functioning, happy team—both within product development and across the company!
1. Communicate the release
Writing good release notes is important, but at the same time, you should expect that people won’t read these. Especially if you’ve adopted the release train method mentioned above, no one will look into the constant updates.
Instead, have a place where people can subscribe to key product updates via monthly email, in-app notification, or whatever suits your product. Simply provide some kind of notification or bulletin that reports on what people care about, not every little thing you’ve changed. Or you could give users varying subscription levels: do they want to know about everything, just the important stuff, or nothing at all?
2. Close the loop on requests
Track what people ask for, so that when and if it’s built, you can circle back and let them know! Getting back to someone, even 6 months later, can be really powerful. This especially helps to re-engage teammates in the product development process. People feel heard, and they trust that their feedback is valued. ProdPad has this functionality, and we call it Closing the Loop. It’s a key part of getting qualitative feedback on whether you solve customer problems and essential for measuring success.
3. Celebrate!
Celebrating small wins also applies to release planning. It doesn’t need to be anything fancy, just a moment to recognize the team’s efforts and what you’ve accomplished together for your customers. At ProdPad we post them internally and for users in dedicated Slack groups.
3 common mistakes in release planning
In the first section, I already went in-depth about the mistake of tying release planning to development planning. Finally there are a few other mistakes that many product teams make, all with the best intentions!
1. Making promises of launch dates to customers
It’s really tempting to tell a customer that a much-desired feature will be ready on X date, especially if the customer is particularly high value or the team is under pressure to reduce churn. But the reality is that you can never be 100% sure… and as I mentioned above, strict deadlines lead to crappy code.
Then, if you miss the deadline, the customer’s expectations aren’t met again. They complain, and the cycle continues. Find a way to avoid calendar talk with customers, while still reassuring them their feedback is heard. It can be tricky, but we’ve found some bulletproof ways of telling customers “No.”
2. Prematurely committing time or scope to any release
In project management, there’s a concept called the “iron triangle.” It represents the limited resources of time and money, and how those affect the scope of the project (and vice versa). When one element is squeezed or maxed out, then other parts break.
With product releases, more often than not, quality gets squeezed. And this is how you get technical debt. Developers launch crap after crap and then two years later, they quit (the stressful launches might have something to do with it), and the entire codebase needs to be rewritten. Every company does it!
3. Relying solely on release notes
Relying in release notes to communicate updates and launches to the rest of the company. This information is too important, and it’s a PM’s job to disseminate it well. We have a few tips about communicating new features to business-facing teams. Find methods that work for your organization and team culture.
For more thoughts on the subject, learn how to build a release plan that everyone understands.
For more thoughts on the subject, learn how to build a release plan that everyone understands
Sign up to our monthly newsletter, The Outcome.
You’ll get all our exclusive tips, tricks and handy resources sent straight to your inbox.