#174 – The Portfolio Product Owner Team

If several of the products in your organization are related or part of the same product portfolio (e.g., because the customer experience spans across them), helping the respective Product Owners collaborate on an ongoing basis can do wonders for your customers.

Typically, the group of POs, each with their own Scrum team(s) and product(s), also collaborate with a high-level PO, such as Chief Product Owner or Product Manager, in a team-like constellation that is called the Extended Product Management Team in SAFe and the PO Team in  LeSS. 

We use the term “Portfolio PO Team” (PPOT) to denote a team of POs whose products are part of the same product portfolio—here, a portfolio can also be a Value Stream. The POs do not share a collective backlog, but rather ensure alignment across their products through continuous communication about the portfolio vision and roadmap. The idea is that, by aligning and thinking of themselves as a team with related products, they can increase their collective value-add across their products.

PPOTs are successful when:

1. The products are actually related in the customer’s eyes

All teams should have a purpose and a raison d’être. For PPOTs, working as a team of POs often helps align the scope and timing of Features of each of the products in order to increase the general customer experience across the products. Therefore, understanding the bigger picture, i.e., the high-level portfolio or capability that a PO’s own product contributes to, helps them better steer their respective product in the right direction through an informed and aligned understanding of what types of Features to prioritize.

Ideally, the individual Product Visions and Roadmaps fit seamlessly into a higher-level Product Portfolio Vision and Roadmap—e.g., by goals on the portfolio level being composed of Features from the product level—enabling the PPOT to interface the surrounding organization as a single unit with a common purpose comprised of individual product value propositions. 

On the other hand, if the products have no relation to each other, are not in the same portfolio or Value Stream, and the customer experience does not span across them, there might not be a need for having a PPOT.

2. The Product Manager acts as a facilitator of alignment and not a decision-maker

Apart from the POs, there is typically also a portfolio-level PO called the Product Manager, Chief Product Owner or, as in LeSS, just plainly Product Owner. No matter the name, in our view, the responsibility of the Product Manager is not to decide on the strategic direction of the portfolio nor the ordering of a high level backlog; rather, it’s to facilitate that all relevant product-level input is shared between the POs, so they all, as a team, and based on their product-level learnings, can set the portfolio-level direction and make sure to develop the right Features in the right products.

This requires other meetings than the typical PO Syncs where the development progress and commitments are discussed, as the PPOT also needs to align on the portfolio vision, roadmap, discovery, refinement, adoption, stakeholders, company strategy, etc.—and if there is a Product Manager, they should drive and facilitate these meetings.

3. The PPOT seeks to reduce the dependencies between its Scrum teams 

The more self-contained the teams are, the potentially lower Feature delivery lead time each team will have, and the shorter the time-to-market of updates to the product portfolio. Our favorite, but also, perhaps, the most difficult approach to building self-contained teams is to invest heavily in removing the dependencies between the PPOT teams, so they become Feature Teams within the product portfolio (or Stream-Aligned Teams within the Value Stream), which will increase the overall adaptability across the teams and, thus, the agility of the product portfolio. 

Conversely, having Product Teams that can only work on their own product inhibits agility if the market demand of a particular product increases, and only one team can work on it. If, instead, all teams can work on all products in the portfolio (or, at least, several teams on several products), ‘swarmability’ will increase on a product portfolio level.

This is, of course, much easier said than done, especially if the technology used across the products are very different (e.g., C# and COBOL). Nevertheless, the Product Manager and Product Owners (as well as the process and technology-oriented accountabilities, such as a Chief Scrum Master/Release Train Engineer and a System Architect) should encourage a mapping and continuous removal of competency and architecture-based dependencies across the PPOT teams.

Do you even need a PPOT?

As this is a type of scaling, have a critical think about whether you actually need a product portfolio. Even though you might already have scaled and are running an Agile Release Train, a Tribe or a Product Requirement Area, ask yourself whether you could descale and make product definitions that do not require more than a single PO to manage the Product Backlog—remember that several Scrum teams can work with a single Product Backlog without any other overhead.

Having a PPOT will also take time away from your POs, so make sure to constantly assess whether your investment in the overhead of running a Portfolio PO Team as well as having a Product Manager / Chief Product Owner is still giving your customers the value-add you are looking for in the form of, e.g., a seamless customer experience across your products. Maybe, it could be all contained within a single product if you define, design and architect it appropriately.