Product Release Plan
There is a great book called Manage It!, by Johanna Rothman. She does not disappoint, and really gets into the nitty gritty details about managing projects. While this is billed as a “project management” effort, it really does apply to product managers a great deal.
One of the things Johanna discusses early on is some of the tools she uses to define her projects - a project charter and a project release plan. While I believe both of these are valuable, I couldn’t stop hearing the “it’s just too much documentation” argument in my head. Would people refer to the charter for details, or the release plan? While I understand the difference on the majority of counts, I wouldn’t expect everyone to - even in the smallest of organizations.
So, I took what Johanna has detailed out as her two templates (the charter and release plan) and created a Product Release Plan template. Hopefully, this would become part of your PRD, and be refined as necessary for each release. There are some critical elements that are called out in the book that I have included, and they are pretty clear why.
That all being said, here is the template:
- Release Theme
- Release Requirements
- Release Criteria
- Release Goals
- Schedule Overview
- Risks
I’ll cover each of these points separately with a brief overview.
Release Theme
This should match to the release detailed on your roadmap. As I discussed in a previous post, creating theme-based roadmaps has a big advantage, and delivers a lot of clarity about a release without getting into “feature this” and “feature that” and scheduling.
Release Requirements
In her book, Johanna points out that each project should ideally have 1 driver, 2 constraints and 3 floats. The “driver” is what the project is absolutely dependent on - it’s the most critical thing. For example, it could be the release date, or the feature set, or a low number of defects.
A constraint is the second most important thing. The project isn’t 100% dependent on it, but it’s still pretty damn important. Floats are those items that you have more flexibility in managing. IE, stakeholders aren’t going to lose sleep if they aren’t delivered.
Release Criteria
These are the things that will mean the release is ready to ship. For example, is there a certain number of SEV-1 defects that need to be resolved? What about hitting a certain timeline? Maybe a specific set of features need to be met? Those points are all factored in there.
Release Goals
Goals are not requirements - they are items that would be ideally completed along with the release. For example, “making the performance of feature A 10x better than what the requirement states” or “adding a brand new set of smoke tests into the automated testing process of the product.”
These goals could be broken down into specific sections, such as product goals, team goals, project goals, and organizational goals. I’d stay away from trying to be too detailed here - especially on your first pass through a document such as this. It’s more important to get the key things down up front and make sure the team is executing and delivering on requirements first.
Schedule Overview
One of the methods Johanna states in her book for scheduling is called “top-down.” I prefer this method to all others, since it involves setting milestones first, and working out the details for each milestone from there. This is much more conducive to successfully planning releases from a roadmap, since the roadmap itself is a high-level set of milestones.
Jot down the milestone name and the estimated date for its completion in this section.
Risks
Risks can be difficult to identify clearly. However, they are very important to have and be aware of throughout development to ensure the proper mitigation actions can be taken. Within this section, identify each risk, the probability of it occurring, its severity if it did occur, the date at which you are most at risk for it causing problems, and the action being taken to resolve it.
I believe that most of these will be identified by the development team. However, because a product is much more than just code, if there is a marketing risk it should be identified here as well. For example, “a relationship with a PR firm may not be in place in time to get the press release done and out prior to the ship date.”
