In theory, the product owner’s responsibilities are simple: The individual should maximise the value the product creates according to the Scrum Guide. But what does this mean in practice? In reality, the application of the product owner role varies greatly, as products and organisations differ. But my experience shows that there are two key factors that determine the duties of a product owner: the scope and the depth of ownership. This blog post discusses these two factors to help you apply the role successfully.
Ownership Scope: Product, Feature, or Component Owner?
To get the product owner responsibilities right, start by asking what the individual owns. Is it a product, a feature, or a component? While this may sound like a trivial question, it can be a tricky one to correctly answer: I have seen more than one company where people lacked a shared understanding of what a digital product is. If that’s the case, it tends to be unclear what it means to manage or own a product. Some individuals look after an entire products, whereas others manage a feature or a component. The following picture summarises the differences between the three terms.
Many product owners I have met weren’t product owners but feature owners or component owners. While there is nothing wrong at all with being a feature or component owner, the responsibilities significantly differ from a product owner:
A product owner owns the entire product. Consequently, the individual should focus on making and keeping the product a success—by ensuring that it offers a strong value proposition to the customers and users and that it creates the desired business benefits.
A feature owner, in contrast, is focused on one or more individual features. The individual’s responsibility is to ensure that the features performs well, for example, that the drop-off number of the checkout feature is low. Similarly, a component owner looks after one or more component, such as, the user interface or data access layer. The person makes sure that the architectural element works as expected. To do so, the individual usually has to have the appropriate technical skills. The picture below illustrates the three different owner roles.
Using feature and component owners is a scaling technique: It can help you grow your product by dividing the product responsibilities. A common approach is to have one overall product owner who manages the entire product and several feature and component owners who look after its parts.
Ownership Depth: Strategic or Tactical Product Owner?
Say you are a product owner in the sense discussed above. Then that’ great. But to which extend to you own the product? Are you responsible for the tactical and strategic decisions, or do you focus on the tactics? Strategic responsibilities include deciding on the product strategy, developing the product roadmap, and managing the stakeholders; examples of tactical duties are managing the product backlog, writing user stories, and working with the development team
Individuals who own the strategic and the tactical decisions are sometimes referred to as “big” product owners. Product owners who focus on the tactics are called “small” product owners. Depending on the ownership depth, small and big product owners have different responsibilities, as the diagrams below show.
I view a small product owner as a partial product owner. Unfortunately, the definition of the role in Scrum—the framework that gave birth to it—is not clear. While the Scrum Guide states maximising value of the product as a responsibility, it only lists tactical duties like managing the product backlog and working with the development team.
I find it not uncommon that small, tactical product owners work with a product manager who owns the strategic product decisions. This setup is usually chosen help grow the product—it’s another scaling technique. It can work well when the product is stable and especially when it has become mature. It is less suited for younger products, which tend to experience more change and therefore require a closer alignment of strategic and tactical decisions.
Post a Comment or Ask a Question
30 Comments
Hello Roman,
thank you for looking into Product Owner role deeply and sharing your thoughts. I wonder where the responsibility for the incidents and problems in a post production sits from your perspective? Who is in charge for the running service? Who should be responsible that incidents are properly addressed and workarounds provided until they get fixed?
Thank you/Dima.
Hi Dima,
Thank you for sharing your feedback and question. I regard it as the responsibility of the product owner to balance addressing incidents and bugs with adding and improving functionality. Resolving the incidents and fixing the bugs is best done by the development team in my experience. Please take a look at my article “Succeeding with Innovation and Maintenance” for more information.
Hope this helps!
Hi Roman,
I enjoyed your treatment of Product vs Component owners. I’m wondering if you see similarity between Component Owners and what ITSM describes as Service Owners (or Service Delivery Managers). Larger enterprises may have adopted IT Service Management (ITIL) processes which involve the concept of an IT service catalog which is comprised of services that can enable business processes or, possibly, products. Your description of a Component owner seems to align with this concept so I’m curious if you see them as inter-changeable ideas. If not, what kinds of distinction would you call out?
Thanks!
Thanks for your feedback and sharing your question Haig. I am no ITIL expert, but I would expect that someone who owns a service that provides value to (end) users acts like a product owner. I manage my services–my training courses–like products: Each has a value proposition, target group, key features, and business goals; and I can determine the life cycle stage of each course. Hope this helps!
You have just simplified all the complexities we have been struggling with for the past 6 months. I think most organisations could benefit from splitting the Product and Feature owners. I have said many times that we have an SME/Account manager and PO that between them make up the PO role. Really we have a PO and Feature Owner. This makes allot more sense.
Thanks for your feedback Chris and good luck with helping your product people collaborate effectively.
“Similarly, a component owner looks after one or more component, such as, the user interface or data access layer. The person makes sure that the architectural element works as expected.”
HI Roman,
I am wondering based on the above quote, how one would reconcile slicing work vertically with a “component owner”. Why would you want to build things in Architectural components and treat that similar to a product? That goes against the most basic agile principle of building potentially shippable software, doesn’t it? It also implies delayed integration and working in technical silos, none of which are aligned with an agile approach to delivering business value through working software every sprint with cross-functional teams. Or am I missing something?
Hi John, Thanks for sharing your question. My intention was not to recommend treating architectural building blocks as products, but to describe an observation: I have met a fair number of people who were in charge of a building block like the payment system and thought of themselves as product owners. I would instead call such an individual a component owner (according to my definition of what a product is). But the concept of a component owner can be useful when a product requires more than a single product owner, as as I discuss in Scaling the Product Owner Role. Hope this helps!
Roman,
This is interesting stuff. I wonder how do you think about Feature owners in the context of persistent Agile teams? More specifically the scale of a Feature vs. the Product. I can see a Product owner (aligned to an experience) designing features and stories that sustains a persistent team for a longer period of time. In that context, wouldn’t a Feature owner be a temporary role?
Thanks for your feedback and comment Saurabh. A feature owner should look after the feature as long as it need to be managed. If you decide to unbundle the feature, then the individual may become the product owner of the newly created product. If the feature has matured and is in maintenance mode, then there may not be enough work to justify having a person looking after it. Similarly, I would suggest that a feature team looks after a feature and works with a feature owner for an extended period.
Does this help?
Hi Roman,
Thank you for sharing such great insights on Product Owner roles and responsibilities.
I am contemplating to make a move from a Business Analyst to Product Owner. What be the career options available for Product Owner role? How can one grow past the Product Owner role.
I hope that you understand my question, otherwise feel free to ask.
Thanks in advance,
Varun
Hi Varun, Thanks for your feedback. It’s difficult for me to comment on the career options available for product owners, as this depends on how the product owner role is applied in a company. But I recommend that you take my product management test to find out which product management and product ownership areas you should strengthen. You can find the test here: https://www.romanpichler.com/tools/romans-product-management-test/
Hi Roman, Great comments. I feel you are genuinely interested in Product Ownership and have very wise comments about the role.
In my company (40 employees) we have a challenge at the moment. There are five different products and five different Product owners, but I feel that the responsibility of the Prod owners is very vague in our company. The only function they have is actually to make a decision about whether something should be developed or not. Responsible for what is put into the product so to say.
I was offered the role as Manager for the Product Owners, but I’m still considering if I should take it on or not… I have also been given the possibility to look over the responsibilities and come up with a suggestion.
Do you have any ideas? What should the Manager of the Product Owner be responsible for and what should the Product Owners be responsible for?
Hope that you understand my question…otherwise feel free to ask.
Thanks in advance,
Maria
Hi Maria,
Thanks for sharing your question. It’s difficult for me to make concrete and helpful recommendations without knowing more about your company and the products you provide. Generally I would expect that as the line manager of the product owners, you are the head of product management. This requires you to carry out the usual line management responsibilities including developing and growing the individuals you look after and ensuring that they understand their roles and responsibilities. You may also act as the portfolio manager, the person who helps align the five products, manage dependencies, and sets priorities.
Does this help?
Hi Robert,
Do you believe the product owner is responsible for detecting and troubleshooting software bugs of the product in post-production?
Hi Kristi, I don’t think that the product owner is responsible for detecting and troubleshooting software bugs in production unless the inhttps://www.romanpichler.com/wp-admin/edit-comments.php#comments-formdividual is also a development team member. Does this help?
Hi Ronan.
Can the same physical person work with two hats in agile team?
It is possible the product owner to perform acceptance tests to inspect the increment? Thanks and regards
Kostas
Hi Kostas, You can be the product owner and a member of the development team. But I find that playing both roles is usually challenging and often not sustainable. I therefore recommend that you specialise and work as a full-time product owner. As the product owner you should review product increments and assess if and to which extend it is done. You should be able to expect that automated acceptance test were successfully run before any functionality is shown to you. Does this help?
Yes, it helps a lot. I had a discussion with another scrum master. His view is that product owner performs acceptance test by himself if necessary. I never heart this case before. What do you think?
Thanks
K
As the product owner, you should ensure that you know which product backlog items or user stories are “done” at the end of the sprint, so you can confidently expose them to the users and customers, for example, by demoing the product increment, employing a usability test, or releasing the software. I would expect that the development team has successfully run the necessary tests before showing me a piece of functionality. If you haven’t agreed with the team on what “done” means for your product increments, then get together and list the criteria. These typically include that the increment is tested, documented, and can be released.
Hi Roman,
first of all thanks for your very interesting post.
I’m interested in Product Ownership and it’s a pleasure to find good content about it.
I have a question: how would you manage Product Ownership in a small team (3/4 people) in a mid-size company, where the Product Owner is – due to budget needs – also one of the developers?
Is it possible – in your experience – to successfully function both as developer and Product Owner?
Thanks.
Hi Eleonora, Thanks for your feedback and comment. I have worked with a few teams where one of the team members played the product owner role successfully. Generally speaking, I find combining the roles challenging. There are two main reason: First, as the product owner, you require a different perspective and skill set compared to a designer, developer, and tester. Second, playing both roles can become quickly unsustainable due to the time required doing both jobs well. I suggest you try playing the two roles giving priority to the product owner job. Use the retrospectives to get feedback from the team, and to reflect on how effective it is to combine both roles. Hope this helps.
Hi Roman,
thanks for your answer.
We’ll surely try playing the two roles giving priority to the product owner job and than use the retrospective to give/receive feedbacks.
Thanks again for your prompt advice 🙂
Glad my answer was helpful. Good luck with playing the product owner role!
Hi Roman – Thanks. Yes. I have seen this before. It reflects a large organisation/mature product well. In reality, the challenge comes when you are growing. There is often a long (12-18 months) where the product revenue supports a single Product Owner but the existing customer demands (for new features, education and sustaining) are high enough to make the Product Owner responsibilities you outline above very challenging. It’s when you need 1.5 -2 FTEs on the product.
I wonder how you would prioritise the different PO activities in the case where the individual can’t do it all.
Thanks
Johnathan
Hi Jonathan, When your product is growing rapidly, and being the single product owner becomes unsustainable, I suggest you consider the following two options:
The first option is to break up your product into vertically aligned feature clusters thereby creating a “product suite”. This approach is depicted in the blog post and slide deck referenced in my earlier comment. In sum, several product owners work in parallel each owning a product part/feature cluster. The benefits include a minimised scaling overheard, the ability to develop the different parts/clusters at different rates, and to expose different feature combinations to different segments. The second option is to grow slowly, and to continue working with one product owner and a small number of teams.
Without knowing more about your product and organisation, I cannot make a recommendation unfortunately. While it can be a huge temptation to grow quickly, scaling too fast can damage the product performance and the brand in my experience.
Does this make sense?
Hi Roman – Where do you see ongoing management of the released product sitting in the responsibilities of the Product Owner? If you have multiple versions of your product being supported, the burden of sustaining and maintenance, as well as net new development, can be significant.
Be interested in your thoughts.
Johnathan
Hi Jonathan, Thanks for your comment. I view the product owner as responsible for existing and new versions of his/her product. But as the product grows and becomes more feature rich, I prefer to employ a product owner hierarchy, or to break up the product, as I have described here:
https://www.romanpichler.com/blog/scaling-the-product-owner
http://blog/the-product-ownership-test/ (p. 12 and 13)
Does this help?
Hi Roman,
As one of the *very few* authors out there with anything written on product ownership, it’s pretty easy to pay attention to what you have to say. 😛
I’m very pleased to see that you give consideration to research/validation techniques as part of the responsibilities. It’s what we’re calling discovery.
One of the patterns we see (and encourage) is to form a triad with ux and development, to answer the questions: what do people want, can they use it and can we build it? Hae you seen this? What is your take?
Thanks,
Aaron
Hi Aaron, Thanks for your comment. I absolutely agree that discovery (or problem validation aka customer discovery) should be a firm part of what a product owner does. Unfortunately, that’s not always the case in my experience. I also agree that product owners should collaborate with the right people including UX designers and developers to understand what the desired user experience is and if building the product is feasible. I find it helpful to focus on these two aspects once we understand that there is a problem that’s worthwhile addressing. Does this make sense?