The GO Portfolio RoadmapPortfolio roadmaps come in different shapes and formats. Based on my popular GO Product Roadmap, I have developed the GO Portfolio Roadmap. Both roadmaps are goal-oriented and use goals to anticipate how a product or a product family is likely to grow. The following picture shows the structure and the elements of the GO Portfolio Roadmap. You can download the template for free from romanpichler.com/tools/the-go-portfolio-roadmap/ or by clicking on the picture below. As the template above shows, the GO Portfolio Roadmap combines the roadmaps of several related products into a single plan. The portfolio roadmap is based goals; you create it by identifying the desired benefits the portfolio members should deliver. The goals invite you to describe why it is beneficial to develop the products and the overall portfolio rather than focusing on individual features. I find that goal-oriented roadmaps are particularly beneficial in the presence of change and uncertainty. What’s more, they make it easier to align stakeholders and help create a shared understanding of how the portfolio is likely to grow. Let's take a brief look at the elements of the GO Portfolio Roadmap. The top section displays the release dates or timeframes. It then states the portfolio members, product A and product B. Each product has its own goals, features, and metrics, which are identical to their counterpart on the GO Product Roadmap: Each goal describes the desired benefit a major release should provide; the features are the key deliverables necessary to meet the goal; and the metrics state the measurements used to determine if the goal is met. (For more information on the goals, features, and metrics, please refer to my post The GO Product Roadmap.) You can customise and extend the GO Portfolio Roadmap by adding more products and by including more portfolios with their products.
A Sample GO Portfolio RoadmapLet’s see how the GO Portfolio Roadmap can be applied. The following sample roadmap consists of one portfolio, the Healthy Eating product family, and two fictitious products, the Beach Body app and the Training app. The former is aimed at people who would like to lose weight to look slimmer; the latter targets athletes who would like to improve their performance by adjusting their diet. As the picture above shows, major releases are planned for both products on a quarterly basis. While the Beach Body app has been available for a while, the Training app is a brand-new product. If the latter reuses features of the former and if those features have to be refactored before they can be reused, then the roadmap above contains dependencies. These dependencies have to be managed, and the roadmap may have to be reworked, for instance, by delaying the launch of the training app to Q2. This illustrates one of the main benefits of a portfolio roadmap: It is easier to spot dependencies compared to using separate product roadmaps. At the same token, if your portfolio roadmap suffers from many dependencies, then this may be an indication that the products are not defined appropriately. You may have to unbundle some products and promote their features to new products, for instance; you may choose to do the opposite and bundle smaller products into a larger one; or you may want to encapsulate shared assets, components, or services into a platform (which would then be added to the portfolio). As developing and updating a portfolio roadmap tends to be more challenging compared to a product roadmap, I recommend that you develop a solid product roadmapping practice before you employ a portfolio roadmap. What's more, make sure that the assets in your portfolio are indeed products--not features or components. Otherwise you don't need a portfolio roadmap; a product roadmap will do.
You can learn more about the GO Portfolio Roadmap with the following: