The following blog post summarizes the first chapter of the Product Roadmaps Relaunched book by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors. Published on November 28, 2017. The first chapter is reviewed and summarized using my best judgment of the most essential information.
It is common for teams to treat their roadmaps like a project plan; where the roadmap made is treated as if it is set in stone and due to be completed by a specific date. But this is very often not how the plan works out.
Additionally, in this day and age, it is vital to stay flexible and accommodate uncertainties and changes that come your way. In addition to accommodating changes and uncertainty, as product managers, we must ensure our product roadmaps continuously serve and satisfies our company’s mission, vision and strategy.
Having a focused and flexible roadmap allows us to do three key things:
- Firstly, it will enable us to communicate the value our roadmap plan will deliver, not the features. Although features have a time and place in your roadmap and are discussed later in the book.
- Communicating value that will be addressed on your roadmap allows you to present a plan to your customers who do not commit to specific deliverables or deliverable dates while still engaging and exciting your customers around the following things that are coming for your product.
- Secondly, we can leverage our roadmap to align the teams within our companies around the vision and mission.
- Connecting our roadmap plans and our vision and mission will clarify to internal stakeholders why certain items are on the roadmap and important to address.
- Lastly, much like the previous point, this will also allow us to coordinate our team efforts and the priorities outlined within the roadmap as they change to accommodate market needs.
- This will also help us gain buy-in from internal stakeholders and help everyone understand the importance of all roadmap items, leading to a more engaged, successful team.
On the flip side, it’s also important to understand what not to do with your roadmap:
- A roadmap should not be confused, compared to or interpreted like a project plan. It is crucial to keep the two separate to ensure proper expectations are set with internal and external stakeholders during the roadmapping process. It is also important that internal teams focus on delivering outcomes, not outputs.
- As previously mentioned, your roadmap should not promise deliverables. This will only lead to disappointment for your internal teams (sales teams promising deliverables that may not be realistic, development teams being set up for unrealistic timelines) and external teams (stockholders, funders, customers, etc…).
- A ton of time should not be spent estimating the amount of work it will take to accomplish a particular solution. There are many facets to this point that are addressed later on in the book. But, the most important points are the following. Firstly, the time spent estimating is better spent doing. And when presenting value on your roadmap as opposed to features, you may not always know what the solution will be, and it is therefore challenging and wasteful to estimate.