In this special BONUS episode with Daniel, we cover some of the most serious Product Owner anti-patterns. These are anti-patterns that can severely affect the teams’s ability to deliver, and to focus on value.
Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.
And we start with a big myth about the PO role…
Does the Product Owner REALLY own the Product Backlog?
David describes the different Product Owner anti-patterns in an article on Medium, and he starts with one that is somewhat of a surprise: the myth that the PO “owns” the Product Backlog.
What does that really mean? David explains that, often, the PO’s will act as if they are the only ones that can edit, or manage the Product Backlog. However, that’s not the most effective way to collaborate with the team, and that perspective may lead to the team feeling disengaged, and not responsible for the success of the product.
4 anti-patterns of the Product Owner role
The 4 anti-patterns that threaten the Product Owner role’s effectiveness, as well as the ability of the team to deliver on the expectations from PO and stakeholders, are:
- Order taker (from stakeholders)
- Responsible for the team (in an HR role)
- Technical architect (and wants to define the technical solution(
- The only one who touches the backlog
Anti-pattern #4 was covered already, but now we dive deeper into the other 3 anti-patterns. Starting by the “order taker” anti-pattern.
The PO as a simple “order taker”
The order taker PO is like a waiter in a restaurant, waiting to take other people’s orders (mostly higher up stakeholders), and then rushing to try and please everybody. Of course, this leads to problems down the line, and the PO ends up not adding value to the product development process.
When the PO falls into this anti-pattern, it is important to discuss the “why” for the backlog items selected into the Sprint. In this case, Scrum Masters can help the Product Owner define Sprint Goals, which will help crystalize the reason why some of the Features/Stories are selected, and at the same time be a sort of filter that helps say “NO” to other backlog items.
In this segment, we discuss some of the questions to ask in Backlog Refinement and Sprint Planning that help the PO focus on what matters for that Sprint instead of trying to fit as much as possible into the Sprint to try and please all the stakeholders.
The PO that acts as the “owner” the team
The PO acts as the “owner” of the team, tends to take a “managerial” stance, assigning tasks instead of explaining the Product Backlog items; feeling ownership over the developers’ time; setting out orders during the daily meeting instead of listening and helping the team identify and resolve blockers.
The Scrum Master that faces such a situation should focus on building trust between team and PO, so that the team gains the necessary independence to reach self-organization. A team that is not able to self-organize and must follow PO orders, is not going to be able to pivot fast enough and will be waiting for solutions instead of taking ownership and getting the blockers solved quickly.
In this segment, we talk about setting goals as a tool to spark collaboration, and we discuss the lessons from the book The 5 Dysfunctions of a Team by Lencioni.
The PO that acts as the “technical architect”
When developers move on to become Product Owners, they usually keep on trying to define technical solutions for the team. In that case, we have a PO that acts as the technical architect, instead of the person that sets the Vision for the product, and explains the “why?” for each backlog item.
When this anti-pattern is present, the team will tend to step back, and hand over the responsibility for technical decisions to the PO, which in turn will make the team less active, more like order takers, than active product developers.
David describes this as a common anti-pattern when there’s no strong technical Vision in the team, and the PO takes on that Vision definition. Another reason for this anti-pattern to emerge is when the team lost the technical leader (who is now the PO), and is not able to make decisions on their own without the technical leader taking the lead role in the process.
In this segment, we talk about Model Storming, a process to help teams make technical decisions by considering different options, and converging on a shared solution idea.
About David Pereira
David is a passionate Product Owner who loves leading teams in building solutions that challenge the status quo.
He’s also written a free ebook on the top 7 mistakes of a product owner which you can get at https://bit.ly/po7mistakes
You can follow , and connect with David Pereira on LinkedIn.
