Would you want to have a simple, collected, set of solutions (techniques and strategies) to solve the most common challenges Product Owners face? So would I! But before we can collect the solutions, we must understand the problem!

Reading Time: 3 minutes The Product Owner Challenge Game is an agile game with Lego bricks. The goal is to illustrate a waterfall-driven product development culture transitioning from Waterfall to Agile the agile mindset: communicate face-to-face clear objectives, requirements, and product vision — a real challenge for a product development department. “Product Owner Challenge” is an agile game with Lego bricks. U000BIt illustrates the agile mindset to a waterfall-driven product development culture when transitioning to Agile: communicate face-to-face clear objectives, requirements, product vision. You must watch this talk from Agile 2013: Enterprise Product Owner’s Challenge: Managing Networks of Backlogs by Alan Goerner of Valtech.This is a talk that I missed while in Nashville and I’m so glad that I went back to watch it.

That’s what I did in 2018.

I asked the listeners of the Scrum Master Toolbox Podcast and the readers of the blog what were their most common challenges when working with Product Owners. So, if you are a Scrum Master, an Agile Coach or a team member who wants to help the Product Owner, the list below is for you! (NOTE: there are links to solutions as well! ?)

What I thought were the 7 critical Product Owner anti-patterns (but I was wrong…)

This project started with a blog post I wrote about the most common anti-patterns I, myself, faced as a Product Owner. The blog post was about 7 key areas of competence and responsibility for Product Owners. Here they are:

1. 1. The Fly-By PO, lacking Vision that the team can use
   2. The Blind PO, lacking definition of success for the business and metrics to measure it
   3. The “lead” PO, when the Product Owner is also the manager of the team
   4. The “Need for Control”, when the PO cannot let others make decisions
   5. The PO as a shopping list manager: order taker and little else
   6. The PO is too busy to help the team, so they need the team to help them!
   7. The Cowboy PO, riding lonely into the sunset (of their product?)

Turns out I was wrong and these are NOT the anti-patterns most of you have seen! (well, some of them anyway…)

So I asked the people in my audience: what is the single most important challenge when working with Product Owners? And some of the answers were surprising!

9 critical Product Owner anti-patterns, as defined by YOU!

As a result of that survey, I found out that most of you have a different experience. The problems you identified did not completely align with my experience.

Here are the most common Product Owner anti-patterns that YOU face most often, from the most frequent to the least frequent:

1. The PO doesn’t have enough time

This anti-pattern wasn’t a surprise. After all, who has a lot of time in their hands?

But the interesting insight was that most of you have very specific (and somewhat unexpected) reasons for this anti-pattern. Here’s a short list for the lack-of-time anti-pattern. PO’s lack time because…

• They are part-time PO’s
• They are CEO/CTO/executive and have many other duties
• They handle multiple products
• PO’s complain that they are expected to talk to customers all the time (which obviously removes time and attention from the team’s needs)
• The PO is not really a PO, just has that role among their many hats (this one is hardly surprising, given how little attention some organizations give their development organization)
• The PO is only available 4 hours per week (wow! This one was quite a surprise. Can you imagine your PO doing their job in less than 4 hours per week? No, I can’t either…)
• Because the PO needs to complete all the bureaucracy required by the company, and the company values bureaucracy above serving the team (Auch!)
• … and many more.

This was just a small sample of the reasons for PO’s to be poor on time. How about you? What have you seen causes the PO to not have time? Leave us your view on this survey, and affect future Coach Your Product Owner courses!

2. The PO doesn’t have the right skills and I’m expected to train him/her

Agile is relatively new, Scrum was invented only in the late 1990’s after all. But how come we still have PO’s that are new to Agile. Well, that’s what you reported. So let’s look at some of the forms that this lack of experience takes:

