This book describes a useful process for creating a product roadmap. The key idea is that roadmaps should not be about specific features. Instead, they should be for aligning vision, objectives, and the themes that are necessary to meet those objectives (with high level time frames). This high level view allows teams and their stakeholders to agree on general direction without committing to specific features (and getting caught up in endless discussions of timelines and technical feasibility). Specific features are important, and separating them from the roadmap makes sure that the features are developed in the context of the product goals and do not become the ends.

Since the terms vision, objective, and theme are used in different ways across different processes, it is worth defining them briefly. The product vision is why the product exists at all. This includes who the product is for, what they need, and the value that the product provides to meet that need for that customer.

In particular, a vision is not a business objective. Selling a certain number of units may be a valuable and necessary business objective, but it does not say why the product exists for the customer. Defining these objectives is the second important part of the roadmap. Business objectives describe what needs to happen for the product to successfully fulfill the building and get customers to adopt the product. It is important to have metrics, also called key performance indicators (KPIs), which define whether or not those objectives are being met. Paired together this maps cleanly onto the Objectives and Key Results (OKR) framework that many companies use. These objectives and their KPIs should be focused on outcomes, not outputs. That is, they should be focused on the value that is being provided, not the specific means that are being implemented to try to achieve those objectives.

Themes define what would need to be true to meet the vision and the business objectives. These are, in essence, the smaller customer needs and problems that add up to the larger goals. One way to think of themes is to think of them as what you get if you work backward from the vision one or two steps. Themes define problems that need to be solved and not the solutions to those problems; the roadmap is about direction, not features. If a vision is large enough, it may be useful to divide themes into more granular subthemes, but more layers than that probably means that the team is trying to do too many things.

The authors give an example of a garden hose where the vision is perfecting lawns by perfecting water delivery, one of the themes is indestructibility of the hose, and a subtheme is no leaks. The vision makes it clear what value is being delivered for users. The theme indicates a requirement for achieving that vision. The subtheme describes a significant element of fulfilling that requirement.

The chapter on developing themes shared a really useful tool for connecting themes to development: the opportunity-solution tree (discussed in more depth in this article by Teresa Torres -- see the image at the end of the article for the tl;dr). The opportunity-solution tree has an objective/desired outcome at the root. Its children are the different themes/opportunities. The children of each theme are the different features/solutions. Each feature has as children a number of experiments to help determine exactly how it should be executed. What I like about making this tree explicit is that it forces every experiment and every feature to relate back to an objective and, ultimately, the product vision.

The rest of the book goes into these elements in more depth and discusses when and how to discuss specifics like features and detailed timelines in relation to the roadmap. It also discusses things like getting alignment and updating the roadmap. In my opinion, the second half of the book felt a bit padded, hence the lower review. The alignment chapter is a good example. There is nothing there that is specific to roadmaps and what is there is fairly generic. ( )