Is the Product Owner really the most difficult role in Scrum?

Tough to do or tough to understand?

Many say that the P.O. is the most difficult role in Scrum. There was a time when our team may have even agreed with that statement. As we guide clients changing the way they do work using Scrum and talk with graduates of our classes, we realize something. The Product Owner role isn’t the most difficult role in Scrum.

It is the most misunderstood role in Scrum.

Many organizations do not understand Scrum means change- altering the way they work. The muscle memory from project management in their company is strong. And old habits die hard.

Misunderstanding #1: Lack of Authority.

If the Organization makes a sweeping generalization like “all Business Analysts are Product Owners” the Product Owner role is being misunderstood. According to the official Scrum Guide (https://scrumguides.org/) the Product Owner has authority to make decisions. Everyone in the organization respects those decisions. Now if your organization actually gives the “formerly known as B.A.” that kind of authority – awesome! But chances are proclamations from the *real* authority cause delays, wasted time and money and other impediments to delivery of Customer value. Which is what Scrum is all about.

Misunderstanding #2: The P.O. Must Know Everything.

Some organizations make up roles that don't exist in Scrum.

Titles like proxy Product Owner, Technical Product Owner, Business Product Owner, Co-Product Owner. There is a reason for only one role called Product Owner. To avoid confusion about who the Development Team is taking direction from.

What happens when all these “product owners” try to give conflicting and contradictory direction to the Development Team? You guessed it. More confusion and delay, wasted money and time and no value to the customer. Product Owners do not have to know all the answers. Effective P.O.s seek input. That’s right. Input. They take technical info, marketing info, customer info, product info, financial info in and make an informed decision.

As a proactive, collaborative leader, they seek input before they make decisions. This Refinement activity is ongoing and happening at varying levels and times. The P.O. doesn’t have to do it all by themselves but someone assisting or someone giving the P.O. input doesn’t need a silly, made up Scrummy title.

Misunderstanding #3: Refinement is a P.O. Meeting with the Dev Team.

If your Development Teams are stuck in full day “refinement meetings” with a Product Owner, it may be a sign that the P.O. doesn’t understand Refinement as an ongoing, proactive activity. P.O.s bring items for further refinement to the Development Team only when ready. An effective P.O. gathers input from stakeholders, customers, subject matter experts and made decisions. Once the Development Team gets involved we might do more but we’re not wasting time with something that might not even happen.

The Scrum Guide notes that a P.O. would not engage the Development Team for Refinement more than 10% of their Sprint capacity. Otherwise when would they be getting work done towards meeting the Sprint Goal?

If you’d like to listen to a discussion on this topic, please visit our Ignite Agility podcast. More Certified Scrum Product Owner courses are on our calendar to meet demand and clear up confusion about this role. Check them out here.