Product Owner is responsible for the product success. Product Owner is the single interface about team's work. In a single-team environment, PO works with that team constantly. It's all very clear.

However, in a multiple-team environment, it gets more complicated. It gets problematic to have one PO work with all teams in the product, when the number of teams goes too big. It leads to multiple POs working with different teams. There is still one PO at product level, who creates PO team with multiple POs. One PO will normally work with more than one team, but not all teams. Since one (big) feature may be developed by multiple teams together, two modes of relating PO and team come up.

• PO on team: Fix the relation between PO and teams. For each PO, they constantly work with a few teams. Naturally, they manage the part of product backlog that relates to his teams' work.

• PO on feature: Not fix the relation between PO and teams, but change it depending on the feature that the teams are working on. In this case, PO is responsible for features in the product. Which teams work on those features, PO works with which teams.

I have been suggesting PO on team all along, and I don't feel right about PO on feature. This post tries to clarify why, not only for you, but also for my own.

Why PO on feature?

Let's first understand the benefits that PO on feature tries to get. There are mainly two.

1. PO can specialize on part of the product and some features. For any team to be able to work on any part of the product, though ideal, it may not be feasible to beginning with. The same applies to PO. PO on feature makes it possible for them to specialize on part of the product.
2. The overall feature can be managed by one PO, so that it reduces the coordination efforts among related teams.

Problems with PO on feature

The most obvious problem with PO on feature is, what if one team need to work on multiple features at the same time? If you would allow multiple POs to interface with same team, it would've brought back all traditional problems such as conflicting priority, partial allocation, etc.

But PO on feature does not have to be so. It can still be clear who is the PO for the team at any time. If team works on two features, the PO responsible for the more significant feature (in terms of value, size, etc.) will be the PO for that team in relevant sprints. Other POs need to work with that PO in order to get their stuff done in those sprints. Then, there will be PO switch, as team works on different features. Two POs may work together for transitional period, though only one of them is PO towards team at any time.

Is this variant ok? I do not think so. There are two deeper problems with PO on feature.

1. PO on feature creates strong focus on current feature, and does harm to the flow and long-term sustainability. If we'd like to get team high performance in the sprint, we shall make the feature ready before putting it into sprint. That requires progressively grooming the backlog and future features. If we'd like to get our release more predictable, we'd like to proactively address risks and uncertainties. That requires investing earlier by having spikes. If we'd like to sustain in delivering good quality product release, we shall lower the cost of change. That requires gradually paying off the technical debts from legacy. However, PO on feature tends to short-term project thinking.
2. PO on feature breaks the feedback loop, which is critical for learning and continuous improvement. It is less likely for PO on feature to learn from mistakes such as wishful commitment, sacrifice done, ineffective collaboration on requirements, etc., together with former teams.

In short, PO on feature often leads to imbalance between short-term and long-term thinking and focus, while for the role of Product Owner, it is not enough to be able to maximize ROI for one sprint or one feature, but do that sustainably for the life of product.

PO on both team and feature

What can we do to gain the same benefits into the mode of PO on team? Working in product areas is the key.

• Since features often spread into many teams, area should be big enough to fit most of features. Then, the overall feature is managed by one area to ease the coordination.
• Big enough area is still smaller than the whole product, thus, PO still possibly specializes in the area with relatively small step.

Regarding the number of teams one PO can work with, some say no more than 2, others say up to 10, my sweet spot is around 5. The size of 5 teams per PO is good for both having some specialization and reducing the feature coordination.