The Product Owner — Scrum’s Great Success and Failure

You don’t have to have a “Product Owner” to be Agile

There’s a complaint about Agile development which is: “Scrum is so well known and so widely used, that people often mistake Scrum for Agile development.” It’s a fair criticism. The prime example of this is the “Product Owner” role. The Product Owner role (as far as I know) comes from Scrum. The role aims to satisfy this Agile principle:

“Close, daily cooperation between business people and developers.”

Pretty much all software development companies want to be Agile now and it seems like setting up “Product Owner” positions is standard as part of that process. The problem with that is that the role gets anchored to the Scrum definition of “Product Owner”. While that solves some problems it raises other problems. To make it clear that I’m talking about Scrum’s definition of a Product Owner, I’m going to say “Scrum Product Owner” from now on.

Where the Scrum Product Owner role succeeds

I read “The Phoenix Project” recently and it really helped me understand the enormous value the concept of a Scrum Product Owner has brought the industry.

It’s a story about a business running itself into the ground as its IT team gets hammered by requests from all around the business. The IT team was left to fend for itself, trying to figure out the priorities of these requests and implementing the wrong things because they didn’t understand the goals of the work requested.

This is where the Scrum Product Owner role shines. Understanding all the business requirements that are coming in, prioritising those and translating them into a format that the development team can work on. It’s a simple but powerful concept that has no doubt transformed many businesses.

Where the Scrum Product Owner role fails

The problem is accountability. The Scrum Guide says:

“The Product Owner is the sole person responsible for managing the Product Backlog … The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable”

The trap here is that if the Product Owner is “the sole person” accountable for managing the backlog then how do you hold UX Designers and Engineering accountable? Can you hold them accountable to the work they deliver, if ultimately it is the Scrum Product Owner’s sole responsibility to determine if that works gets done? I don’t think so.

The Scrum Product Owner’s accountability turns UX and Engineering into stakeholders.

“But can’t Engineering and UX be accountable too?” you might rightly ask. The Scrum Product Owner definition is clear that the backlog is the sole responsibility of the Scrum Product Owner. This work can be delegated out (i.e. to UX and Engineering), but you can’t delegate out accountability. When it comes down to it, the Scrum Product Owner needs to be able to explain why a UX improvement was more valuable than an Engineering maintenance task. This means the Scrum Product Owner has to understand the value of all the work in the backlog.

Pete Coulter from Thoughtworks talks about the unrealistic demands on Scrum Product Owners:

“Increasingly, I see the difficulty organizations have in finding suitable people to take up a Product Owner (PO) role when adopting agile working practices. Even when the role is filled, the tasks of empowering the individual to a suitable level and giving them the knowledge of how to calculate true business value, are rarely accomplished … Not only do [Product Owners] need to be passionate about the product, but also have a solid knowledge of concepts and practices like user value, business value, cost/benefit analysis, business accounting, operating costs, market and competitor analysis, stakeholder management etc.”

In Customer Obsessed Teams Don’t Have Product Owners, the inventor of “Modern Agile” Joshua Kerievsky says:

“The choice of what to build or fix is hard. It requires the insights of many to do it well. If you want to do it poorly, delegate all of this work to a single Product Owner (PO) … customer obsessed companies know that you can’t make people awesome if you aren’t learning about their needs. And it takes a team to do that well, not one PO.”

Why do we put so much pressure on our Scrum Product Owners? How does this even work for Junior Scrum Product Owners? Are they expected to be held accountable for all this still?

The accountabilities of a Scrum Product Owner are just too great.

The Product Co-Lead to the rescue

Let’s ditch that single person accountability concept and instead have a team of a Product Co-Lead, UX Co-Lead and Engineering Co-Lead all accountable.

They need to be in agreement on the backlog. No one person/discipline is allowed to decide. Their success is judged both on ensuring all of their needs are balanced in the backlog, but also that their choices maximise value.

But don’t just listen to me, listen to Air BNB

“The [Engineering, Product and Design] cohort is recreated across every project, with co-equal, designated engineering, product and design leads working together … This type of equal access and authority on a multidisciplinary team allows for astonishingly synchronized and speedy product development that can scale as a company grows.”

And Atlassian

“To govern product development, Atlassian uses the triad model in which engineering, product management, and design all collaborate in making decisions … “You need healthy tension in the triad for solving engineering, business, and customer problems,” says Alastair. “If product performance suffers because of technical debt, it doesn’t matter how polished the features might feel. The triad is ultimately responsible for the whole experience.””

And Basecamp, who have a slightly different set of three in their team:

“ultimately the decision about what makes it into [the backlog] comes down to me (ceo), David (cto), and Ryan (strategy). A week or so prior to the cycle start, we review all the pitches posted to Basecamp, share some of our own ideas as well, and often vigorously debate the options. And then we’ll … debate some more, and make the final decisions.”

I think the best Product Owners already consider themselves Product Co-Leads

In my experience, the best Product Owners already do this “co lead” role. They bring UX and Engineering together and help combine the needs and visions into a backlog. Lets have “Product Co-Leads” to make the intent of this role clear and dissociate it from the Scrum Product Owner role.