Scaling the Product Owner Role

Roman Pichler

Written by Roman Pichler

on Tuesday 28th June 2016



In theory, the product owner is one person. But in practice, managing a larger, complex product is usually a shared effort. But how can product ownership be split without resulting in decisions by committee and creating a weak or even inconsistent product? In this post, I discuss different techniques to help you scale the product owner role successfully and I explain when each technique should be applied.

28 Flares 28 Flares ×

Scaling and the Product Life Cycle

To understand if and when the product owner role should be scaled, I find it helpful to consider the product’s life cycle stage. As long as a product is young and hasn’t reached product-market fit—or is close to achieving it—I recommend having a single person in charge of the product. Here is why: Young products tend to require a significant amount of experimentation and rework in order to get the product launched, adapt it to the feedback of the early market, and get it ready for product-market fit. At this stage, effective decision-making is paramount. Having a single product owner in place supports this: if no consensus can be achieved about what to do next, the product owner decides. Having one person in charge of the product is viable, as it is usually comparatively small and only a small number of development teams—one or two—are likely to develop it at this stage.

But once the product is becoming more successful and start growing, once it attracts more features and becomes richer and requires more teams to develop it, a single person can usually no longer manage the product—without being overworked or neglecting some responsibilities. What’s more, the product now changes less frequently and radically, which makes it easier to share responsibilities amongst a group of product people, as the picture below shows.


Scaling Option 1: Feature and Component Owners

Once you’ve achieved product-market fit and entered the growth stage, you should consider sharing the product work by asking other people to own product features and / or components. I view a feature as a product capability, such as, the ability to search for a product on a website, and a component as an architecture building block, for instance, the data access layer. (I discuss the difference between products, features, and components in more detail in my post What is a Digital Product?)

The initial product owner should be in charge of the overall product, take care of the product strategy and roadmap, and manage the stakeholders, but still be involved in managing the product backlog and making prioritisation decisions. The feature and component owners manage their assets: they capture new ideas and requirements, test them using feedback and data, and collaborate with the teams developing the features and components. The following picture illustrates this approach.


Scaling Option 2: Unbundling and Product Variants

The alternative to sharing the responsibility of managing a product is to break up the latter. A common technique to do this is unbundling a feature and releasing it as a separate product—like Facebook did with the Messenger app in 2004. This reduces the scope of the original product and it creates a brand-new one, managed by a new product owner and developed by its own team(s).

Another technique is creating product variants—think of iPod shuffle and iPod Touch, for example. Applying this technique avoids feature bloat of the original product; and similarly, to unbundling, it introduces new offerings that are looked after by their own product owners and built by their own teams, as the picture below illustrates.


You can, of course, combine option one and two, and first introduce feature owners in addition to an overall product owner and then spin-off features or create variants.

Scaling Option 3: Strategic and Tactical Product Roles

The third option to scale product ownership is to introduce a strategic and a tactical product role. The strategic role is often called product manager and the tactical one is referred to as product owner. The product manager

Frameworks like SAFe use this option as a default, but I recommend you apply it carefully: Splitting product responsibilities along the strategic-tactical dimension works well if a tight integration of strategic and tactical decisions is not required. This is typically the case when the product has entered maturity: it is now incrementally enhanced to defend market share and maximise its business benefits; bigger changes are unlikely to occur—unless you decide to extend its life cycle, for instance, by taking to a new market or segment.

If you use this scaling option at an earlier life cycle stage, then you face the risk of strategic decisions not effectively guiding tactical ones, as well as tactical insights, such as user feedback on specific features or a slower than anticipated development progress, not informing the strategic decisions, particularly when several people take on tactical duties and / or the individuals responsible for strategic and tactical decisions don’t work together very closely.


Comparing the Options

How do the three scaling options compare? The following table summarises my recommendations about when they should be used.

Option When to Use it
Single product owner Before product-market fit
Product and feature owners From close to product-market fit to reaching maturity
Product variants and unbundling
Strategic and tactical product roles When the product is mature

As the table above shows, you should not rely on one scaling technique. Instead, consider the life cycle stage of your product and select the technique that’s most likely to help you achieve or sustain product success.

Learn More

You can learn more about scaling the product owner role by:

Article Name
Scaling the Product Owner Role
Find out how to apply the product owner role when a single product owner is not sufficient and the responsibilities have to be shared.
Pichler Consulting