• PO doesn’t know Scrum or Agile (Auch! By the way, spending time on training for that PO isn’t always the best solution. In the Coach your Product Owner course v2.0 LINK I tackle some faster alternatives to the slow training route)
• Product Owners are selected by the Stakeholders; they aren’t trained nor do they have the time to do the job. (A time will come when PO is an actual skillset that gets taught at school/University. Alas, that’s not the case yet…)
• PO not evaluated on PO role, but rather on other duties (If this were the case for you, I bet you would focus on those other duties, wouldn’t you? I know I would…)
• Our POs have been transitioned from other roles within the company. For example Head of the Department, Business Analyst, etc. (I’ve seen this quite often as well. How about you?)
• … and many more

Is your PO skilled in that role/job? If not, what is the reason? Leave us your view in this survey, and affect future Coach Your Product Owner courses!

3. The PO can’t create a Release plan (or other critical artifacts for that role, like Vision or Product Backlog)

In Agile we value working software over comprehensive documentation, but we still need some documents to help us achieve a common view of where we are going with the product. However, there’s little agreement in the community about what those are.

In the Coach Your Product Owner course I present a set of 3 documents that I think are critical:

• Vision Document (why does the product exist, who are the top 3 customers/users, etc.): here’s a free Vision workshop course I put together to help you host your next Vision Workshop
• Impact Map (clarify the goal from a business perspective): more information about Impact Mapping, and the Impact Mapping book by Gojko Adzic.
• Story Map (to help see the Product as a whole instead of just the single stories in the backlog): Here’s a facilitation guide I put together to help you host your next Story Mapping workshop.

In the Coach Your Product Owner course we explain why these are important and how to use them. But if you want to get started right away, just click the links above to find helpful resources!

Product Owner Challenge Gamehouse Games

4. The PO does not engage with the team and ends up working alone

