Six Types of “Product” Owners [Roman Pichler]
Overview
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.
To get a more complete picture of the Scrum product owner role, take a look at my product owner guide:
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. In the agile scaling framework LeSS, the role is referred to as “Area Product Owner“.
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 team, a group of product people who collaboratively manage a larger product. The product 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.
Note that the Scrum product owner in the picture above is sometimes also referred to as Chief Product Owner, particularly when feature and component owners are called “product owners”. While I have applied this approach in the past, I now consider it not helpful, as a Scrum product owner should own a product in its entirety.
Platform Owner
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 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.)
Portfolio Owner
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.
Summary
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.
The post Six Types of “Product” Owners appeared first on Roman Pichler.
Source: Roman Pichler https://www.romanpichler.com/blog/six-types-of-product-owners/
Post a Comment