30 Aug 2021
Avoid the Punch: How to Create an Effective Release Plan in an Outcome-Based World
Product ManagementMike Tyson, arguably the most formidable boxer of all time, said my favorite quote that I find consistently relevant for product management.
He was asked if he was worried about his opponent’s fight plan.
He responded with “Everybody has a plan until they get punched in the mouth.”. It’s a more pugilistic take on the old adage “No plan survives first contact with the enemy.”. You can easily apply it to Product Management via the often misunderstood and maligned Release Plan.
“Release plan?” you might think. “I can’t worry about that! I’m too focused on outcomes!” And you would be right!
One of the most critical things to consider is whether such a concept can function in an outcome-based world.
When your roadmap avoids dates, why would you put together a different document that is entirely oriented around them?
Quite simply, your release plan (and its contents) is the best way to avoid getting “punched in the mouth” by surprise delays, regression issues, production bugs, and stakeholder confusion.
The product team needs a “roadmap for the roadmap,” meaning a tactical way to get from the vision to reality.
And though a release plan is typically an internal document for the product team, you can easily communicate relevant parts of it cross-functionally if you have stakeholders that need to be looped in.
The Foundational Release Plan
What is a release plan? Exactly! In the simplest possible terms, it is the “what” to your roadmap’s “why”.
A good release plan contains the tactical outline of the features, enhancements, bug fixes, and technical debt resolutions needed to bring the outcomes from your roadmap to life. Some examples of what should go into it are below:
What specific actions need to happen to execute the roadmap over a period of time?
When will each action need to happen to release on time?
What release on what date(s) will contain each enhancement or feature that rolls up into a roadmap outcome?
What do the test plans and QA action items look like for each release?
In more complex terms, it is a blueprint for execution of your vision.
With a release plan you make your abstract roadmap vision concrete by assigning and clarifying a clear set of tactics to execute.
Typically, it contains 9-12 weeks of planning to your roadmap’s 9-12 months (or more). In it, dates correspond to your typical sprint cycle.
For example, if you have two week sprints with a release at the end of each one, then your release plan should be organized in two week increments like this Agile release plan example.
However, as you can see, there is no link back to the roadmap itself, and no reference to any outcomes. It is simply a laundry list of features corresponding to sprints.
Unfortunately this causes it to exist on an island, when it is possible for it to be more of a peninsula!
The Best Laid Release Plans
While an Agile or scrum release plan is a good starting point, it is typically best to figure out a way to make one that works for your specific team, then create a template in such a way that is extensible and flexible.
If you are an outcomes-based team with an an outcomes-based roadmap, then you need an outcomes-based release plan as well.
And if you buy into the Cagan Empowered Product Team philosophy (like I do), then you, the Designers, and the Engineers should want everything linked back to the outcomes in your roadmap, including the specific steps in your release plan.
So what needs to change to make a release plan outcome-based?
Fortunately, not much!
You can use the same template that functions as a standard project plan, but there should be references back to what outcomes each release supports.
It can still contain your feature-specific testing outlines, the release dates, the expected features and enhancements to be released, etc. but all items should be clearly traceable back to a strategic outcome as defined in your roadmap.
It could be as simple as adding a column to indicate which outcome the feature in question supports.
If You Fail to (Release) Plan...
A release plan avoids many of the pitfalls inherent in bringing software from staging to production (and often from development to staging!).
Because it contains specific action items, dates, and owners, you have a “throat to choke” when delays crop up, which can then be specifically addressed in your retro.
Similarly, you should have all testing tasks (both regression and new feature) outlined in there, also with timelines and owners.
Do you have stakeholders (CTO, CRO, CMO?) that need to be briefed on each release with sales scripts, product briefs, one-sheeters, etc?
You should be baking these items into your release plan with YOU, the product manager, as the throat to choke!
Ultimately the release plan is another artifact we as product managers produce to communicate cross-functionally more clearly.
You arm yourself with information for your stakeholders that you can access on-demand.
Meanwhile, your team has a clear path for success with expectations and assignments documented and visible to all. It is a fantastic tool to add to your collection when you find your releases going off track!
Adam Hecht
Read also
Experience the new way of doing product management
