Products don’t exist in isolation. Instead, they are often related to other products, which they help sell or they share features and components with. Think, for instance, of the Microsoft Office suite or the iPod product line. If your product is part of a family, then you will benefit from a portfolio roadmap, a plan that shows how the products are likely to grow together. This post introduces such a plan, the GO Portfolio Roadmap, and it describes how this roadmap can help you manage your product family.
The GO Portfolio Roadmap
Portfolio 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 Roadmap
Let’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.
Post a Comment or Ask a Question
10 Comments
Hi Roman,
I am looking to implement the GO Portfolio Roadmap framework in a new digital platform and have a few questions:
Best,
Chris
Hi Chris,
Thanks for sharing your questions. To find the right answers to your questions, I recommend that you read the following articles:
The GO Product Roadmap
The Product Roadmap and the Product Backlog
The Product Roadmap and the Release Plan
Hope this helps.
This is really helpful, thank you.
How would you display/highlight any dependencies please?
Thanks
Thank you for you feedback and sharing the question Sophie. If you want to make the dependencies explicit, try the following: Create a new row called “Dependencies” to describe a depency the training app might have on beach body app, to stay with the example given in the article. Alternatively, visualise the dependencies with (annotated) arrows assuming that the tool you use supports this. Hope this helps!
Hi Roman, I’m working to define a portfolio roadmap where there are multiple business initiatives with deadlines affecting multiple products at the same time. An example might be an initiative to implement a new business process with a deadline that ultimately involves changes or new features across a host of existing products and another initiative to implement a new business process that affects the same products but involves different features or changes to a shared data model. How would you show this?
Hi Lorna,
Thanks for sharing your question. I suggest you simply add the new or changed features to the appropriate lines/products on your portfolio roadmap. Please bear in mind, though, that the features should serve a goal on a goal-oriented roadmap.
Does this help?
Hi Roman!
If we have an overarching Company Vision/Strategy and 2 or more teams that each are responsible for individual products, do we create a vision/strategy for each team’s products in addition to an overarching product vision/strategy? I’m confused. 🙂
Best
Matt
Hi Matt,
Thanks for your question. Generally, I recommend creating a separate vision and strategy for each product, unless you work for a startup. The company vision should guide the product visions, and the business strategy should direct the product strategies. I describe the relationships in more detail in my book Strategize.
Hope this helps!
Hello Roman,
I find the idea with Portfolio board great. Though I think of applying it to different features of the big Product but not products. We have several feature POs. Each of them works with stakeholders and cares about requiements for the feature (feature Vision Board, prioritizing of backlog for feature, etc.). At the same time we have a POs meeting, where we are going to make a global prioritizing. We do not have PO of POs – we are altogether should do a final decision. Of course there is information about the company strategy and goals. This should serve for global prioritization. This is the idea. For this pupose Portfolio Board could be useful.
What do you think about this usecase?
It would be very interesting to hear your opinion about this.
Hi Natalia, I recommend revisiting your notion of what a product is along the lines I discuss in my article “What is a Digital Product?”. If you are dealing with one product, then this product should have one product strategy and one Product Vision Board. Does this help?