Scaling the Product Owner Role

Published on 28th June 2016 4 min read

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.

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.

When Should You Scale the Product Owner Role?

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.

Product Owner with Feature and Component Owners

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.

Unbundling and Product Variants as Scaling Techniques

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.

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.

Strategic and Tactical Product Roles

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.

Post a Comment or Ask a Question


  • Geoff Watts says:


    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?


    • 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.

  • 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:

  • 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?

    • 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?

  • Andrea F says:

    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

  • 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?

    • 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!

  • Peter A says:

    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?

    • 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 says:

        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.

  • Hi Roman,

    One split I have witnessed many debates about is the Design and PM role split. There are many that feel a UX Designer with business insight can wear both hats and many PM’s with design backgrounds don’t like the idea of not being hands on with design also.

    I come from digital entertainment industry and in the past the lead designer was the product lead and when the PM role was introduced they retained the lead design responsibilities and tried to avoid the new PM responsibilities. The key responsibilities they pushed back on was customer advocacy, KPI’s and data analysis, business modelling, roadmapping and managing and evangelising others to their vision. As concepts like Scrum and Lean Startup were introduced things soon escalated with Designers and PM’s drawing lines in the sand, which didn’t end well.

    What I have been trying is the Strategic & Tactical split with PM’s being strategic and Designers tactical. As we utilise Lean Startup we are also able to split by Problem and Solution. We have also tried Feature & Component and Unbundling Variants via the different Engines of Growth . Although we are having successes we are having many failures also and on reflection I totally agree knowing where you sit on the product lifecycle is the key component to getting this right.

    Thanks again for your insights they as always are very insightful!

    Cheers Jason

  • Ben Schraag says:

    Hi Roman,

    Great post! In your third option you split strategic and tactics. With a product manager or chief product owner construction you can have multiple tactical product owners. How do you split the scope and responsibility of these product owners?

  • Ionut-Adrian Bejenaru says:

    Awesome read. And why it is so great – because it is still relevant today. These options seem the best even today. I like the idea to choose the best option depending on the life cycle of a product.

10 Trackbacks

    Warning: call_user_func() expects parameter 1 to be a valid callback, function 'blankslate_custom_pings' not found or invalid function name in /nas/content/live/romanpichler/wp-includes/class-walker-comment.php on line 179

Leave a Reply

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