The term product owner is commonly used to refer to six different product roles in my experience. These are:
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 picture 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.
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 jobs. But you can think of the product owner as an agile product manager, as I explain in the following video.
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.
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 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 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.
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 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 to a certain extent, 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 successfully 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 and role names. It’s the good we do for the users and our businesses.
The following infographic summarises the six roles. Click on it to download it.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
Hi Roman,
How would you divide responsibilities with ITAM, IT asset management? For example, I, as PO, have a contract with Microsoft for the licenses of M365 apps (Word, Excel, PowerPoint, Visio etc). But the ITAM process owner manages the software assets. Is the process owner working for me? Or am I working for him and should I transfer the contract with Microsoft to him?
Kind regards,
Eveline
Thanks for sharing your question, Eveline. I would regard the ITAM process owner in your scenario as a stakeholder and member of the (extended) product team. If other products also rely on Microsoft 365 licenses, then it would make sense to manage them centrally. This might be done by the ITAM process owner, as you suggested. Hope this helps!
Hi Roman, have you ever had the chance to talk to Marty Cagan about your typification of Product Owners?
Hi Andi,
I've met Marty Cagan, and I am aware of his views on the product owner role. While his work and mine are aligned in many ways, I disagree with his take on the product owner role. I believe that it is based on how he has seen the role applied rather than how it is intended. Admittedly, the product owner role is often misunderstood and misapplied, as I write in the article. The same can be said of the product manager role, though. But this does not mean that the role per se is wrong or ill-conceived. I discuss the two roles in more detail in this video: https://youtu.be/dagL0eO7AkA Hope this helps.
Hi Roman, thank you very much for your feedback. I was hoping you hadn't had a chance to talk to him yet. And if you ever met him, you could convince him of your way of thinking 💪.
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!
Tanya
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.
Hi Bob,
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!