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.
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 sometimes called product manager and the tactical one is referred to as product owner, even though in Scrum, the product owner role comprises both, strategic and other responsibilities. Otherwise, a Scrum product owner cannot maximise the value her or his product creates.
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 stable/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
Wonderful! It is so relevant to what we do today in the organisation I work with.
We have a mix of Product and feature owners, Product variants and unbundling, & Strategic and tactical product roles.
And now after reading your article I begin to understand why the structure is built like this 🙂
You have beautifully explained all the scaling options. Thanks a lot!
You’re welcome Pranita and thanks for sharing your feedback. Great to hear that you found the article helpful.
Thanks for all your insights! In my organization, they have chosen the 3rd option: strategic and tactical scale. Although it might make sense in some cases, the border between the 2 is not that simple. When I explain the difference between the 2 roles as per option 3, the PM tell me that they won’t have enough work if they only take into account strategical and high level responsibilities… then, I see most of PM doing the PO job even if they don’t talk directly to dev team… I find these 2 roles duplicated, and it doesn’t work from my view.
Thanks for your opinion!
Hi Nadia, Thank you for sharing your feedback and experience. Sounds like you may benefit from experimenting with having one person in charge of the product (product manager / Scrum product owner) and using feature owners to manage product parts.
Hi Roman, thanks for this article. It is very insightful and helps to have a clear picture on the available alternatives for scaling a Scrum product, regardless of the framework (LeSS, SAFe, Scrum@Scale, among many others). I wanted to ask you if you had any recommendations when working with Infrastructure teams. My gut would be that probably a mix between options 1 and 3 would work best for a large and mature product. Was interested in your thoughts. Thanks!
Thank you for sharing your feedback and question Frank. I would recommend determining the product an infrastructure team looks after. If it is a collection of shared assets, like common components or services, then it may make sense to have someone who owns and manages this collection aka platform, please see my article “Six Types of ‘Product” Owners’“. Does this help?
Thanks Roman, it makes sense and definitely helps. I also found the article suggested very insightful, it helps a lot to understand different variants of product ownership roles
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.
Thank you for your feedback Lonut-Adrian.
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?
Thanks for your feedback Ben. Tactical product owners may look after a feature or a component–depending on what is most appropriate for your product. Does this help?
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!
Thanks for your comment and sharing your experiences, Jason!
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?
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.
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!
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?
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: https://www.romanpichler.com/blog/the-go-portfolio-roadmap/ Hope this helps!
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?
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: https://www.romanpichler.com/blog/avoiding-common-product-owner-mistake/)
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.