While the product owner role is not new—it emerged in Scrum in the second half of the 1990ies—there is still confusion about what it means to be a product owner. It’s not uncommon for me to meet someone who refers to themself as a product owner, only to discover that they own a product part but not the entire product. Other times, I meet someone who says they are a product owner. But it turns out that the person manages several products, an entire product portfolio. This article helps you reflect on and improve the way the product owner role is applied at your workplace. It describes six common types of “product” owners. It shows how the roles differ and relate to each other, and it explains how you can effectively apply them.
Listen to this article:
The term product owner is commonly used to refer to six different product roles in my experience. These are:
- The original Scrum product owner who owns a product in its entirety and is responsible for maximising the value it creates.
- A feature owner who manages a major capability with which end users interact like search and navigation on an online retailer’s website.
- A component owner who owns an architecture building block like the persistence layer.
- A platform owner who manages a platform as a collection of shared software assets.
- The SAFe product owner who owns the product details.
- A portfolio owner who manages a group of (related) products.
Each of the roles above is a product management role; anybody playing one of the roles takes on product ownership; and each role can be exciting and rewarding. None is per se better or worse. But as indicated, the ownership scope significantly differs and with it, the empowerment and skills required to succeed.
The following pictures provides an overview of the six roles, which I describe in more detail in the sections below.
Note that some of the roles above can be combined. For example, you could be a product and a feature owner on a larger product, or you could be a portfolio owner and at the same time, manage one of the products in the portfolio, assuming that this neither leads to biased product decisions nor sacrifices sustainable pace.
Scrum Product Owner
As its name suggests, a product owner in Scrum is in charge of a product. Note that the choice of the name is intentional. The role is not called product administrator, feature broker, product backlog manager, user story writer, or project manager—even though that’s sometimes how it is interpreted. It is also not called “product manager” primarily to indicate the level of empowerment and respect product owners require to succeed in their job. But you can think of the product owner as an agile product manager, as I explain in the article “Product Manager vs. Product Owner”.
If the product owner owns a product and is responsible for maximising its value, then it is important to understand what a product is. I regard a (digital) product as an asset that creates value for a group of users and for the business. For example, I am writing this article using Microsoft Word. When I need to take a break from writing, I save the document. Word is the product. But the ability to save the document is a feature, a part of the overall product.
If someone is referred to as product owner, then the individual should own the product in its entirety—like Word in the example—and not just a product part—such as the ability to save a document. Referring to people as product owners who do not manage a product and do not exercise the right ownership is wrong in my mind: It creates confusion and it sets wrong expectations: Someone who owns a product part cannot take on the responsibility of maximising the product’s value and achieving product success. Additionally, the individual does not need the corresponding decision-making authority and does not require the same skills.
A product like Microsoft Word is, of course, likely to be too big to be managed by a single individual: It requires several product people to collaborate. But even in this case, I would suggest that there should only be one product owner. The other product people involved should have roles whose names correctly reflect their scope of ownership, as I discuss below.
Feature Owner and Component Owner
A feature owner is an individual who owns a capability end users can interact with, for example, the ability to persist a Word document or to edit it. A component owner owns an architecture building block like a user-interface layer or a payment service. Component owners typically require in-depth technical skills. For example, the owner of a persistence service has to be able to describe its interfaces or APIs and converse with the users—the development team members who use the service.
Feature and component owners are responsible for maximising the value their features and components create while ensuring that this does not compromise the product’s overall value creation. This includes describing their functionality, interacting with development teams, participating in product discovery and strategy work, and helping evaluate feedback and data.
I regard feature and component owners as members of a product owner team, a group of product people who collaboratively manage a larger product. The product owner team is led by a Scrum product owner who ensures that the right product decisions are made, that a valid product strategy and an actionable roadmap are available, who prioritises the product backlog, and who engages the stakeholders. The feature and component owners own the decisions for their assets, describe, prioritise, and validate their features and components, work with the development teams, and contribute to the product discovery and strategy work, as the picture below illustrates.
A software platform is a collection of digital assets that are used by several products, as I describe in more detail in the article “Leveraging Software Platforms”. A platform owner owns such a platform. The individual is responsible for maximising the value the platform creates, for example, reducing time-to-market of the products built on top of it or reducing development cost.
You can think of a platform owner as a type of Scrum product owner: Someone whose product is a platform and who requires in-depth technical expertise to communicate with the users of the product—the members of the development teams who build the products that use the platform.
When a platform grows, it may be necessary to share product ownership and introduce feature and/or component owners along the lines describe above.
SAFe Product Owner
The agile scaling framework SAFe uses its own product owner role, the SAFe product owner. Despite the similarity of the name, the role significantly differs from the Scrum product owner. Whereas a Scrum product owner owns a product in its entirety, a SAFe product owner looks after the product details, defines user stories, works on a subset of the product backlog, and interacts with the one or more development teams.
The SAFe product owner is therefore focused on the product tactics. The strategic product responsibilities are taken on by another role, the SAFe product manager. To put it differently, the SAFe model splits product ownership into two distinct roles: The SAFe product manager owns the strategic product decisions, and the SAFe product owner is in charge of the tactics. This is in stark contrast to the Scrum product owner who exercises full-stack product ownership, from vision to the tactics, as the following picture shows.
While using a strategic and tactical product role is a common scaling technique, it is best applied when the product is stable. In other words, I find the approach less suited when faced with a significant amount of uncertainty and change that affects the product strategy. This is usually the case in the development, introduction, and (early) growth stage of the product life cycle.
Here is why: As long as you search for a valid strategy to launch a product, achieve product-market fit, and then keep the product growing, it is particularly important to dovetail strategic and tactical product decisions. This is hard to achieve when they are split across two distinct roles. (In contrast, a Scrum product owner is always involved in the tactical work, even though the bulk of the work may be done by feature and component owners in collaboration with the dev teams.)
A portfolio owner looks after a group of products, and the role is also known as product portfolio manager. An example of a product portfolio is Microsoft Office. It consists of products such as Word, PowerPoint, and Excel.
The job of a portfolio owner is to maximise the value a product portfolio creates. This includes actively managing the portfolio, collaborating with the product owners who look after the products within the portfolio, harmonising the individual product strategies and product roadmaps, aligning major releases, managing dependencies, and helping create a common user experience across the various products.
The individual will typically benefit from having solid product management skills and from having successful managed individual products before stepping into the role. For a smaller product portfolio, the head of product might be able to take on the role. Otherwise, a dedicated full-time portfolio owner will be required.
I hope that the role descriptions above have helped you reflect on how the product owner role is applied at your company and that you have managed to identify ways to improve it. Don’t feel bad if you have discovered that you are not a Scrum product owner. Any product role can provide a great opportunity to help progress a product and create value for the users and the business. As I have suggested before, what truly matters are not our job titles. It’s the good we do for the users and our businesses.
The following picture summarises the six roles.
Post a Comment or Ask a Question
This is such a good read, well explained Roman.
I have a scenario where currently there are two different products serving two different user bases and have two different UIs. Each of these products now have separate Product Owners.
In near future the plan is to consolidate these two products into one and have one UI, which caters to different user base. Now from strategy perspective should there be only one Product Owner owning the new unified UI, or is better there is one PO and may be 1 or two Feature Owners?
Thanks for your feedback and question Vinish. If you decide to bundle the two products and combine them into one, I recommend having one person in charge of the newly formed product. If managing the new product is too much work for a single individual, then involve additional product people who own parts of the product like one or more features. I would encourage you to validate that bundling the two products is the right strategy, as the two products seem top address different target groups. An alternative would be to create a platform that standardises the UX/UI and possibly encapsulates shared assets (services/components). Hope this helps!
I really appreciated the distinction between the roles – thank you!
How would these roles align to internal tools in which business stakeholders feel a sense of ownership and vision for the platform their employees use to get their job done?
I’m comfortable with the idea that product roles should talk directly to end users to define opportunities and develop own their roadmap but this autonomy seems to be much less with internal tools where alignment with stakeholders is expected.
Would appreciate your thoughts on how product roles change and/or are similar for market facing tools and internal tools.
Thank you for sharing your feedback and question Tanya. It’s great when business stakeholders take an interest in a product. A good way to involve the stakeholders is to invite them to sprint review meetings and to consider forming a product team. But the product owner should be empowered to have the final say on product decisions and decline stakeholder requests. Otherwise, it would be unfair to expect that the person playing the role is responsible for maximising the value the product creates. You can find more advice on involving the stakeholders in the article Stakeholder Management Tips for Product People. Hope this helps!
Hi Roman. I always love your work.
I found this piece while searching for the term Technology Owner. I have found that when a development shop has technology standards, component contract choices, and an architecture, the Scrum Product Owner often needs a Technology Owner as a collaborator. I understand that the Scrum Product Owner still owns the outcome.
Here’s my question… when scaling, with Scrum of Scrums, LeSS, etc, the proliferation of product owner roles and associated specialization make it hard for a given team to have just one representative (the Scrum Product Owner) participate in the next highest scaling level. At the very least, the technology of the shop or product must be represented there. So the aggregation up the scaling ladder can have quite a large group.
Can you say something about how these different roles interact with a scaling strategy’s need to keep aggregation teams down to a Scrumly manageable size? I have always found that difficult.
The most workable solution I have found is to invite all the “key” people to what I call a weekly Horizon Meeting, a little longer than a daily Scrum, where we try to help keep our teams looking out to a 2-3 sprint horizon. To anticipate needs and solve potential problems while there is still time. The invitation list is somewhat large, but the actual attendees vary depending on what is going on. Spin-off meetings occur as the participants deem necessary. More ad hoc than the formal styles I’ve read about, but effective.
I’m interested in what a more formal approach, like yours, has to say about the problem I have tried to solve in that way.
Thanks for sharing your question and approach. Let me start with a disclaimer 🙂 I don’t offer a complete scaling framework,a dn I am not an agile scaling expert. Instead, I’ve suggested ways to scale the product owner role, see my article Scaling the Product Owner.
However, I suggest that you sue product goals to focus your development efforts and capture the goals on a goal-oriented product roadmap. This offer a continuity of purpose and longer-term direction to the dev teams and stakeholders, and it may allow you to do without your horizon meetings.
Hope this helps!
Thanks Roman. I’ll have to think about that.
Your welcome Bob!
Hi, If you were to set up a trial as to the value of having a product owner, what would you measure, and how. Cheers.
Thanks for sharing your question Lucy. I would turn it around and ask: What would happen if you don’t have someone who manages the product and ensures that it creates the desired value for the users, the customers, and the business? In other words, what is the in-action risk? A Scrum product owner is ultimately successful if the individual maximises the value a product creates. But this assumes that the person is adequately empowered, has the necessary skills, can dedicated most of their time to the role, and has the right environment. The latter includes an effective cross-functional development team, supportive stakeholders, and an effective Scrum Master. Hope this helps!
Very interesting article Roman. Thank you! In my previous job, I combined two roles :
– Digital expert (official) inspiring Belgian tech companies and acting as sparring partner for their digital transformation roadmaps
– Product owner (not official) responsible for creating and delivering value for two digital products (from concept to final delivery and go to market)
My question: Is a Scrum product owner also accountable for sales and marketing of the product? I saw in different organizations misunderstandings and tensions between marketing department and product owners? What is your opinion on the accountability of a Scrum PO on marketing aspects? How can we improve cooperation on this crucial element?
Thank you for sharing your experience and question Benjamin. The Scrum product owner is not responsible for marketing a (commercial) product. That’s the marketer’s job. To ensure that the marketing effort is aligned with the product owner work, I recommend establishing a close and trustful connection with the marketer (as well as other key stakeholders). This can be achieved by forming a product team. Hope this helps!
Correct! Thank you. The org. culture enhancing cooperation and mutual respect is a critical success factor … I no longer work in this company and try to re-think my professional positioning and expectations. Not that easy as I have many different experiences but your very inspiring blogs help. Thank you.
You’re very welcome Benjamin and thanks for the feedback. I ma glad that the reply and my blog in general are helpful. Good luck with your next career step.
I really found your post helpful – thank you.
What are your thoughts on Product identification e.g. in the Aviation industry? Besides the products that are sold to customers, how does an IT dept that supports selling, operations & back-office functions identify/break down what it does into products? Is a grouping like ‘Flight Operations’ for example a product, or is it the smaller units within that deliver value to internal customers that are products e.g. Crew Management (planning, rostering, tracking, leave)?
Thank you for sharing your feedback and question Una. When defining products, ensure that each asset creates value for a group of people, users and possibly customers, and the business. The users might me external or internal; they might be from flight operations to say with your example, or they might even be members of other development teams, for example, in the case of an internal software platform. Reading my article What is a Digital Product? should help you effectively define your products.
Thanks for this article, it perfectly explains the difference in the product owner roles. I am curious to get your input on using Word as an example. If Word was different in various markets, would it be owned by a component product owner? The product development would be too huge to include in one feature but at the same time, the EMEA market use it differently, but the outcome would be the same data for analytics.
Thanks for your feedback and question Koka. If a product like Word is offered as separate product variants for different markets, then my preference would be to have an overall product owner for Word. However, if the variants were significantly different, and there was no longer a standard product, then I would move to a platform model where the Word variants are built on top of a platform that encapsulates shared assets. Hope this helps!
Great, tnx for a super post.
How about Area Product Owner in accordance with LeSS: https://less.works/less/less-huge/area-product-owner ?
Is this also valid naming convention? 🙂 The corporation I work for still struggles to find proper job titles.
Thank you for discussing it.
Hi Mattias, Thanks for sharing your feedback and question. My understanding is that a LeSS area product owner (APO) is somewhat similar to a feature owner (as I describe it in the article). The difference is that an APO tends to own several related features that make up an a product area, hence the name. Such an area requires at least four development teams. Consequently, APOs are only used in LeSS Huge adoptions. A feature owner, however, can be used on smaller products, and the individual playing the role only might own only one feature at a time and might work with no more than two development teams. Hope this helps!
Great article. I’m working with one of my clients to build out their Product hierarchy. They are using a title of Product Manager; progression step from Product Owner. In essence, wouldn’t a Portfolio Owner be the manager?
I need to see what a typical progression from entry level to Scrum looks like.
Hi Bill, Thanks for the feedback and question. I find that working as a feature owner is often a great way for people to gain experience with agile product management practices and a stepping stone to becoming a Scrum product owner and managing an entire product. The product portfolio manager/owner role can sometimes be played by the head of product if the product portfolio is not too large and the product management team not too big. Hope this helps!
What is the difference between Product Owner & Product Manager, as per scrum guide Product Owner looks for product vision, maximizing the value of the product , Maximizing ROI etc.. are both of these roles same ?
Thanks for sharing your question Ashish. I discuss the two roles and their differences in the article “Product Manager vs. Product Owner.” Hope this helps!
Hello Roman, thank you for sharing your thoughts and experiences. In different change projects where a company and especially the technology department wants to move to agile product teams, there is sometimes the question where the product owner belongs to. Is it a person that orginately comes from a business unit or is it a person, who comes from technology and has a deep understanding of the business? I personally think it makes no difference as long as it is the right person who takes over the role. However, I did make better experiences when the product owner comes and sits in technology and not in a business unit. The acceptance within the product team (where normally most people are tech girls and guys) is much higher, when collaborating to develop a good product. What are your thoughts about this? Cheers Daniel
Hi Daniel, Thank you for sharing your experience and question. I would answer the question by exploring what products we are dealing with. Say one of the products is a software that supports HR. In this case, I would choose someone who has in-depth knowledge of how the department works, most likely an HR member and help the person acquire the relevant product management knowledge. But if the product is, say, a platform that support the HR software (amongst others), then a product owner with strong technical knowledge is required. I would hence select a senior developer or architect and help this person learn the appropriate product management practices. In both cases, you will face the challenge of establishing an effective product management function: a group of professional product people who have the necessary skills and time, and who are empowered to do their job. Hope this helps!
Hi Roman, I have an interesting scenario, where I have Product A, being split between 14 sites. Each site needs a Product Owner. This is the agile part of the delivery. Infrastructure is the waterfall delivery. If there are 14 Product Owners, what would the overall PO title be referred to (Parent PO?)
Thanks for sharing your question Jason. I suggest calling the overall product owner “chief product owner” if you want to continue referring to the site-specific roles as “product owners”. Hope this helps.
I’m curious to understand how you would look at a larger product area with 9-10 teams working with distinct missions, but all linking up in an overall mission of the company to “create direct relationships with end users”. All teams have the mobile app as the main channel but some of them are also releasing in the web and building internal APIs. Consequently, each team has technically quite different profiles; one working with car connectivity functions/capabilities; others working with end user features. Historically the teams have been sitting in different departments – car function teams with R&D and end user feature teams with Digital. Now my question is, would you have a PO being accountable for the app as a product or would you consider that the current team set up where each team has a distinct mission fall into your definition of team with a scrum product owner?
Thank you for sharing your question Anne-Mette. Sounds like you are faced with a challenging setup. I find it helpful to identify the actual products before I think about product ownership and assign roles. A product is an entity that creates value for users and the business, as I suggest in the article “What is a Digital Product?“. You might therefore have a Scrum product owner who owns an app in all its forms (web and mobile) and you might have a Scrum product owner who owns an internal, platform-like product that several apps might use. Does this help?
Thanks for the clear description and illustration of these PO types. I recognize that in our unit we have most of these types, but we do not explicitly call them PO. Our mayor problem is that there is only one DevTeam, hence we have at least three of those POs, but only one team. Are there any other options than hiring more developers so that for each PO a whole Scrum team (PO, SM, DevTeam) can be created?
Thank you for sharing your feedback and question Uwe. Frankly, I can’t see another option unless the development team can split into three new, fully functional teams without having to add new team members. If you can’t hire more people, you should ask yourself if you should continue to develop all three products. It might be better to focus on the product that creates the most value for the business, at least for now.
If you decide to continue with three Scrum product owners and one development team, ask the dev team to work on one product per sprint. Trying to progress several products at once tends to reduce a team’s productivity.
What’s more, I recommend discussing your question in the next sprint retrospective. Listen to the ideas and concerns of the development team members and try to reach agreement on the best way forward.
Hope this helps!
I’ve been a longtime fan of your clear descriptions & thoughts, helping me take a step back to think outside of the box and always giving me new energy to keep on going / try a new angle. Keep it up.
Specifically regarding different product owner types, I have a question for you! A gig got me interested where, instead of working directly with Developers & Product Designers (and being directly involved in user research), the job would be working with stakeholders & high level architects. The software itself would be built by suppliers with their own product team(s).
Having always had the ‘luxury’ being able to early & directly involve dev/design, they always knew early exactly what the issues & considerations were, and there were so very few surprises & differences in expectations. One concern I have is with overcoming possible “telephone issues” like in the children’s game, and being able to be agile.
This seems to be closest to the distinction you describe between strategic and tactical PO. Do you have any thoughts on possible pitfalls & some absolute baseline necessities to have a higher chance such a constellation succeeds?
Thanks a bunch! Keep it up!
Thank you for sharing your feedback and question. As you’d work with a remote team, I would recommend trying to get to know people, preferably by spending a week or two onsite. Additionally, consider how you can ensure close and trsutful collaboration with the dev team and involve the team member or at least representatives in product discovery and strategy work and in the product backlog refinement activities. The risk of the setup you describe is becoming a “distant product owner” or a “proxy product owner“, which is something you probably want to avoid.
Hope this helps and good luck!
Love your non-judgemental tone here Roman. I have seen all of these patterns as well. Problem for me is the semantics of the word ‘Owner’. Given that the collection of responsibilities of these people is heavily interdependent and nothing is mutually exclusive, none of them actually ‘Own’ anything at all. Words like ‘steward’, ‘facilitator’, even ‘manager’ are more realistic for me.
Thank you for sharing your feedback and perspective Tony. I understand that you are not comfortable with the word “owner”. Ken Schwaber apparently chose it to emphasise that the person in charge of the product must be empowered and respected. You are right, of, course: A product owner does not literally own the product her- or himself but does it on behalf of the company.
It’s a useful article, noting the different types of ways you can look at Product Ownership. I really like how you connect the Product Owner role, product ownership, and product management.
Poor practice by PO in SAFe, though, can often lend themselves to being just a backlog manager, but good POs in SAFe (of which there are a few) work exactly the same as Local POs work in LeSS.
The metaphors are interesting, but I don’t find the Microsoft Word example works very well.
As a PST, when I’m training and coaching potential POs, so many people take their experience of project management governance and assume that the senior customer is the Product Owner. Other things like the Manifesto don’t help either when they refer to the “customer” (from XP) and assume it’s the same as the reference to the “business” and Scrum’s Product Owner role. I always point out that it’s a person at Microsoft who is the Product Owner and they are the client/purchaser/user. Sometimes (and very often) the internal customer isn’t actually nor should be the Product Owner for this reason. They have no reason to nurture the product, engage with stakeholders, manage the budget as part of a Scrum (of any agile) Team.
Thanks for your feedback Matthew. I have also experienced people confuse the customer and product owner role, particularly for bespoke products. I wrote an article called “2 Common Ways to Apply the Product Owner Role” that tries to address this challenge. Hope you’ll find it helpful.
I’ve seen the SAFe product owner being described as a more cross-team/-product role than the scrum-specific product owner. The SAFe product owner in scaled agile is working across a set of products and aligning the scrum teams – whereas the scrum product owner is dedicated to one team/product. I’m curious why it’s the other way around in your post?
Thank you for sharing your experience and question Joanna. I have based my description of the SAFe product owner role on the official SAFe documentation and how I have seen the role being applied. Based on what you told me, it sounds to me as if the SAFe product owner role was used as a team coordinator or project manager rather than a role that owns the product details.
Definitely a serious problem with a company moving to use scrum and other agile methodologies. I have been a Product Owner, though based on this information I was more a Platform Owner. In my current role I sit closer to being a Portfolio Owner. I will eagerly take this to my colleagues for discussion. Thank you.
You’re welcome and thank you for the feedback William. I am glad that the article was helpful!
Fantastic! I will have some difficulty getting my client to change the role titles but having this model in my head helps clarify the value of the different roles encompassed in the Product Owner title. I appreciate you reinforcing the Scrum Product Owner role is not merely a “product backlog manager” as some others in the field seem to think. Which of the roles you describe align with that type of role?
Thank you for your feedback Dana. I am glad that you found the article helpful. Out of the six roles describe, the SAFe product owner comes closest to a “product backlog manager” in my mind. Hope this helps!