Dieser Blogpost ist auch auf Deutsch verfügbar

Ask two teams what a Product Owner is, and you will get three opinions. It would be hard to find a development organization that has not implemented this role. Nevertheless, opinions concerning the actual duties of the role diverge widely. There have even been attempts to further differentiate the role in order to take these diverse perspectives into account. Examples include Proxy Product Owner, Component Owner or Portfolio Owner.

Instead of assigning different roles, I would rather focus on the context in which the Product Owner is active. After all, there is no single definition for this role.

Core duties

The role of Product Owner originated in the Scrum Guide. It is quite popular today and can be found in many organizations. Many articles have been written on the question of what a Product Owner actually is. Other frameworks, such as SAFe, have now also taken up the name and established their own definitions.

But does the attempt to achieve a conclusive definition even make sense? How about the attempt to further differentiate the role? I don’t think so. Nevertheless, it is still important to remember that not all Product Owners are the same. It is unavoidable that different contexts require different duties and skills for this role. That’s why the best answer is: “It depends!”

Taking the definition in the Product Owner section of the Scrum Guide[1], the core duties are as follows:

This role is also responsible for realizing and maximizing the product value.

The guide goes on to offer some relativizations, resulting in plenty of room for interpretation.

In his article Six Types of Product Owners[2], Roman Pilcher describes the following roles:

The problem is that none of these terms have a standard definition. Every organization has its own vocabulary.

In day-to-day business and when speaking with customers, it can be hard to work with these terms because:

For these reasons, I prefer to consider the role within the framework of the relevant context. I accept here that a name can have different definitions. The definition only exists within a specific context. For my purposes, I have defined a number of different “drawers.”

Drawer 1: Market product

Let’s open the first drawer. What we find here is a digital product. Specifically, one that customers pay for.

Examples of revenue types:

Julia takes on the Product Owner role for this drawer. She will invest a great deal of time trying to find the “product market fit.” This refers to the point where the product satisfies a strong market demand.

Key areas:

Julia is a lighthouse for her team. She indicates the direction but not the exact path. She will focus much more on milestones than on individual requirements.

It is also possible that she might create the odd user story for her team. It is more likely, however, that she will manage and order the backlog at an abstract level. This could be epics, features or themes. However the hierarchy is structured, she will be primarily focused on the strategy.

Julia will need support to identify backlog items that can be implemented. This can be provided by a Product Owner Team. There may be people there who focus on user experience. Or there may be people who focus on legal topics. This gives rise to implementable backlog items. In this case, the development team will have to interact with multiple people here. Or it could take on these duties itself. Of course, that only works if the team includes the necessary skills.

If we take a look at the job postings at Indeed and similar sites, one thing quickly becomes clear: Not many companies are searching for such a profile under the title of Product Owner. The descriptions often more closely match the Product Owner role from the SAFe framework. The role is very tactically oriented there. Portions of the described activities then tend to fall upon the Product Manager. This means that the duties assigned by Roman Pilcher to the Scrum Product Owner are split in SAFe between the roles of Product Owner and Product Manager.

I assume that most organizations would use the title Product Manager for the role I describe in this drawer. But there could still be someone who is explicitly called a Product Owner. The key areas would then resemble those from one of the drawers described below. That means we can close this drawer now and open the next one.

Drawer 2: Enabling product

The next drawer squeaks a bit when we open it. The meaning of the term might not be immediately clear.

I use enabling product to refer to software that paying customers come into contact with but that they do not actually pay for themselves. Such software is a touchpoint for the customer and not the product.

I have borrowed the term “enabling” from the SAFe framework. Paraphrased somewhat, this framework describes the term as covering activities that are required for achieving the goal but are not part of the product itself.

An esteemed colleague I used to work with had a habit of asking project managers: “So, are the firewall rules already included in the timetable?” I consider setting up firewall rules to fall under the category of enabler.

I have expanded this somewhat by combining it with the term product. In this way, I mean to describe something that customers are aware of but do not directly pay for.

Examples:

The following are the products that customers actually pay for:

In our example, Heribert is taking on the role of Product Owner for an “enabling product.” He supports the “market product.” He tends to be focused on a specific part, such as the check-out function of a web shop or the module for submitting complaints in a self-service portal. He is able to make many decisions on his own here. However, his budget has been allocated to him by others or at least depends on overarching budget plans.

