I spend a lot of time talking to organizations that have been using Scrum for years, sometimes decades. Those organizations are wrestling with the complexities of scaling agile ideas, dealing with transformation fatigue, and considering what is next. Those conversations often revolve around the Agile Product Operating Model (APOM) and how product thinking, alignment, and funding can provide a foundation for delivering more value and managing uncertainty.
But there is another situation I also talk to people about: someone has told them to do Scrum, and they need a Product Owner. And, because I am the Product Owner of Scrum.org they reach out to me, and we start chatting.
And these conversations are in part the backdrop for the launch of a new self-paced course, Professional Scrum Product Owner Fundamentals. This course provides the fundamentals necessary to understand how to be a Product Owner, which you can then validate with an attempt at the PSPO I certification.
The first surprise in these conversations is the MAJOR confusion about what a Product Owner should do. Often, these people do not have the job title of Product Owner or even Product Manager, but instead are an expert in the problem domain (think business analyst or subject matter expert), a project manager tasked with getting the work completed, or a department manager.
That is often the first part of these types of discussions. Scrum defines accountabilities, NOT job titles. Job titles are often unique to your situation and organization, but to use Scrum, you need someone to take on these accountabilities. Product Owner is actually a set of accountabilities grouped under one person. Scrum Master is another set of accountabilities; together with Developers, they make up the Scrum Team.
OK - once we have discussed the whole job title/career path debate, we move on to what the Product Owner does.
The Scrum Guide Definition
In a nutshell, the Product Owner is accountable for maximizing value. The Scrum Guide puts it very nicely as:
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
The following sentence particularly takes me: "The way it is done varies greatly." Each situation is different and requires a different approach by the Product Owner. This can annoy people as they want a blueprint or transparent process for how this accountability is realized. Welcome to the club! I would love that too. But as the Product Owner at Scrum.org my playbook is ever evolving and unique to me. For example, there is no guidance on how to work with the co-creator of Scrum in the Scrum Guide :-), or on managing feedback from a large group of experts who have very different views on what is valuable or not.
The Scrum Guide does provide some more practical accountabilities of the Product Owner pertaining to the Product Backlog:
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating the Product Backlog items;
- Order Product Backlog item; and
- Ensuring that the Product Backlog is transparent, visible, and understood.
So, in a nutshell, they are managing the Product Backlog. That does not mean they do all the work, or are the only people who can enter backlog items. They are accountable for the Product Backlog being as good as it can be, with clear goals, well-defined items, and, of course, the items in the correct order. To do this well, the Product Owner needs to do lots of things, and those things are at the heart of Professional Product Ownership.
Vision, Value, and Validation.
To deliver value sounds much easier than it is. It requires a clear sense of why something is valuable. It also needs a clear understanding of what value means. Value is subjective, and that means understanding it in the context of people's perceptions. To provide clarity and evidence of value, it also needs to be tested. And those three ideas form the basis of how Scrum.org teaches the fundamentals of professional Product Ownership.
- Vision - Provide clarity on where the product is heading, allowing Scrum Teams and stakeholders to understand the context for the work that is being done
- Value - Understanding how value is defined and understood by the stakeholders and users of the product
- Validation - The necessary work required to validate the assumptions, risks, and ideas about value
These three Vs provide clarity on what actual Product Ownership means. Because of the complexity and environmental instability of most products, one person is accountable for them. Some organizations, for example, split the strategic planning of vision and value from the tactical approach of validating ideas. Others believe that these Vs apply only to Discover and that work can then be handed off to Scrum Teams once they have a validated vision. But that assumes two things:
- Value can be validated in isolation without the need to deliver working increments incrementally.
- The environment and situation will not change during the delivery process.
I remember from my time at Tasktop that I was often surprised by what was stable and what was unknown. That led me to accept that the product vision and roadmap were constantly in flux and that I needed to incrementally deliver, using the same teamwork that was part of the current product (bug fixes), the next release, and future experiments. The choices I made constantly changed based on those three types of work. The speed of those decisions, coupled with the context required to make them, made it very hard to split the job into one, two, or three roles.
I understand that many Product Owners are not building a new software product; instead, their product is part of a large, complex system with heavy dependencies. Ownership might be a challenge! But the 3 V’s still provide clarity. The vision remains essential because it helps set expectations for the other Product Owners, Scrum Teams, and Stakeholders. Value enables teams to understand the outcomes they are seeking. And, you still need to validate assumptions and manage the Truth Curve effectively. Because it is Scrum, the 3 Vs are made transparent, enabling clarity, focus, and ultimately value to be delivered.
Product Ownership is hard, but it is not impossible.
Whether you are working on cutting-edge digital products or “owning” a set of capabilities within a much larger product, where change is slower, you are accountable for delivering value. Maybe the person who said, “Do Scrum, and you are the Product Owner,” did not understand what that meant, but it is a huge opportunity. You get to shape value and challenge complex decision-making structures to deliver clarity, focus, and understanding. And if the person who told you to be the Product Owner is not happy with the outcomes, you also get the opportunity to show why that decision was a great one by delivering value and learning in every Sprint.