Misconceptions about the role of the product owner

In this brief article I want to cover the three most common misconceptions about the role of the product owner, I have encountered so far:

  • The product owner is a proxy for the stakeholders.
  • The product owner creates the key product backlog items.
  • The product owner prioritizes the backlog.

First of all let’s see what the Scrum Guide says:

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 Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:


– Clearly expressing Product Backlog items;
– Ordering the items in the Product Backlog to best achieve goals and missions;
– Optimizing the value of the work the Development Team performs;
– Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
– Ensuring the Development Team understands items in the Product Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.


The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.


For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.

the Scrum Guide, September 2019

That’s a really great explanation. Read it. Understand it. Live up to it.

But still there are these misconceptions about the role of the product owner in the heads of people and organizations employing agile principles. Let’s change that.

The product owner is not a proxy for the stakeholders

In some cases I’ve experienced the product owner is seen as a proxy for the stakeholders. Every communication with the stakeholders is done through this key person.

That’s not really the optimum in an agile approach. Of course developers should collaborate with the stakeholders directly to get early feedback and being able to adapt as early as possible.

But: Of course the stakeholders should not influence the work done during a sprint.

Things like:

“Hi, it’s not planned in your sprint backlog, but I need this button, with that functionality as soon as possible. Please implement it now!”

are an absolute no-go to do.
Things like this must be addressed through the product owner.

Because the product owner is accountable for the value of the product and has the required knowledge about the goals and missions to make a decision.

Note: That doesn’t mean that the sprint backlog cannot change during a sprint. As long as it does not distract the focus from the sprint goal changing it is fine.
But it’s not a decision of the stakeholders to do this.

The product owner does not create most of the product backlog items

The key items in the backlog should come from the stakeholders. The product owner can of course support them to express their wishes in a language that is understandable for everyone involved.

Side note: In this context the frequently used:
“As a [insert role], I want …, so that…” phrase to write a backlog item as a user story, is also often used in a wrong fashion:

The role should never be used just to indicate the author of the story

“As a product owner, I want to have a button that sends a message to a colleague further up the line, when I finished working on a task, so that this co-worker can continue with this task.”

Obviously the product owner helped the stakeholders out here and wrote a story for them. Nice guy.

But as a developer it leaves me with many open questions: Why does our product owner need that? Whom should that message go to? He doesn’t even work on tasks?! Puzzling…

This:

“As a sales guy, I want to have a button that sends a message to a colleague further up the line, when I finished working on a task, so that this co-worker can continue with this task.”

Not ideal, but sounds way better, right? I can now imagine what it is used for.
Probably the “colleague further up the line” is someone from the order management,
I can prepare some ideas for a refinement session.

The role that is mentioned here should never be used to express authority

It should be the role relevant for the context.

“As a member of the management board, I want to have a reporting function, so that I can use these fancy excel sheets in my even more fancy power point presentations”.

What do you need? As a developer I am a bit scared now:
I need to implement something I don’t know about yet for someone, who is obviously very important. Better make no mistakes…

If , instead the author of this story would have written:

“As the person accountable for customer loyalty reports I want to have a reporting function, so that I can use these fancy excel sheets in my even more fancy power point presentations.”

This is way better. As a developer I know now, what kind of reports are needed. And I’m not intimidated by the “management board” term. (In fact I may feel sorry for that person, having such a boring job 😉 )
Of course the second half of that story can also be improved, but that can be done during refinement.

The product owner does not prioritize the backlog

This is the most common misconception about the role of the product owner, I guess.

The product backlog is not prioritized

It’s an ordered list of backlog items.
The product owner continuously orders and reorders this list in a way that maximizes value.

Seeing it as a prioritized list is too simple. Ordering the backlog involves many variables like dependencies, risks, costs, business conditions, market reactions, etc.

A great time to re-order the product backlog is during the sprint review, where the product owner, developers and stakeholders are present and able to participate.

Leave a Reply