What are the main responsibilities of a Product Owner, what makes this role so problematic and how should it be designed to make an agile transformation successful?
The first thing that often comes to mind for organizations that want to introduce agile working and Scrum as a method is filling the roles. We have already discussed elsewhere that agile work means much more than filling roles, introducing sprints and meetings and that many organizations, unfortunately, reduce agile work to these things and stop here. Read more about this topic here.
But the first problems come up when defining and filling the roles, which – if not addressed early on – will have far-reaching consequences for the entire process.
The most problematic role is undoubtedly the role of the Product Owner.
First and foremost, most organizations think it is the role of the Scrum Master that is particularly difficult and deserves all the attention. This is why Scrum Masters are usually sent to various agile trainings or are sought after on the external market, while Product Owners often fall through during the preparation phase.
I don’t want to belittle the importance of the Scrum Master’s role – both are absolutely equivalent in their nature, but compared to the role of the Product Owner, it has more acceptance and clarity right from the start.
But what is it that renders the role of the Product Owner so problematic and how should it be designed to allow an agile transformation to succeed?
In order to understand this better, let’s start with a few basic considerations about the understanding of roles in Scrum and how to classify these roles in the organization. Scrum is limited to three roles, the Product Owner, the Scrum Master, and the Development Team.
By doing so, Scrum breaks with the fine tradition of project organizations of constantly inventing new roles. In addition to the classic project manager, PMO and architecture roles, there are often implementation managers, release and test managers, people responsible for maintaining high spirits or coffee making, etc. This may somehow make sense for project organizations and be well adapted to the circumstances of the project.
Nevertheless, Scrum takes the exact opposite approach and limits itself to exactly three roles, independent of all project conditions.
This is undoubtedly a change of perspective or paradigm shift. This can actually only be explained by the fact – and this is also a frequently asked question, which has a lot to do with the introduction of the Product Owner role – that Scrum is not a project management method in the true sense.
Scrum is more of an implementation method. I have been following this discussion for quite a while now, and I have noticed that there is a bit of a divide. Some see Scrum as a project management method, others don’t. Even in the SAFe Guide you can find in some places that Scrum is seen as a project management method, with criticism that Scrum itself does not scale.
By the way, Waterfall was never perceived as a project management method, so why should Scrum be one?
For the understanding of the role of the Product Owner, this observation is very important, even if it cannot be seen at first glance. So let’s take a second look and ask the question again – this time from a different perspective – what makes the role of the Product Owner so problematic?
First of all, it’s a problem that nobody knows them. In the past, this role simply did not exist in organizations.
This is also true, or maybe even more so, for the role of the Scrum Master, but it is still so new and so different, and it is due to the new method that it is much easier to accept (which unfortunately does not automatically mean that the people who take on this role are easily accepted, but that is a completely different matter).
The role of the Product Owner becomes truly problematic because many organizations think they know what it is all about. For some organizations, the role is very close to that of the classical business analyst, for others, it is similar to that of the classical architect.
Both are simultaneously wrong and correct – and I don’t mean slightly wrong or slightly correct, I mean it is entirely wrong, even though it is somewhat understandable.
First, we will take a quick look at the three roles in Scrum.
However, we’re not interested in the definition of the roles, but in their number. There are three, there are only three and there will always be only three. This circumstance is often given little attention in organizations, but it has far-reaching consequences.
This is because if the implementation of a project (not the whole project itself, Scrum is “only” the implementation method) – no matter what size and complexity, no matter what technology, no matter what organization and in what setup – is based on only three roles, then one thing is clear from the start.
The roles are so charged with responsibility and at the same time filled with tasks and responsibilities and must be so perfectly coordinated that no negligence of any kind can be afforded in defining the role and its positioning within the organization.
Or every little bit of negligence will sooner or later cause great consequential damage to the project and those that are not immediately visible will be the expensive ones.
Indeed, this applies most of all to the role of the Product Owner. First of all, no one knows the role, which means that errors do not become visible quickly, not even serious errors or shortcomings. Secondly, it is in any case difficult to prepare people well for this role, as we will see in a moment.
And finally, my experience from dozens of projects has shown me that a Product Owner alone decides on up to 50 % of the overall team performance, just by the way they write the stories and prioritize them. A Product Owner can bring down a project entirely with a few (wrong) steps. They bear an enormous responsibility which can rarely be delegated.
Now let’s talk about the role itself and what skills are necessary to be a Product Owner. And again we start with a negative example, because I have seen this repeatedly in several organizations. And because I don’t believe in coincidence, I see the reason for this in the above-mentioned struggle of organizations to correctly position the role of the Product Owner in contrast to the business analyst or the architect.
I often see one of two variants.
In one variant a Product Owner is determined, and they are supported by business analysts who are part of the Scrum team.
As Scrum teams are by definition supposed to be cross-functional, this is not considered a problem at all, but the organization believes that it is acting in the best agile sense.
In the second variant, the business analyst is made a Product Owner, because the basic understanding is that the Product Owner is responsible for requirements engineering and stakeholder management. Business analysts are used to precisely this and are therefore predestined for this role.
Both variants are wrong, albeit somewhat understandable or even reasonable or obvious at first glance. But at second glance, both variants have fatal consequences.
There are, of course, other variants in which, for example, architects are made Product Owners or the Product Owner role even encompasses several people – business analysts as so-called “technical Product Owners” and architects as so-called “technical Product Owners”, although I do not want to go into all of that here.
The first two variants are enough to clearly explain the role of the Product Owner. From this, it is easy to see why such additional variants are not good or even completely absurd.
In order to understand why I consider the first variant to be no good, let’s take a look at the general development process. Roughly put, it looks like this:
Business process (functionalities) -> functionality (product features) -> technology (implemented executable version).
First of all, a business process is described. This is done at the organizational level, either as part of a demand management process or immediately afterwards. If the organization has decided to implement this business process, the functionality is already described as part of the implementation. And this is precisely the task of the Product Owner. Afterwards, the functionality is implemented by the Development team.
The business analysts are the ones – if they still exist in an agile organization – who analyze and describe the business processes. This in itself can be a highly complex process, depending on the topic. At a large bank that wanted to introduce the ApplePay business process in its mobile app, for instance, the business analysts had to spend several months checking all general conditions for the introduction of this business process:
Once the organization is prepared for this, terms and conditions have to be changed, and several questions have to be answered: who bears what responsibility, how is this reported to the German financial authorities, what risks does the bank bear, etc.
These are all questions that initially have nothing to do with the product. Business analysts prepare the topics that are later cast into functionality. This means that they work on an organizational level and not in a Scrum team. If they stay in the Scrum Team, a part of the team would always work asynchronously, because they are supposed to prepare future topics, of which it is not always clear if they will even be included in the product. It also becomes difficult to keep the team size small and often they will be the ones writing the stories instead of the product owner.
This brings us to a key task of the Product Owner. They are the link between the project organization with its stakeholders and the Development team, implementing the product. They are the “owner of the product”, not of the business process.
It describes the functional requirements of the product and not the technical aspects of the business process. What matters here is the distinction between technicality and functionality. This is because the functionality must not only implement the business process but also take into account many other factors, such as non-functional requirements, compliance requirements, governance, security, etc.
The Product Owner acts as a kind of liaison for the customer.
They represent the interests of the stakeholders in relation to the desired business processes, but also the interests of their own office, i.e., their development team. They will therefore set the functionality in such a way that the business process is well implemented, but the software remains maintainable and can be created with manageable effort.
Everyone who has ever had this role knows how much you have to compromise all the time. In the function that I outlined here, the Product Owner is responsible for maximizing the value of the product. Again, this should not be confused with maximizing the value of the business process.
Now we turn to the second variant. Appointing the business analyst as Product Owner is also not a good idea. This is because the role of the business analyst remains important at the organizational level.
And as I’ve just demonstrated, the Product Owner works on a completely different level, namely on the product level and not on the business process level.
Product Owners already have plenty to do with stakeholder management and the transformation of all requirements into functionality and the establishment of effective communication between all parties involved.
If they are required to familiarize themselves as deeply as possible with the business processes, their original tasks will regularly be neglected. The software is designed too feature-heavy and builds up a lot of technical debt, or the teams are no longer optimally supported, at the expense of velocity.
To summarize, here are the main responsibilities of a Product Owner:
The Product Owner plays a pivotal role in ensuring that the development team thoroughly understands the client’s or stakeholder’s vision, aligning everyone toward a common goal. This involves effective communication, clarification of requirements, and the nurturing of a shared understanding of the project’s objectives.
To keep the product competitive and relevant, the product owner continuously evaluates its performance, monitors user feedback, and identifies areas for improvement. By strategically prioritizing these enhancements, they help guide the development team in making informed decisions that increase the product’s value and usability.
The Product Owner takes charge of the product backlog, which is essentially the to-do list for the development team. They are responsible for keeping this list organized, updated, writing a detailed description of each task and ensuring that the most important and valuable tasks are at the top. This ensures that the team works on the right things at the right time.
Collaboration with stakeholders is essential in shaping the product’s roadmap. The Product Owner actively engages with stakeholders to understand their needs, concerns, and expectations, using this input to create a comprehensive and actionable plan that addresses the project’s goals and aligns with the organization’s overall strategy.
The Product Owner acts as a liaison, fostering effective communication between development teams, business stakeholders, and other relevant parties. By maintaining open channels of communication and ensuring that information flows smoothly, they facilitate a collaborative environment that supports the product’s success and alignment with the broader organizational objectives.
This consideration leads us to the next central aspect of the role of Product Owner. Communication. I have described the role of communication in the agile process here as a “mutual invitation into each other’s reality”, i.e. as an essential transfer process of product visions into technically implemented features in the shortest possible time.
they must succeed in getting his product vision into the heads of the members of their development team as quickly as possible, so that they can develop the most complex system immediately and in small packages in short iterations.
This means that they do not have to be an expert in the business processes, nor an architect who knows the technical architecture of the application in great detail. They must, of course, have access to both – and some others as well – and they need to know the functional architecture of the application.
So, it would be good if they know what software is and how it is fundamentally structured, because that is the object they describe. But from a functional perspective, not a technical one.
In order to be able to do all this, they need a few basic conditions. And these conditions correspond to the description of the role as listed in the Scrum Guide. They alone are responsible for the product backlog, i.e. for the content and order of the backlog items, no matter if they are user stories (features), enabler stories (technical debt ), bugs, or other tasks.
They cannot delegate this responsibility, but they can certainly enlist help, for example when assessing technical debt. Above all, the Development team should be able to provide sound advice, which is why communication is so important, i.e. the transfer of the product vision to the awareness of the team members. Because only if they understand this vision well, they can provide him with competent advice, and they can all work together to develop this vision in the product and bring it to life.
Why we should not mix agile and classical project management – or why traffic lights are not helpful at roundabouts.
With the WSJF technique, prioritization and PI Plannings become damn easy, highly effective and even fun! Step-by-step guide and free WSJF Excel template
Scrum vs. Waterfall – For all Scrum fans, let’s get the bad news out of the way: Scrum is just a compromise. The good news is that this is the only piece of bad news.
For scaled agile organizations it is frustrating when their project management tools don’t support their processes.
That’s why we developed scagile as an app which actively supports agile best-practices with features you haven’t even thought about and with which you’ll be able to create value flow across your entire organization.
