Who is the Product Owner?

The Product Owner, also known as the PO, is the person responsible for ensuring and maximizing the value of the product generated from the work of the Scrum Team in order to satisfy the needs of customers and users. The Product Owner is just one person. She has the authority to make decisions involving definition of the product, but always aligned with the Product Goal. With Scrum, a product is defined incrementally throughout its development.

The Product Owner, together with the Scrum Master and the Developers of the product, make up the Scrum Team.

To carry out his work, the Product Owner:

manages the definition of the product, which includes inserting, detailing, removing, ordering, and bringing transparency and clarity to the items in the Product Backlog throughout the product’s development, in order to maximize the result of the Scrum Team’s work. The PO can conduct this work alone or delegate, even if in part, to the Developers or to others, while remaining accountable for the results.
manages the relationship of customers and other stakeholders with the product’s development, understanding who these people are in order to influence decisions regarding the product, balancing their needs, communicating with them to help discover those needs and influencing them to maximize their collaboration in developing the product.
ensures the Product Goal, defining it with the business, the product’s customers and other stakeholders or aligning with what has already been established, communicating it to all those involved and ensuring that the work is done in order to realize it.
manages the product releases, defining its goals and the best strategy for carrying out these releases.
participates in the Sprint during Scrum events, planning the Sprint with the Developers at the Sprint Planning meeting, presenting, and obtaining feedback from the customers and other stakeholders at the Sprint Review meeting and participating in the continuous improvement process at the Sprint Retrospective meeting.
Collaborates with the Developers whenever necessary, being available to clarify any doubts and make decisions regarding the definition of the product and, with them, refine and prepare the Product Backlog for implementation, as needed and when possible.

The Product Owner is:

unique for a Scrum Team, as there should be only one focal point for the Developers regarding decisions on the product.
available to collaborate with the Developers, be present at Scrum meetings where attendance is mandatory, interact with the customers and other stakeholders and maintain and order the Product Backlog.
competent to define the product, with sufficient knowledge and empowerment to make quick and appropriate decisions, aiming to optimize the value of the work being performed by the Scrum Team.

Discussion: where does the Product Owner come from?

Choosing as the Product Owner the product customer itself or someone designated by that person is an option adopted by many organizations and advocated by various Scrum experts. In this scenario, the Product Owner will define the product to be developed based on her own needs or who she directly represents – that is, whose problems are expected to be solved. Naturally, this choice seeks to ensure that the Product Owner has mastery of the business and the context and will make product decisions that favor the actual customer.

Experience shows, however, that this is not the best option in numerous cases. In fact, I’ve seen many failures occur as a result of this choice, especially when dealing with an external customer.

Based on our experience, we defend that the Product Owner should, in principle, be someone close to the teams that will develop the product. Hence in the case of an external customer, the best choice would be someone from the vendor itself.

To justify this opinion, I argue that being a Product Owner involves an accountability that requires several factors:

Great knowledge of the function and rarely will someone from the customer know how to perform it — In most cases the customer simply does not have the necessary skills and knowledge, which necessarily include knowing how to define the product in an iterative and incremental manner, in addition to mastering the Scrum framework itself. This problem is more common and more serious than it may seem. Nevertheless, many argue that to resolve this issue, the Scrum Master could teach the Product Owner whatever is necessary, perhaps with the support of specific training. This investment of time and money in such a complex and specific training, which encompasses a series of skills, knowledge, practices and, often, a major change in culture, is only worthwhile if the person trained as a Product Owner begins to act with that accountability on a permanent basis. Therefore, it could make sense to train someone from the requesting area as a Product Owner in the case of an internal customer.
Discovering and understanding existing problems, rather than beginning with desired solutions — An external perspective, somewhat like that of a consultant, makes this work more viable. On the other hand, customers are normally immersed in the context of their problems and usually does not identify them clearly, rarely being able to know what they really need, or understand that it is actually a discovery process. Because of this, it is not uncommon for customers to offer “done” solutions to problems that they do not yet understand, causing the Developers to carry out implementations that do not deliver much value. And to boot, which customers do you know that understand how to prioritize? Everything is a priority, isn’t it? Thus, in this sense, the Scrum Team can do exactly what the customer asks, but that customer in the end will not be satisfied.
Availability and collaboration — Even if this Product Owner of the customer has the necessary knowledge and skills, it is quite possible that this person does not have the necessary available time to assume this accountability, as they will probably be more involved in other matters of their own day-to-day work in the customer’s company. In addition, their relationship with the Developers may become based on demands, not a collaborative one as we would expect from members of the same Scrum Team. The result can be a Product Owner who interacts very little with the Developers, who doesn’t trust them enough to delegate, who demands from them instead of collaborating, who is possibly not present at Scrum meetings where her presence is required (and is often not even wanted there by the Developers) and who can’t dedicate the time needed to think about the product and refine the Product Backlog.
Balance and politics — When a product has various customers or different stakeholders, and who may even belong to different organizations, the inadequacy in choosing a Product Owner from among them is clear. There can only be one Product Owner in the Scrum Team and, therefore, the customer who is chosen as such can make decisions that favor them over the others.

Due to all these reasons, for the vast majority of cases I strongly recommend that the Product Owner originates from the side of whoever is developing the product, especially in the case of an external customer. And it should be someone trained as such, with the necessary skills and knowledge. The PO will carry out the work based on frequent contact with the product’s customers and other stakeholders, balancing their needs while making decisions in line with the goals of her own organization.

It is important to note that in order to be a Product Owner, this person should have the authority to make the necessary decisions regarding the product. That is, even if it is not someone from the customer, the Product Owner is always the person who is actually accountable for defining the product.