The Title “Product Owner” Misleads People to Behave like Bosses

Be careful. Product Owners can be detrimental to teams. 

What do you understand by the term Product Owner?

I’m afraid that everyone interprets it differently, and that’s a cause for problems. For me, the word owner is misleading. As a Product Owner, you own nothing, though you may think you do.

Let me share with you a quick story. I’d always get confused between Product Manager and Product Owner. Initially, I used Product Manager as a job title, and then I moved to a startup where everyone called me Product Owner. 

Eventually, I decided to use Product Owner as a job title on LinkedIn. After changing it, my previous CEO wrote, “Congratulations on taking this initiative. It’s a big step to start a business. I admire your courage.” I was puzzled by this message because I didn’t start a company. I was doing the same job as before. 

I’m surprised by many Product Owners’ behavior. Here are things I hear pretty often:

• I own the final word
• I define what goes into each Sprint
• Only tasks I approve can go live
• Developers need my perspective to make decisions

When I hear that, I know Scrum teams will fail because of the Product Owner. This drives me crazy.

Many Product Owners act as though they are above the Scrum Team instead of being part of it. Such behavior will inevitably backfire. The team will get demotivated and will undermine the Product Owner.

Unfortunately, I commonly observe Product Owners operating under a command and control mindset with the team. If the team achieves the goal, the Product Owner happily takes the credit for it. But if the team fails, the Product Owner blames developers for poor execution.

Product Owners are part of the Scrum Team, not above them.

Allow me to share with you four destructive behaviors of Product Owners. I hope this inspires you as a Product Owner to act differently and, as a Scrum member, to call Product Owners out when they miss the mark.

Destructive behaviors of Product Owners

1)  Product Owner: The Genius Who Knows It All

Digital product development is complex. We face several challenges, and we must always make decisions. It doesn’t matter how smart you are, you will eventually hit the wall. 

Every day you have to ponder where to go. You have too many questions and too many answers. If you try to get all the answers on your own, you’ll ensure failures more often than you can afford. 

Which problems are worthwhile solving?

Which solution can drive our desired outcome?

How fast should we scale up our product?

I need to break something to you. Alone, you cannot get all the answers right. You must learn to collaborate closely with your team and find the answers together.

Finding the sweet spot between problem, solution, and technology requires much work. A single person cannot be competent in it. But some Product Owners insist on defining the problem to solve and the solution alone. 

When developers only execute the demands of the Product Owner, you can expect mediocrity and a high turnover because developers will feel trapped in a production line. Is it the best way to build meaningful products? I don’t think so.

Collaboration is vital to building successful products. My recipe for it would be:

1. The Product Owner strives to identify meaningful problems to solve
2. The Product Owners bring the problems to the Scrum Team
3. The Scrum Team deep dives into a problem understanding process
4. The Scrum Team crafts a solution for the problem
5. Developers create a delightful solution.

It sounds obvious, doesn’t it? Maybe not for many teams. Too often, teams mess up, resulting in frustrations and poor results.

“None of us, including me, ever do great things. But we can all do small things, with great love, and together we can do something wonderful.” — Mother Teresa

2)  It’s Always Developers Fault

If the Scrum Team succeeds, Product Owners claim credit for it because they make most decisions. But if the team fails, shame on developers because Product Owners had nothing to do with that. Unfortunately, I’ve observed this bizarre scenario rather often.

Some Product Owners see themselves above Scrum Teams. They use the team as a means to an end. Developers represent the assembly line workers, while the Product Owner is the engineer defining how they work and what they produce. 

Whenever something goes wrong, it’s time to blame the poor assembly line workers. They must have been inefficient or done something wrong. The Product Owner knows.

I’ve observed this awful behavior in distinct scenarios. Let me share some examples with you:

• When the stakeholders are angry because of quality issues, the Product Owner points the problem directly to a team member. Saying something like, “Torvi is working on a bug fix. I pressured her a lot today, but until now, nothing. We have to wait.”
• If a deadline is missed, the Product Owner will shift the responsibility to the team. For example, “Björn is taking too long to finish. I’ve already pressured him, but he’s slow.”
• The Product Owner refers to developers as they and never use we (Scrum Team). It’s always I, the Product Owner, and they, the developers.

Product Owners should never point fingers at a member of the Scrum Team. If a problem happens, it should be solved inside the team. 

Great Product Owners are proud to say we instead of I and they.

3)  Obey Your Master

It’s 09:00 a.m., and developers are ready to start Daily Scrum, but the Product Owner is absent, so they can’t. They wait for seven minutes until the Product Owner finally arrives. The Daily starts like this:

Product Owner: Björn, I would like you to focus on the new issue I found today. Torvi, could you take over the tasks from Björn? I will talk to you after the Daily.

Torvi: I don’t think I should because I won’t be productive since I lack context.

Björn: Well, I could work on the mentioned issue, but does that make sense? I need only today and maybe tomorrow morning to finish my current task. Can we wait until then?

Product Owner: I already promised Eckbert this fix. Sorry, we can’t wait. We have to fix it today. I will give you the details.

Björn: Next time, you should involve us before you promise something.

Product Owner: Sorry, Björn. I hope you understand that I decide what goes into a Sprint and what doesn’t. That’s my accountability, not yours.

You may ask, why didn’t the Scrum Master interrupt this discussion? In this example, the Product Owner played both roles. It’s a real scenario that I’ve observed. 

Many companies don’t have a dedicated person as a Scrum Master. However, the absence of a Scrum Master does not justify the Product Owner behaving as the team’s manager.

The Product Owner has no authority over developers. The Product Owner and Scrum Master are the team’s peers. The misunderstanding comes from the nature of the Product Owners’ job; they work more closely with stakeholders than developers. That’s why they may think they can decide alone what to do and what not to do. But that’s not how a team works.

The Product Owner must respect and trust developers’ ability to reach Sprint Goals. Developers are self-organizing and don’t need anyone telling them what to do. The lack of trust between Product Owners and Developers will destroy Scrum teams’ chances for success.

Final Thoughts

Product Owners are not bosses.

Product Owners don’t own anything alone.

Product Owners are not above developers.

If you want any chance of succeeding as a Product Owner, you better learn how to be a leader who inspires. Lead by context, not by control. Encourage people to challenge your decisions and give feedback when you miss the mark.

It’s vital to understand what servant-leadership means. The Product Owner is a peer to all team members. Even if you have the job title of a Product Manager, it’s still a servant-leadership position. 

Until Product Owners can live as part of the team, the Scrum team will never be able to unlock its true potential.