Thoughts

Book Summary: Product Roadmaps Relaunched

A Project Manager's book summary on product roadmaps and how they can be used as a strategic communication tool.

by Ian DiBruno

At Promptworks, we often build early stage applications and programs to help realize a vision for our clients and ultimately serve their end users. While every solution starts off as an idea, ideas are cheap - and it’s all about how they’re executed. As a Project Manager, along with my teams, I bear the responsibility of thinking strategically about the end users, their problems, and the outcomes they seek alongside the business objectives of our clients. Enter Product Roadmaps.

The Book: "Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty"

Authors: C. Todd Lombardo, Bruce McCarthy, Evan Ryan, Michael Connors

This book was recommended to me by a fellow Product Owner who is a few years ahead of me in their career. Product Roadmaps Relaunched positions a product roadmap as a strategic communication tool that can assist in aligning internal and external stakeholders for a given project.

What I loved about this book is that the authors prescribed a specific methodology and step by step process to building a roadmap while also acknowledging that there is no template, and that each roadmap will vary depending on the surrounding market and audience at a given time. I still refer back to my notes when creating roadmaps and have included a lot of the detail below:

Primary Components

All roadmaps should included the following:

  • Product Vision - How will customers benefit from your product once it is fully realized?

The product goals or vision state the impact that your product will have on the world and aligns your development with product strategy. For example, Google’s mission is “to organize the world’s information and make it universally accessible and useful.” This statement should be the north star for your business and should be displayed as the backbone of your roadmap.

  • Business Objectives - What goals will your product accomplish for your organization?

Getting clear on how this product will drive business success is critical. Setting up measurable goals will help provide the product development team the context they need to guide prioritization. The authors endorse using the OKR framework (more detail on this framework in my next blog post).

  • Timeframes - Time signifiers such as Now > Next > Later provide for roadmap flexibility while still giving the audience an idea of when work will be delivered.

Promising delivery of a product or feature on a specific date before requirements are properly gathered rarely sets the team up for success. Using time frames within your product roadmap will usually satisfy the key stakeholders while giving the team some buffer time to get the job done right.

  • Themes - The key customer needs. These are provided in lieu of specific features or solutions, leaving room for the team to determine HOW they’ll serve these needs during execution.

Taking the time to identify user goals, tasks and outcomes before implementation can save a lot of time, money and frustration once development begins. These themes summarize the value to be delivered to the user as opposed to specific features.

  • Disclaimers - Nothing like a little C.Y.A. cough cough (I MEAN expectation setting) for the audience!

Secondary Components

Optional secondary components include:

  • Features and Solutions - If common or specific features are known, include them. These may be known for the immediate next time frame, but left out in subsequent time frame periods.
  • Product Stage - This should indicate the maturity of the product. "Discovery" or "Design" indicates that stakeholders can still have input while stages like "pre-production" and "beta" signify the product can be touched or interacted with.
  • Confidence - Indicating level of confidence in your ability to address roadmap items. If you feel adding confidence will provide clarity to your stakeholders, add it.
  • Target Customers - If you have several distinct user types, calling out the target customers for specific items on the roadmap will help stakeholders understand.
  • Product Areas - Larger products can have different areas which might be worth highlighting on a roadmap.

These secondary components should be leveraged as needed. The authors also provide context as to when they might be used.

To see how all these components fit together, here’s an example of a roadmap:

Figure 2-11. The Wombat Roadmap with some secondary components added.

After laying out the components, the book goes into detail on how to gather the information needed to prepare each component described above. One thing to note is that a complete product roadmap is a result of a lot of up-front work and planning. Coming up with a solid product vision, market strategy, business objectives and well thought out user needs are each their own work efforts that are significant.

As you can see in the roadmap for The Wombatter Hose, there is not a ton of information included on the final version of a roadmap. This is intentionally simple for the audience to be able to consume.

To make sure you include the most important details in your roadmap, the book gives a brief crash course on several prioritization methods. I’ll spare you the details of each, and let you research each of these roadmap methods on your own: Critical Path, Kano Model, Desirability/Feasibility/Viability Diagram, ROI Scorecards, MoSCow framework.

Conclusion

To close, Product Roadmaps are especially valuable for new products or product concepts that are unproven and need some structure or direction. Their sole purpose is to unify teams and provide clarity on what will be built and are backed by careful planning. I hope this summary and example will help in creating a roadmap for your new groundbreaking product!

Stay tuned for my next book summary on Measure What Matters by Job Doerr covering OKRs.

We'd love to keep in touch!

Opt in for occasional updates from us. Privacy Policy