Top 5 Product Owner Myths
Demythifying widespread misconceptions about Product Owners
Demythifying widespread misconceptions about Product Owners
It’s astounding how many misinterpretations of the Product Owner role you can find. All companies I know have a particular interpretation of this role, which leads to a different set of expectations, and that is where many problems arise.
I’ve worked as a Product Owner in many different places, and I was almost always surprised with ‘weird’ expectations. Although I thought I knew what to do in this role, expectations between the company and me were often misaligned. What I realized is that many people often land in similar traps as I already did. Let me share the most common myths I’ve encountered on my journey and how you can overcome them.
The Source of Misunderstandings
The Product Owner is not a standardized role within agile frameworks. For example, the responsibilities defined in the Scrum framework are totally different than the ones in SAFe. What I mean is, when you find an open position for a Product Owner, you need to know which framework the company uses before you understand what the company expects.
Let’s compare Scrum and SAFe. The Scrum framework puts many responsibilities on the Product Owner’s shoulders, while SAFe removes them. In Scrum, the role is strategic and tactical, having an end-to-end responsibility, while on SAFe, this role is focused on the execution.
To make matters worse, there’s often confusion between titles, Product Manager and Product Owner. Then you wonder, what’s the difference between a Product Manager and a Product Owner? Some companies would say the Product Manager defines the right thing to do while the Product Owner ensures the thing is done right. I don’t believe in this interpretation. For me, the Product Manager is a job while the Product Owner is a role that should be filled by a qualified person, which is often a Product Manager. To strengthen my perspective, let me borrow a thought from Maarten Dalmijn:
You hire someone with the right knowledge to fill the role. Whether this person has experience with Scrum or has a Scrum developer certification is less important than having the skills to do the actual job. You don’t hire for the role in Scrum, you hire for the job they are supposed to do.
Should you hire Product Managers or Product Owners for your Scrum Teams?
Beyond all of this, people interpret words differently, and misunderstandings become inevitable. Now, I will go through the most common ones I’ve experienced.
Myth #1: The Requirement Keeper
How would you interpret the following part of the Scrum Guide?
The Product Owner may represent the needs of many stakeholders in the Product Backlog.
Although it’s part of the Product Owner's responsibility to manage the stakeholders' expectations, that doesn’t mean being a requirement keeper who doesn’t challenge the needs behind the wishes. Unfortunately, many companies perceive the Product Owner as a kind of Backlog Owner, where the primary responsibility is to collect the wishes from stakeholders and update the Product Backlog. This understanding is wrong.
When the requirement keeper myth takes place, you will find:
Powerless Product Owners because the stakeholders or someone else decide what is important and what is not.
Extensive and confusing Product Backlog because the Product Owner invests more than 50% of her time extending the Product Backlog.
The Sprints are like a Chinese soup; everything can go into it. For example, you go to a Chinese restaurant and order chicken soup; once you get the dish, you find everything in it.
Myth #2: The Speed Maximizer
According to the Scrum Guide, the Product Owner is responsible for maximizing the product value. But how companies interpret this sentence is critical to deliver real value or fall into traps.
A common problem is associating the word ‘maximizing’ with increasing speed. As a result, some companies become obsessed with features, and they perceive the Product Owner as a feature maximizer. When that is the case, delivering more features is the ultimate way of measuring success. Yet, measuring the impact of the features is underrated or ignored. The result is obvious; the product becomes so confusing that nobody can benefit from it.
It’s too naive to believe that more features mean better, more value. Digital product management is much more complex than that.
Great Product Owners don’t focus on maximizing output, they invest their time in identifying problems that are worth solving.
Myth #3: Define Solutions Upfront
Some years ago, I started a new challenge as a Product Owner. During my first months, I was pressured to build the right solution and deliver it on time. In addition, stakeholders wanted to know the solutions in minor details, so I had to work closely with them to agree on how each component would work.
I used to keep an extensive and detailed Product Backlog. Stakeholders were happy because they felt secure with a clear plan; we knew what to do. Our plan was perfect in our eyes. Unfortunately, we fell into the validity illusion trap. A plan illuded us, and we failed dramatically once the users had contact with the solution. We were blind to our blindness.
According to Daniel Kahneman, the validity illusion is the evidence we can forecast success; it’s like becoming blind to a plan. But, unfortunately, the hard truth with product management is that we can’t ensure success. We only know something has worked once the end-users can solve their problems.
“The gorilla study illustrates two important facts about our minds: we can be blind to the obvious, and we are also blind to our blindness.”
― Daniel Kahneman, Thinking, Fast and Slow
Being a Product Owner has nothing to do with defining solutions. The secret is to embrace learning. Great Product Owners create hypotheses and find ways to validate them as fast as possible.
Falling in love with solutions is a perfect way of ensuring frustrations.
Myth #4: Focus Solely on the Execution
Some professionals I know despise the Product Owner role because of a misinterpretation of it. They perceive this role as a tactical one, where the primary responsibility is to keep the machine running. It’s like an assembly line; the production can never stop. Unfortunately, this misconception is the case in many places.
When Product Owners don’t own the prioritization, their responsibilities are reduced to execution. In this case, the main activities are:
Manage the Product Backlog to reflect the stakeholders’ needs.
Manage the stakeholders’ expectations to ensure the product delivers on their needs.
Attend the Scrum Events focusing on delivering more output.
In my opinion, when execution is the only job, all the fun is gone because the autonomy evaporates as managing takes place over leadership.
Product owners should be empowered to lead a product from end to end instead of shoveling coal into the machine.
Myth #5: Sign-Off Tasks
I have an embarrassing confession to make. For a long time, I did something I now despise. As a Product Owner, I requested to approve all Sprint tasks as a final step; no task would go live without my approval. When I look back, I can barely explain why I did that, but I did, and I enjoyed it. What I didn’t notice was how harmful my behavior was to the team.
When the Product Owner has to sign off all tasks, it’s a clear sign of mistrust and misunderstanding of Scrum. The Scrum Team commits to the Sprint Goal and not to deliver a set of tasks. The Sprint Backlog belongs to developers, not to the Product Owner. When trust is absent, commitment fades. Developers won’t reach their highest potential being part of a dysfunctional team.
It took me a while to understand that leadership is not a title or a position; it’s a set of attitudes. Product Owners should not try to manage developers but lead them.
“If your actions inspire others to dream more, learn more, do more and become more, you are a leader.”
― Simon Sinek
What Makes a Great Product Owner
From my experience, it’s unlikely to find a place where you can work as a real Scrum Product Owner. Most businesses are dysfunctional, and you will face resistance to do your work correctly. Still, if you are brave and have a value-driven mindset, you can excel in your role. Here is what I find helpful to succeed in this challenging role:
Focus on understanding what value is, don’t let abstract words stand your way. Ensure stakeholders, developers, and everyone around you share the same understanding of value.
Ignore the speed. Focus on maximizing the impact instead of output. More features have no guarantee of more value.
Don’t spend time defining solutions. Instead, strive to identify what you don’t know and validate your assumptions as fast as possible.
Embrace learning in everything you do, don’t let the validity illusion fool you.
Don’t be a bottleneck for the Scrum Team. Instead, establish clear agreements and trust the team.
