Photo courtesy of Pexels

The GO Portfolio Roadmap

Published on 22nd September 2015

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.

The-GO-Porfolio-Roadmap-Template

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

  • Chris says:

    Hi Roman,

    I am looking to implement the GO Portfolio Roadmap framework in a new digital platform and have a few questions:

    1. What is the best digital platform for a GO Portfolio Roadmap?
    2. Would the GO Portfolio format work with columns that relate to months or agile sprints instead of quarters?
    3. What happens if it is not possible to complete a feature within one of the columns and then you need to adjust all future columns?
    4. Is there a way to drill down into the features so that progress and product requirements can be viewed in more detail?
    5. Is there a way for the actual metrics to be dynamically populated to complement the desired metrics?
    6. How do product managers own a swimlane in the roadmap if all their initiatives relate to multiple products within the portfolio?
    7. Do you use a delivery plan to complement the GO product/portfolio roadmap?

    Best,
    Chris

  • Sophie Olyphant says:

    This is really helpful, thank you.
    How would you display/highlight any dependencies please?
    Thanks

    • Roman Pichler Roman Pichler says:

      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!

  • Lorna says:

    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?

    • Roman Pichler Roman Pichler says:

      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?

  • Matt says:

    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

    • Roman Pichler Roman Pichler says:

      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!

  • Natalia says:

    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.

    • Roman Pichler Roman Pichler says:

      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?

Leave a Reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.