In my experience, I have seen and created roadmaps on the portfolio level (for many products). In some organizations, we did visualize all existing products. In other companies, products were shown for a specific department. Nevertheless, multiple products were visualized as a common roadmap.
Some reasons to use this type of roadmap
This approach might be considered regardless of the situation and generally helps, but you might take a closer look if an organization:
- Suffers from the lack of transparency on a portfolio level (and a product, too!).
Some products have their Product Goals and explicit outcomes, while others do not. - The potential of a product and desired customer experience are not clear and transparent (there is a lack of defined Unrealized Value).
- Investments in products, these decisions are not transparent and lack clear justification.
- When a business strategy is not reflected in product strategies and respective goals, you might look for alignment.
- Think about your organization. Here is a place for your reason I have not mentioned!
Benefits
Showing all current products in one picture helps in seeing needed investments or pausing them. This kind of roadmap embraces uncertainty and welcomes discovery and experimentation.
Also, a portfolio-level roadmap can assist with seeking alignment on a business strategy and strategic goals. It gives an overview.
The most essential part is transparency created around Product Goals and customers’ outcomes across multiple products.
Ideal for inviting high-level stakeholders to discussions.
Template
The following is an example roadmap to use at the portfolio level with multiple products. I have created this template based on real-life situations I experienced in several organizations.
Premises: All products are defined by the customer’s desired outcome and are Product Goal oriented. A roadmap is updated frequently as they learn more. (Usually, I did updates biweekly or monthly, depending on organizational needs).
Some products have question marks as placeholders because of the high uncertainty in the future. Once more knowledge is learned, the teams can add their Product Goals, experiments and measurements.
Your situation
Take a look at this example. Try to answer the following questions:
- How might this roadmap work in my environment?
- How would it help us make better product decisions and uphold stakeholder transparency?
- What do I need to do to implement this in my organization?
- How would you start a conversation with stakeholders about creating such a roadmap?
Final thoughts and tips
- Portfolio Product Roadmap does not replace Product Backlogs.
- It is not a project or program plan for a longer period.
- Product Roadmap at a portfolio level should embrace uncertainty, reflect reality, show products potential and help with decision-making.
- You can adjust this roadmap according to your situation and products but do not remove Product Goals and customer outcomes. You might easily lose customers’ perspectives, problems to be solved and needs. Do not fall into the trap of feature factory/delivery, which I call Featurosis.
- You might add more details, like measures, but I do recommend keeping it simple. Too many details might blur Product Goals and outcomes.
- Remember to revisit with Product Owners and stakeholders periodically. I prefer when Scrum Team members are also involved in updates.
- I do not recommend creating plenty of meetings around it. Keep it short and well-facilitated. Too many, too long meetings discourage people involved and we can lose their engagement and attention.
This blog post was entirely written by a human (me), not AI, reflecting my real-life experience with organizations.
Special thanks to Patricia Kong and Glaudia Califano for encouraging me to write this article.
