The Product Owner Is Often One of the Worst Enemies of Scrum
Five reasons why Product Owners lead Scrum Teams in dreadful directions
Five reasons why Product Owners lead Scrum Teams in dreadful directions
During the last years, I observed many teams are moving away from Scrum. This trend astounds me. It seems like they are losing faith in the promised results of this framework.
Recently, I’ve stumbled upon many articles challenging how the framework is used in reality. For me, this is a sad situation, but why is it like that? Which factors make teams doubt working with Scrum?
You might disagree with what I am about to say, but I believe the Product Owner is one of the worst of Scrum’s enemies. I’ve been in multiple situations where the Scrum Team failed because the Product Owner led them in the wrong direction. I was the Product Owner in some of these situations.
Until the Scrum Team has a strong Product Owner, they will fail to deliver meaningful results.
Allow me to share my arguments on why the Product Owner is one of the main reasons for failures. Hopefully, you will know what to avoid if you play the Product Owner role.
1. Commitment for the Team
Stakeholder: To unload our customer service team, we need to implement a chatbot. Can you do that?
Product Owner: Sure! The developers have a good knowledge about it.
Stakeholder: Great! How long do you think it takes?
Product Owner: Hum. I think we can commit to deliver in two Sprints. I will prepare the User Stories and hand them to the team.
Such a situation is common among dysfunctional Scrum Teams. Product Owners agree on a solution with a deadline without talking to a single developer. When that happens, developers don’t commit to the solution because they had no saying in it. Without commitment, engagement is low.
I call this relationship as the service provider contract. Developers don’t own the solution because somebody else defined what should be implemented by them. Yet, they are pressured to make the solution work. But are Product Owners or stakeholders the right people to determine the solution? I don’t think so.
Great Product Owners define relevant problems to solve, while the whole Scrum Team defines HOW to solve them!
2. Doesn’t Know How to Prioritize
Prioritization is a nightmare for most Product Owners. The problem is not deciding what to do; the challenge is determining what not to. Stakeholders pressure to deliver more and more. No matter what the team provides, it will never fulfill the expectations.
“There’s always more to build than we have time or resources to build — always.”
― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product
Unfortunately, the HiPPO (Highest Paid Person Opinion) often decides what a priority is and what is not. Still, the Product Owner remains accountable for maximizing the value. Many people lack the required skills to turn this situation around.
When Product Owners fall short on prioritization, Scrum Teams are no different than rats on a treadmill.
3. Mislead the team
Let me ask you a question, how often do you see Scrum Teams with the following traits?
Product Vision is inexistent or forgotten.
The Sprint Goal is always to deliver all tasks by the end of it.
More features = success.
More story points = progress.
I’ve seen many teams with all of these anti-patterns. Unfortunately, the Product Owner is often the main responsible for such unfortunate situations. I wonder if Product Owners know what value is.
Before my last webinar, I created a survey asking the main challenge of a Product Owner. With more than 30% of the answers, the winner was: “Focus on value instead of features.”
Why do Product Owners fall in love with features? Many people land in this role without product management experience, which inevitably leads to misconceptions. First, we need to understand why, then what. We don’t build features for the sake of having them; we create them to provide value. Until the impact we want to achieve is clear, we shouldn’t talk about features.
“The biggest thing I’ve learned in product management is to always focus on the problem. If you anchor yourself with the why, you will be more likely to build the right thing,”
― Melissa Perri, Escaping the Build Trap: How Effective Product Management Creates Real Value
4. Please Everyone
“Oh my god! I have many stakeholders to take care of.”
“I need to prioritize something for everyone. Otherwise, they will escalate to my boss.”
“I need to keep the stakeholders happy, then everything else will follow.”
I often hear sentences like these from Product Owners. That annoys me because:
Stakeholders are not customers.
Stakeholders’ happiness has nothing to do with delivering value.
Doing a little bit for everyone is a perfect recipe for mediocrity.
It’s a fact Product Owners have to deal with multiple stakeholders, but how you handle them ultimately defines your odds of being successful. Alignment is what matters, not happiness.
Great Product Owners don’t please stakeholders; they establish meaningful partnerships to deliver successful products.
5. Conflicts Avoidance
The word conflict scares a lot of people because they perceive it as a bad thing. But is conflict indeed something wrong? For me, collaboration without conflicts leads to fake harmony. People have different opinions. If we don’t feel heard, we won’t commit to anything.
It’s common to observe Product Owners running away from conflicts. For example, when deciding which solution is the best option for the problem, people will have different perspectives. How do you make a decision when that is the case? You can either aim for consensus or make the conflicts visible and solve them. The outcomes would be something similar to:
Consensus: the group will adjust the solution until everyone agrees. The solution will ultimately be a sub-optimal option because everyone made a compromise.
Conflict: everyone will share their perspective, and conflicts will be cleared, and the group will decide on the best options. The team agrees to disagree.
“Seeking consensus is often an obstacle to action.”
― Marcia W. Blenko
Final Thoughts
Scrum will never work if the Product Owner is unprepared for the job. Regularly, companies misunderstand what the role is about, and someone inexperienced takes this massive responsibility.
I am a Product Owner by heart, and I know many teams I worked with failed because of me. I didn’t have the required skills to overcome the challenges I faced, and ultimately the results were disappointing. For executives, Scrum was the villain; the framework got the blame. But I know who the real enemy was.
Organizations will continue to reach mediocre results until they misunderstand what the Product Owner is about.
The Scrum Team needs a strong professional for this role. Otherwise, success is an unachievable dream.
Do you want to write for Serious Scrum or seriously discuss Scrum?