What to Do When the Product Owner is Absent: Realities and Solutions.

"One product, one Product Backlog, one Product Owner." What sounds so simple on the surface has countless nuances in the real world. The reality is that there are many kinds of Product Owners, and sometimes... there´s none at all!

In fact, one of the co-founders of Scrum anticipated this from the beginning: "In the absence of the Product Owner (...), the Scrum Master is required (...) to act in their place". This is precisely what Ken Schwaber stated in Agile Project Management with Scrum back in 2004.

Furthermore, as noted in Scrum Reboot, while the Scrum Master role requires deep knowledge not only of Scrum and Agile but also of a full range of techniques and tools, the requirements for the Product Owner role seem to be somewhat more relaxed.

So much so, that the Scrum Guide itself states it is the Scrum Master´s job to "help the Product Owner find techniques for effective Product Backlog management," or even that the PO can delegate the responsibility for ordering and managing the backlog to the Development Team.

How is this possible for such a key role? In other words, how is it that in an ideal scenario—the one on paper—a Scrum Master can and should help a PO perform their own role, or that the PO can even delegate part of their responsibilities?

These complexities point to what has been experienced in a great number of projects from the start: the role has historically been filled by people who are experts in their business, taking on the PO responsibilities without full dedication.

This results in limited time for growth in the role, limited availability, and, in the most glaring cases, insufficient knowledge.

But what do we mean by Product Owner?

As Lyssa Adkins points out, it´s clear that any topic related to a product´s direction, schedule, and budget should fall within the Product Owner´s domain, as they are the one who, by definition, makes the business decisions that impact the product.

However, in many cases, the person we call a PO doesn't have the authority to define strategy, influence the rest of the company with their way of working, or even have decision-making power.

This is because, as Melissa Perri specifies, Product Owner is a role played on a Scrum team, whereas Product Manager is the job we´re often referring to. And both profiles are typically quite distinct. In fact, as we´ve seen, the responsibilities of the Product Owner role can be covered from within the development team itself.

Be that as it may, when it comes down to it, the most important thing is that business priorities are communicated clearly and in order. That someone is capable of conveying them (rather than just writing them down) so that the work delivered provides the expected business value, especially when what we are providing is a service.

Could that figure be the Scrum Master—understanding the Scrum Master not just as the person who holds the role in Scrum, but as the one who leads the Agile management of a project?

The truth is, there seem to be no compelling reasons why they couldn´t handle both, beyond the fact that the time required would likely prevent the proper performance of both functions, just as it´s ill-advised for a Scrum Master to continue coding if they come from a technical background.

At Paradigma, we realized some time ago the need to reinforce the more business-focused side of projects. In fact, it forms one of the domains of Polaris, our roadmap for project management.

For example, in several projects we´ve undertaken, we observed that the business structure, for various reasons, placed a greater focus on product strategy: there was an area manager with an advanced command of the product and the business, in direct communication with stakeholders.

This would be the equivalent of the Product Manager role. However, these individuals' day-to-day work makes it difficult for them to flesh out emerging features, define priorities, assist in delivery, and identify tasks for improvement or even technical debt.

Therefore, whenever we perceive this need, we bring in a figure who may not know as much about the specific business, but who excels at maximizing business value.

This is why the "Proxy" Product Owner figure comes into play—precisely to carry out the necessary tasks that the Product Owner cannot get to. This is a figure who, like the Scrum Master, stands out as an important player without being a mere "agile analyst" (a crucial function, by the way) or a butler for the team and the client.

• A person who, although they may not have free rein to shape product strategy, has a deep understanding of the company and how their product aligns with it, capable of inferring business, competitiveness, and adaptability metrics and driving improvements based on incidents, testing, or internal refinements.
• A person who helps craft a roadmap and set clear objectives, with milestones and deliveries aligned with the business.
• A person who contributes to analyzing and visualizing risks, incorporating competitor analysis and ideas from other sectors.
• And who, in short, is a maximizer of value contribution, so that the team generates the greatest possible impact on the organization.

Put a Product Owner in your life. And if you don´t have the time, trust Paradigma to help you maximize your product´s delivery and value through the Proxy Product Owner role.

Inspirations

• The Scrum Guide (Ken Schwaber y Jeff Sutherland, 2010)
• Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Lyssa Adkins, 2010)
• The 8 Stances of a Scrum Master (Barry Overeem, 2016)
• Product Manager vs Product Owner (Melissa Perri, 2017)
• Scrum Reboot (Richard Gratton y Dave West, 2017)
• Why you Need Only ONE Product Owner (Roland Flemm, 2018)
• Can the Scrum Master also be the Product Owner? (Stephanie Ockerman, 2019)