12 comments on “Scaling the Product Owner Role

  1. Geoff Watts


    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?


    • Roman Pichler

      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.

  2. Jutta Eckstein

    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:

  3. Joe Cotellese

    Roman, you mention that when you have both a Product Manager and Product Owner that you risk having a “Paritial Product Owner.” That Product Owners should be both strategic and tactical.

    How do you avoid that scenario when you have a Chief Product Owner?

    • Roman Pichler

      Hi Joe, thanks for your question. The difference between a chief or overall product owner and a (strategic) product manager is that the former is not only responsible for strategy but the individual also manages the product backlog (in collaboration with feature or component owners). The latter, in contrast, usually focus on product strategy and delegates the tactics to a “small” product owner. This has an important implication: If the product manager and the small product owner don’t collaborate well, then there is the danger of misalignment between the strategic and tactical work. In the worst case, strategic decisions are not reflected in the product backlog, and bigger product backlog changes don’t cause product strategy and roadmap updates.

      Does this help?

  4. Andrea F

    I would like to ask your opinion for another scenario. A team is in charge of 3 different products. Why this? Because these products are sufficiently stable and mature and they just need to be maintained and a 7 people dev team guarantees enough capacity for this purpose. From time to time, one of these products has a stronger evolution which could take from 2 up to 6 sprints but in the meantime small maintenance is made on all the other products. Splitting the team would have meant to have very small teams that sometimes could have nothing to do. Take also into account that the technology and some parts of the business logic is shared by the three products.

    Each product has its own product owner, however these product owners belong to a structure with a higher level manager who discusses roadmap and priorities with stakeholders, but the detail of the backlog of each single product is managed by the specific product owner.
    Although it’s a different scenario, this organisation of product ownership looks similar to the Option 1 with the exception that there is one team only. So far, this organisation seemed to work pretty effectively.
    However, I would appreciate you opinion, do you have any feedback or suggestion about it?

    Thank you

    • Roman Pichler

      Hi Andrea, Thanks for your comment. As there are three products in your scenario, you require a portfolio management process and may benefit from having a dedicated portfolio manager–an individual who decides which product receives more investment and coordinates dependencies between the different products. My GO Portfolio Roadmap may help you with this: Hope this helps!

  5. Oscar Lopez Alegre

    Dear Roman,

    Great post, I’m applying it to scale our Organisation.

    I’m agile coach for a company that are just finishing an acquisition. The product owners have been appointed to each of the product/feature of product, and a head of product that has been appointed to drive the strategy. So I would consider that we are close to option 3.

    We are appointing one PO for a new product, but the head of product is insisting that decisions to life and to define priorities comes by a committee that needs to provide unanimous approval for the launch.

    I have suggested that the committee should be considered as stakeholders and discuss with the PO in order to align priorities. But the PO should have final authority to decide wether the product should be launch or not and to what % of users. Getting the approval from the committee has proven to be a lengthy task and will slow down the launch and subsequent sprint updates.

    What would you recommend to do in such situation?

    • Roman Pichler

      Hi Oscar, Thanks for your feedback and comment. I suggest you explore why the head of product wants a committee to decide and does not (fully) trust the product owner. It might be that the individual lacks some skills or that the relationship between the manager and the product owner is broken in some way. Hope this helps!

  6. Peter A

    Hi Roman, do you have any thoughts on if a large product could be “unbundled” or split up based on strategic goals. i.e. if for example moving from Option 1 to a combination of option 2 and 3.

    Rather than a feature owner in option 2 could you see an option of a strategic goal owners within a large product? Potentially working at a tactical level to achieve one pillar of the strategic goal set by the chief product owner?

    • Roman Pichler

      Hi Peter, Thanks for your comment. I recommend deciding if your product should be unbundled or not. Spinning ff features tends to be a good idea if you have a complex product and you find that its part serve different strategic goals (strategic in-cohesion) and / or that some users only use certain features while another group employs different ones (UX in-cohesion).

      If you decide to unbundle your product, identify the features that should become a product in their own right and assign a product manager/owner for the new product(s). My preference would be to start small, as the newly created product(s) are likely to face a significant amount of uncertainty and change. Think of the Facebook Messenger app and the changes it has seen since it was unbundled from the main Facebook mobile app in 2014. You can find more information on unbundling features in my book Strategize.

      Does this help?

      • Peter A

        Thanks Roman – Just purchased your book for more detail.

        I suppose I’m looking at the option of splitting Product Owner roles along strategic focus areas rather than product unbundling so that each PO/ dev team is responsible for different objectives within a product rather unbundled functional product areas.

Leave a Reply

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

28 Flares Twitter 5 Facebook 3 Google+ 1 LinkedIn 19 28 Flares ×