Many strategic topics are handled by someone else, and Heribert will support them in this. This makes his work more tactical in nature. He has a number of internal stakeholders with whom he must coordinate decisions. This could include the Product Manager or the person responsible for the entire IT landscape.

Key areas:

Within the team, Heribert also handles some analysis tasks and writes some backlog items himself. He personally takes part in the regular team meetings. However, he does not have time to describe all the requirements conclusively. Here therefore needs support from the team.

This could take the following forms:

Drawer 3: Internal service

Internal services are the backbone of many company processes. I also like to refer to them as back office software. This is the software responsible for employee administration, order control and financial accounting.

Sometimes this is standard software, sometimes custom developments. In some cases, we even see hybrid situations in which software is purchased and then adapted.

Examples:

Compared with an enabling product, this topic extends deeper into the organization. Legal perspectives notwithstanding, the stakeholders are largely people within the organization itself. This software typically does not represent a touchpoint for the paying customers.

For our purposes here, we assume that the software is a custom development.

Marie takes on the Product Owner role for an internal service.

The Product Owner role could also be held by someone on the business area team, called “Lead User” in the Scrum Guide. While everyone on the business area teams is happy to contribute to the vision and provide information and ideas, they often lack the time and necessary experience to handle all the activities involved.

This applies in particular to proper documentation of the requirements.

Marie supports these persons. She acts as a business partner to the representatives of these teams. Her job is not to issue requirements directly. Instead, she investigates the requirements and offers her own suggestions for the indicated problems.

Requirements engineering is her primary activity.

Only rarely are people available who are specialized in disciplines such as user experience design and UI design. Marie therefore supports these disciplines as best she can.

Key areas:

Marie works closely with the team on a daily basis. She is almost always present and even involves herself at times in the details of implementation.

Summary

The Product Owner role can be found in each of these drawers. However, the associated responsibilities and therefore also the focus of activities differ.

Figure 1 attempts to provide a weighting of the various areas of activity between the different contexts.

Figure 1: Weighting of the activities of a Product Owner
Figure 1: Weighting of the activities of a Product Owner

Julia (market product) will presumably bear the internal title of Product Manager. She is focused on the vision and the go-to-market. Her product expands the portfolio of her company. Market analyses and metrics are her most important tools. She therefore serves as a lighthouse for her development team; the exact details or even detailed backlog items are not expected from her. Experts in UX and business analysis support her here.

The situation is quite different for Heribert (enabling product). He gets deeper into the details and also focuses on organizing the backlog down to the level of individual backlog items. He must develop a clear goal for his product that fits with the vision. He frequently provides support for market-oriented activities, which are Julia’s area of focus, or he must adapt these for his own product. As a result, he does not have enough time to concern himself with all the details of the requirements and the backlog. He relies here on assistance from the development team. Perhaps he can also call upon experts in UX and business analysis.

Marie, on the other hand, is deeply immersed in the operational activities and juggles the backlog on a daily basis. She is the bridge between the business teams and the development team. Within a clearly delineated field of activities, she ensures that the business area teams are satisfied with the product. Here she serves as much more than a proxy. She is a partner to the business area. She regularly engages in negotiations concerning profitability and staying within budget.

All three have the same role on paper and require significantly overlapping skillsets. And yet there are also important differences. Could Marie and Julia do each other’s jobs? Presumably not, and both would have things to learn due to the different tasks involved. Depending on the nature of the product that the two “own”, they may need strategic skills or entirely operational skills.

In summary, then, it can be said that my duties and focus as a Product Owner depend heavily on the context. Keeping this in mind is an essential part of fulfilling my role.
If I am hired for an internal service and do not conduct myself accordingly, conflicts are (justifiably) bound to arise.

Acknowledgements

Thank you very much to my colleagues Lena Kraaz, Jan Körnich, Michael Schwarz, Joachim Praetorius, and Rebecca Temme as well as my former colleague Simon Dünhöft. I am grateful for their thorough proofreading and their excellent suggestions, remarks, and criticisms.

List of references

  1. Schwaber, K. & Sutherland, D. (undated). The Scrum Guide [Guide; PDF]. scrumguides.org. https://scrumguides.org/docs/scrumguide/v2020/2020–Scrum–Guide–German.pdf  ↩

  2. Pichler, R. (28 April 2022). Six Types of Product Owners. Roman Pichler. Accessed on 9 January 2023, from https://www.romanpichler.com/blog/six–types–of–product–owners/ (Original work updated 2022)  ↩

TAGS