The Product Owner is part of the Scrum Team, not above them
Until Product Owners become a real team member, they will never be able to thrive
Until Product Owners become a real team member, they will never be able to thrive
“Talent wins games, but teamwork and intelligence wins championships.”
― Michael Jordan

When I see other Product Owners interacting with their Scrum Teams, I often notice something that annoys me a lot. Many Product Owners act as if 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, it’s common for me to observe Product Owners operating under command and control mindset with the team. If the team achieves the goal, the Product Owner cheerfully takes the credit for it. But if the team fails, the Product Owner blames the Development Team.
Is a relationship like this sustainable? Of course not.
Product Owners are part of the Scrum Team, not above them.
Who is the Product Owner?
Many companies and people misunderstand the Product Owner role. But what does the Scrum Guide say about this role?
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
— The Scrum Guide, November 2017
The Scrum Guide explains the outcome the Product Owner should deliver. But who is this person in the organization? Many companies answer this question differently.
Product Manager: some companies define the Product Owner as a role and the Product Manager as the career. In this case, the Product Owner is the Product Manager itself.
SAFe Product Owner: in this framework, the Product Owner reports to the Product Manager. The SAFe Product Owner is similar to a Business Analyst, but far from the Scrum Product Owner.
A business representative: when moving from traditional software development to Scrum, some companies may define someone with a vast business knowledge to play the role of the Product Owner.
You may find a dozen more understandings of who the Product Owner is. But the point is, the Product Owner is a member of the Scrum Team. This role is a peer to the other professionals, Scrum Master and Developers. It’s a deadly misconception when the Product Owner behaves as being on the top of the team.
Let me share with you some unsustainable behaviors I had the displeasure of coming across.
Product Owner defines the problem and the solution alone
Software development is daunting. We face endless challenges, and we have to make decisions all the time.
What is the right problem to solve?
What is the right solution for the problem?
What is the most suitable technology for this solution?
Finding the sweet spot between problem, solution, and technology requires a lot of work. A single person cannot be competent in it. But some Product Owners insist on defining the problem to solve as well as the solution alone. In this case, the Development Team only executes the demands of the Product Owner. That’s why many Developers are frustrated; they feel like being in a production line. Is it the best way of building meaningful products? I don’t think so.
Collaboration is vital to building successful products. My recipe for it would be:
The Product Owner strives to identify the relevant problems to solve.
The Product Owners bring the problems to the Scrum Team.
The Scrum Team engages in a discussion until the problem is crystal clear.
The Scrum Team crafts a solution for the problem.
The Development Team implements the solution.
It sounds obvious, and it is. Yet, many 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
Whenever something goes wrong, it’s the Development Team’s fault
If the Scrum Team succeeds, the Product Owner claims the credit for it because she makes most of the decisions. But if the team fails, shame on the Development Team, the Product Owner had nothing to do with that. Unfortunately, I’ve observed this dreadful scenario quite often.
Some Product Owners don’t see themselves as part of the Scrum Team. They use the team as a means to an end. The Development Team is like a factory, while the Product Owner is the one defining what should be produced. Whenever something goes wrong, it’s time to blame the poor factory workers, for sure they were inefficient or made something wrong. The Product Owner had a perfect plan.

I’ve observed this terrible behavior in different scenarios, let me share some examples with you:
When the stakeholders are angry with some development issues, the Product Owner points the problem directly to a team member. Saying something like, “Björn is working on a bug fix. I pressured him a lot today, but until now, nothing, we have to wait.”
If a deadline is missed, the Product Owner will not hesitate to shift the responsibility to the team. For example, “Peter is taking too long to finish. I’ve already pressured him, but he’s slow.”
The Product Owner refers to the Development Team as they, and never use we (Scrum Team). It’s always I, the Product Owner, and they, the Development Team.
Product Owners should never point fingers to a member of the Development 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.
Command & Control Behavior
It’s 09:00 a.m., the Development Team is ready to start Daily Scrum, but the Product Owner is not around, so they cannot start. They wait for seven minutes until the Product Owner arrives. The daily start like this:
Product Owner: Björn, today I would like you to focus on a new bug I found, I will talk to you after the Daily. Harold, could you take over the tasks from Björn?
Harold: For me, it’s okay. But I think I will not be productive on it since I lack context.
Björn: Well. I can do that, but I need only today and maybe tomorrow morning to finish my current task. Can we wait until then?
Product Owner: We can’t wait, we have to fix today. I will give you the details.

You may ask, why didn’t the Scrum Master interfere in this case? In this example, the Product Owner played both roles. It’s a real scenario that I 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 manager of the team.
The Product Owner and Scrum Master participate on the team as a servant leader and peer to the rest of the team. The Product Owner has no authority over the Development Team. But this role represents stakeholders with a particular political “weight” in the organization. And since Product Owners spend more time with stakeholders to provide clarity, this can make it hard to be a servant leader.
The Product Owner must respect and trust the Development Team’s ability to create and work a daily plan of action.
“It is the long history of humankind (and animal kind, too) that those who learned to collaborate and improvise most effectively have prevailed.” — Charles Darwin
Endnote
I’ve had the pleasure of working with many successful Product Owners, from whom I could learn how to avoid the pitfalls that lead us to mediocrity. But I also faced many misunderstandings on how to be a Product Owner, myself included.
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 release its true potential.
Do you want to write for Serious Scrum or seriously discuss Scrum?