Given the chronic lack of time (see anti-pattern #1 in this revised list), I would also try to work alone, maybe even at home in the evenings when the team is not available. This means that PO’s who prefer/need to work alone are very common in Scrum Teams.

Alas, this anti-pattern breaks one of the most important values in Agile: Customer (PO, in this case) collaboration, over contract (Product Backlog) negotiation.

“User Stories are an invitation to have a conversation” about the product, the customer, the needs that we need to fulfill. When the PO stops engaging with the team and misses critical meetings, we can’t have that conversation. Here’s what you’ve said are some of the symptoms of this anti-pattern

• The PO treats the team as “order takers” instead of contributors to the product
• The PO regularly pushes unclear stories to the team, who are confused and/or develop things that are not as expected
• The PO works alone (that was an obvious one)
• … and more

5. The team suffers from slow feedback and the PO doesn’t get the feedback they need either

Given that Agile is about creating, and benefiting from short-feedback cycles, this anti-pattern is particularly worrying.

Here are some of the forms and reasons that you reported for this slow feedback:

• The team only has access to a Proxy PO, who in turn has little to no access to the “real” PO
• The PO does not have direct access to the users, therefore has very little feedback or very slow feedback for the team
• Sometimes there’s a sort-of “Product Owner committee” that supersedes the Product Owner, and it takes a long time for the PO to get their feedback
• The Product Owner spends their day in meetings and is not able to engage with the team regularly
• … and more

How about you? What are the reasons you’ve seen may lead to slow feedback? Leave us your view in this survey, and affect future Coach Your Product Owner courses!

6. The PO does not feel empowered to make decisions

The role of the Product Owner was created exactly to remove this anti-pattern. The original idea of the Product Owner (as the single wringable neck) was to remove the need to consult many people before making a decision.

Alas, in many organizations we still have PO’s that are so in name only (POINO?), and therefore don’t feel they have the power or the mandate to make the decisions the team needs to be able to progress. The slow or non-existent decision making causes everything else to go much slower.

In the Coach Your Product Owner Course (sign-up to learn when it is available) we tackle this problem head-on with a set of techniques that help the PO manage multiple stakeholders and come to agreements quickly.

After all, even if the PO needs to listen to stakeholders, that does not mean they can’t lead the process of coming to an agreement. In the course we talk about:

• Why asking the PO to make decisions alone is not always the right approach
• Simple techniques to help a group of stakeholders reach consensus quickly
• How to use experiments as a method to remove delays from decision making
• Facilitation techniques for handling possibly conflicting views and come to a common agreement

7. The PO serves many teams and/or has many roles

This anti-pattern is hardly a surprise. After all, if the product is successful, it is only natural that the number of teams grows and the PO needs to serve all of them. So we need to figure out how to Scale the PO role. In this blog post about Scaling the Product Owner role, we discuss one possible solution that you can apply quickly.

8. The PO is a micro-manager and wants to control everything that happens

Oh boy! This anti-pattern is a tough one. In Agile and Scrum, we try to help create a collaborative way of working, so that the team amplifies the good ideas from the PO, and the PO uses the team’s creativity to improve the product.

After all, teams are the ones that have the technical insight and can come up with novel (technical) solutions.

However, when the PO wants to control everything that happens, the team will feel disempowered and will disengage, leaving the PO to work alone (see anti-patterns 4 and 5 in this list).

When PO’s want to sign-off on even the simplest of decisions, the team has to step back. This, in turn, leads to slower development cadence which will lead to problems in the market/business, sooner or later.

In order to tackle (and possibly avoid) this anti-pattern I’ve written a blog post and a created a technique based on the simple idea of focusing the Product Owners on the Product Goal instead of the Backlog, and then use the critical artifacts (see item #3 on this list) to amplify collaboration between PO and team.

The aim of that technique is to reduce the sense of loss of control that some PO’s have, and using the quick feedback cycles (Module 9 in the Coach Your Product Owner Course v2.0 LINK), give the PO a way to influence, yet not need to control, every single detailed decision.

9. The PO needs to serve and align with too many stakeholders

Product Owner Challenge Gamehouse Free

Sometimes, the PO’s lack of empowerment can come from having to manage and agree with many stakeholders (a specific aspect of the #6 on this list). However, this anti-pattern is more about enabling and managing communication with stakeholders. Aligning several stakeholders will require more time and focus from the Product Owner, which leads the PO to have less time available to work with the team…

This anti-pattern also highlights one of the most important jobs for the Scrum Master: coaching their PO to trust the team to make decisions when the PO is absent.

The Scrum Master must work on helping team and PO reach a productive collaboration approach, which will allow the PO to focus on managing the collaboration with the critical stakeholders.

The (surprising) 9 most common challenges that Product Owners face, that affect their Scrum team

Here’s the full list once more:

1. 1. The PO doesn’t have time
   2. The PO doesn’t have the right skills and I’m expected to train him/her
   3. The PO can’t create a Release plan (or other critical artifacts for that role, like Vision or Product Backlog)
   4. The PO does not engage with the team and ends up working alone
   5. The team suffers from slow feedback and the PO doesn’t get the feedback they need either
   6. The PO does not feel empowered or allowed to make decisions
   7. The PO serves many teams and/or has many roles
   8. The PO is a micro-manager and wants to control everything that happens
   9. The PO needs to serve and align with too many stakeholders

Have you seen some/many of these anti-patterns in your work?

Tweet us your example: @scrumpodcast or @duarte_vasco and share your experience as Scrum Master/Agile Coach helping your PO. Use the hashtag #CoachYourPO.

“Product Owner Challenge” is an agile game with Lego bricks I created. It supports organisations in transitioning from Waterfall to Agile and illustrates the agile mindset to a waterfall-driven product development culture: stop micro-management and communicate face-to-face clear objectives, requirements, and product vision. The product description is in one part of the room, PO, and DevTeam in the other. PO is not allowed to show it to DevTeam but can inspect the plan as often it's needed — PO has to 'walk & talk' – real challenges for traditional-minded product development departments. Game Objectives – Share product vision and instructions to the team as precisely as possible to build the product right. Communicate (requirements) as clear as possible. Learning Points – (1) Co-located collaboration leads to faster results and better quality; (2) Even as precise, clear, and distinct as possible, verbal communication alone is never precise, clear, and distinct enough; (3) Too detailed instructions hinder creativity and turn fast to micro-management.

See more at http://bit.ly/POChallenge. The game was presented at Play4Agile, Feb. 2014, Germany #play14, Mar. 2014, Luxembourg, and #t4at14, Oct. 2014, Germany.