Roadmaps and Release Plans
Roadmaps, release plans, gantt charts, project plans, kanban boards, sprint plans. The list goes on and on. Over the years, the tech industry has used all of these and more to help plan the work, communicate the work, and deliver outcomes. The problem is that all of these different methods are still around and tend to overlap quite a bit which results in confusion surrounding definitions, ownership, and the goals of each of these different planning methods. For the purpose of this article, I’m going to focus on roadmaps and release plans which might seem very similar but hopefully we can tease apart the intent of each document.
Roadmap
The roadmap is arguably one of the most important documents the product manager produces. The product roadmap conveys the strategy describing how the product aims to achieve the product vision.
“The product roadmap conveys the strategy describing how the product aims to achieve the product vision.”
One of my favorite ways to present a product roadmap is to use the “Now, Next, Later” method. This approach allows viewers of the roadmap to focus on the plan and direction of the product versus focusing on output, features, and dates. I also like to add an “Evaluate” column where new concepts that are not necessarily ready to be committed to yet can be listed. Please note that the usage of the “Evaluate” column really depends on the culture of your organization. There are some groups that only want to see items on the roadmap that communicate commitments, while other groups enjoy seeing what new concepts are on the horizon.
While the product manager does own the roadmap, they do not build it by themselves but rather utilize stakeholder collaboration, discovery, and analysis techniques to put it all together. The roadmap shows the outcomes the product will deliver, which strive to solve problems the product manager uncovered during discovery. Due to the evolving nature of products, the roadmap is never set in stone. This means that the product manager will need to revisit and update the roadmap as new information is uncovered and/or priorities shift.
Release Plan
You might be wondering how to take the roadmap and convert it to actual work items that are fully scoped. The answer is through the use of a release plan.
While the roadmap communicates what problems need to be solved, the release plan focuses on how the problems will be solved and delivered. The release plan is generally owned by the project manager on the team. The project manager works closely with the product manager to understand the roadmap outcomes and the team works together to identify solutions that aim to achieve those stated outcomes. The development team will work together to scope out the effort and note any dependencies or roadblocks that may arise during development. The project manager gathers all of the input and builds a release plan that communicates the output the team will produce including projected completion dates (which should follow the prioritization identified in the roadmap).
Wrap Up
Regardless of how your organization approaches roadmaps and release plans, the main takeaway is that there needs to be a document that describes the outcomes your product aims to achieve as well as a document that breaks down those outcomes into solutions/features with corresponding delivery estimates. These documents are never final and should be updated as learnings and priorities change. Roadmaps and release plans each have their place in the product ecosystem and they address different needs in order to achieve the product vision.