Have you ever worked in a team where you felt that everyone was telling you what to do, that everyone had conflicting requirements, and that they all kept changing their minds? You felt the pressure of moving from one thing to another and back again. The Project Manager looked worn out trying to manage all of these dependencies, decision-makers, and other project managers. The accountability of the Product Owner was created to provide a clear and simple set of responsibilities for a Scrum Team to better manage that. Of course, the challenges still exist, but at least you have the protection of the Scrum Framework to make progress in an orderly and structured fashion. Well, that is the dream of Product Ownership. And, it is a message we push heavily in our classes, materials, and assessments. The idea that a Product Owner actually owns the Product allows the team to follow their vision and direction. It reduces complexity by providing a single, focused individual who determines what is valuable for the team to work on and what is not. They are accountable for the value the team delivers and stakeholders get to see this at the end of each Sprint. If the investors in the team do not like the direction then they can provide feedback. If the team and the Product Owner do not take that feedback they can, ultimately remove funding, etc. But we hope that making progress, and transparent value means that this rarely happens. Additions to the Scrum Guide in 2020 of the Product Goal and more clarity on planning made the focus on value and outcomes even more explicit.
But many people inside and outside of the Product community find the idea of a Product Owner challenging and have many legitimate concerns such as “how can one person make all the decisions for the Product?”, “Doesn’t this disempower the team?”, “How does this work at scale?”, “What is this person called?”, and other concerns that focus on relationships between the team, customer, and other stakeholders.
Let's take a moment to review those concerns and try and answer them, or at least give my perspective having seen Product Ownership practiced in 100s of organizations.
How can one person make all the decisions for the product?
Building modern products is a complex job. The blend of design thinking, business knowledge, technical knowledge, market context, and even legal and regulatory requirements make decisions complex. And for complex products, it is impossible for one person to know everything. But that is the power of Product Ownership, not the ability to know everything but being able to ask questions and make decisions based on a clear idea of the vision and outcomes the product has. From my experience, some of the best product people are not the most knowledgeable but are the most inquisitive with a good idea of the why. They shape their understanding of the context of why the team is there, funded, and focused. They challenge stakeholders including HiPPOs (Highly Paid People with Opinions) to justify their position based on the context of the why. They focus on outcomes, driving to measurable events that can help shape the direction of their work. They also care deeply about the people that the product serves. Ultimately the Product Owner needs to own the vision of the product and be able to translate that vision into clear goals which then, by working with the Scrum Team become incremental steps as described in Sprint Goals. And the people who fund the Scrum Team have to be OK with the Product Owner taking charge of the vision. Of course, they get input, but they have to trust the Product Owner to be championing the vision they have paid for. If they do not trust that person then they have to become the Product Owner.
Doesn’t Product Ownership disempower the Scrum Team?
There is a myth that the Product Owner is the sole person who talks to customers, makes product decisions, and understands the business. In the most effective Scrum Teams everyone is engaged with the problem which requires everyone to be responsible for learning about customers, the business, and the environment the product is being used in. There is no Product Owner bottleneck. Yes, the Product Owner will set guardrails around the direction the product is going, but they can not and should not make every little decision that is required to deliver the Product Goal. That means that the Scrum Team works together to uncover requirements, understand the users, appreciate the desires of the people funding the work, and do what is required to deliver on the Product Goal or challenge its relevance. They work with the Product Owner to make sure that their work is supporting their vision asking questions and challenging where necessary.
The dirty truth is that sometimes the work is not the most efficient with team members working in areas that they have no prior knowledge of, but the great thing about Scrum is that everyone works together including the Product Owner to help transfer knowledge and provide support. And often that lack of prior knowledge helps ask the questions that should be asked to challenge the status quo and find unique innovative solutions. Sometimes the innocence and naivety of the person doing the work is actually an opportunity rather than a problem. But this will only be the case if the team is operating in a ‘safe’ place where mistakes and being to say “I do not know” is encouraged and supported.
What is this person called? What is their job title?
I do think there is some irony in how organizations that want to be agile also want fixed job titles with clear career paths and defined skill lists. Surely the objective of an agile organization is you have a set of people who have some skills but also a willingness to learn, do other things and be able to work outside of their comfort zone. However, I appreciate that people need job titles, salary structures, and promotion models. So should the person performing the accountabilities of a Product Owner be called a Product Owner?
They can be, but it is clear that the Product Owner description in the Scrum Guide is not enough to define their job or provide a description of their career path. Ultimately the job title is defined by the organization, it can be Product Manager, Product Owner, Business Analyst, Claims Manager, Support Operations Manager Chief Medical Liason, or others. I have even seen a Vet take on the accountabilities in an animal hospital that was using Scrum. The important part of the job is not the title but the accountabilities and often reporting structure. A Product Owner will find it MUCH easier to do their job if they have the accountabilities of the Product / Outcomes / Value Stream / Service / Platform (etc) they are owning. They also will find it much easier to do their job if the person who really, really, really cares about this Product being effective and funds the work is the person they report to. So in the case of many IT organizations that means the person doing the Product Ownership should report to the business that uses the systems. Of course, there are examples where, because of the number of stakeholders it is important to do the opposite, but on balance by having that clear reporting line the Product Owner can get more attention and more success.
Do you still need a Product Owner if you have not got a Product?
The 2020 update to the Scrum Guide made the definition of Product very flexible.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
So technically as long as the work has a clear boundary, stakeholders and value can be measured, clearly, anything can be a Product. The key to success is clarity coupled with a clear understanding of the customer and access to them. The more disconnected from the customers and less clear in terms of boundaries, the harder it is to use Scrum and thus harder for someone to deliver on the accountabilities of the Product Owner.
The reality for many organizations is that they are using Scrum on projects. The projects are a collection of work that serves many customers, and the Product Owner is really just a Project Manager or Business Analyst for the work. Scrum can still deliver value in these circumstances and can be a great tool for better planning work, ensuring progress is made more frequently and even getting better stakeholder engagement. However, you are losing the benefit around innovation or at least outbound customer value innovation. Also, often in these situations, the team is part of a much larger program with heavy dependencies across teams. This leads to challenges in getting real, value-oriented work Done. It also means that there is a massive overhead required to ensure that each team is not breaking the other team's work, or waiting too long for work. Integration becomes complex. Nexus provides some ideas for how you can better align teams and also describes the need for only one Product Owner. However, the challenges with complex projects and the use of Scrum are greater than I can address here.
The bottom line is that even in situations where the Product is a very loosely held reality, the power of the accountabilities of the Product Owner holds true. Simplify decision making, have a clear vision, define a Product Goal, focus on value when deciding what to do next and at all times make things transparent so that everyone including Stakeholders can provide input to help make course corrections.
I have only touched the surface of the challenges of Product Ownership, but the simple idea can provide much clarity and focus for a team. Product Ownership also, if done correctly, can be a great mentor and coach for an organization to become more outcome and customer-focused.