Scaling the Product Owner

Posted on Monday 25th January 2010

Summary

This post discusses scaling the product owner role and describes the chief product owner – the product owner in charge of a complex product developed by a large Scrum project.

15 Flares Filament.io 15 Flares ×

The product owner is the person in charge of the product. For products of modest complexity and small projects, it may be feasible to have one individual playing the product owner role. But how do we deal with product ownership on large Scrum projects that develop complex products?

The Chief Product Owner

A large agile project consists of many small teams. Each team needs a product owner, but my experience suggests that one product owner usually cannot look after more than two teams in a sustainable manner. Consequently, when more than two teams are required, several product owners have to collaborate.

This puts us in a dilemma, as it conflicts with the Highlander Principle, which states that there should only be one product owner. The solution is to introduce a chief product owner. A chief product owner is responsible for the overall product, guides the other product owners, and facilitates product decisions.

There are two ways to apply the chief product owner role: working with one potentially large and complex product, or breaking up the product into multiple, independent sub products.

Option 1: One Product

If you develop one cohesive product with lots of functionality, you are likely to end up with a hierarchy of collaborating product owners with a chief product owner at the top, as the following image shows:

In the picture above, the chief product owner is responsible for the overall product whereas the other product owner manage feature sets or individual features.

Option 2: Product Suite

The second option is to break up the product into vertically-aligned, focused sub-products that can be managed by one product owner, as the following image illustrates:

The advantage of the product suite approach is to release the individual products separately and to package them to product variants. A flatter project organisation also means less overhead and faster decision making. The product backlogs are focussed and more concise reducing the grooming effort and increasing transparency.

Summary

If you work with more than one product owner, put one individual in charge of the overall product. As your product grows and becomes more feature rich, consider breaking it up into focused, vertically-aligned products that can be managed by one product owner and developed by no more than three teams. This allows the product owners to control their product, reduces decencies and overhead, and speeds up development.

13 comments on “Scaling the Product Owner

  1. The Product Owner *can* be a consortium…

    … In his new blog post Roman Pichler breaks with the supposedly golden rule that a Product Owner must be a single person ……

  2. Geoff Watts says:

    Roman

    Would you recommend any formal tools or practices for effectively scaling the product owner? For example a clear, documented product vision with cascading goals or a product owner daily scrum?

    Geoff

    • Hi Geoff, A shared product vision is certainly particularly important on a large Scrum project to help everyone move in the same direction. I also recommend using one product backlog, as the product owners and teams collaborate to create or update one product. To succeed with a large-scale development effort, specific practices have to be applied. These include extending the product backlog grooming horizon to two to three sprints, employing lookahead planning to anticipate and resolve dependencies between the teams, running Scrums of Scrums to facilitate the communication between the teams, and enabling joint sprint reviews and retrospectives to foster a sense of unity and project-wide learning. Regarding the project organisation, I favour feature teams over component teams. (The former implement a theme or set of user stories; the latter build a subsystem or component.) With feature teams, the product owners are responsible for pieces of functionality such as “Entertainment” or “Chess” with the chief product owner looking after the entire product.

  3. [...] decision making, including product backlog prioritization and release planning as my post “Scaling the Product Owner” [...]

  4. [...] decision making, including product backlog prioritization and release planning as my post “Scaling the Product Owner” [...]

  5. Hi Roman,
    I agree completely with all you’re saying. This is exactly how we’ve scaled the role of the product owner in several large projects. I have only one remark – I would only cautiously suggest 1 product owner can support up to 2 feature teams, because of one of the common product owner mistakes which is the risk of the overworked product owner. (see: http://www.romanpichler.com/blog/avoiding-common-product-owner-mistake/)
    Jutta

  6. [...] the product owner role Scaling the product owner Avoiding common product owner mistakes Desirable characteristics of a product owner Product owner = [...]

  7. [...] from delegation (but also negative in situations that have been unclear). See for example Roman Pichler’s advice on Scaling the Product Owner. Sometimes I believe that a split into business-facing and team-facing Product Owners is another [...]

  8. [...] complex products or large projects, you have two options: You can either employ a product owner hierarchy with a chief product owner in charge of the entire product and product owners responsible for [...]

  9. [...] effectively. On complex products or large projects, you have two options: You can either employ a product owner hierarchy with a chief product owner in charge of the entire product and product owners responsible for [...]

  10. [...] acceptance criteria, and solid clarification when needed. Mega-projects might need one solution, whereas product suites may use another. The size of the product, the number of teams, the distance to the customer, the [...]

  11. [...] Once the Product Canvas and the architecture have started to stabilise, you can start adding more people to the project. I find it useful to break-up the original team so that at least one or two members are part of each new team, as this helps the new members get up to speed. I also suggest you grow your new product development project in a step-wise fashion: Scale from one to two teams, then from two to four, and so forth. This allows you to understand the impact on the people and the process including product ownership . [...]

Leave a Reply

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

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>