Product Owner Anti-Patterns, and how Scrum Masters can help overcome those

Product Owners have an impossible job! I know, I’ve been a Product Owner. And even worse, a Product Manager transitioning to Product Owner! And even worse! I was also the Project Manager. Geeez! When I look back I am amazed I survived that phase of my career.

Here’s the kicker, that was the best time of my Agile adoption journey. I got to see my ideas come to life so quickly! And have a concrete business impact (the product we delivered went on to generate 10 Million Eur in sales a little over 3 years).

My Product Owner journey towards Agile was not easy! Let me tell you how I survived that stressful time, and lived on to learn a lot from the experience.

As a Project Manager and Product Manager, I had to really bend my thinking and my actions to fit the Agile way of working we were trying to adopt (Scrum was the approach we took at the time).

I had way too many meetings and was not available to the team as much as I wanted. The organization around me was first ignoring and then trying to micro-manage the product we were delivering. It was crazy! How did I survive that?

The stages of Product Ownership

I followed a simple model that I developed over time, and got great help from the team and some of the stakeholders!

First, I had to learn what knowledge and information the team needed to be able to work on their own, with minimal guidance from me. I was out visiting customers and selling the product, I did not have the possibility to be with them every day.

Without the team’s ability to bring in their commitment and imagination the product would not have worked. Thanks to this involvement I was able to visit customers nearly every week, including long inter-continental trips to learn about completely different markets!

With all that traveling I was running the risk of being a “Fly-by PO” (drop in, drop an idea, and drop out!). Thanks to the Product Vision we created together with Stakeholders and the team, the team was able to take up the slack and own the process of defining the details they needed to deliver.

The Product Vision Stage is only one of the 7 stages I used to help my former-PO self in that Agile adoption Journey. Here are all the stages I worked through:

1. Product Vision
2. Value Equation
3. Impact Mapping
4. Story Mapping
5. Backlog Management
6. Team Work
7. Market Validation

I struggled with every one of these stages as I learned the Product Owner role. I was definitely exhibiting many of the Anti-Patterns below at some point, and I would have failed without the help of my peers, the team, and stakeholders. That was when I realized the importance of coaching Product Owners. I was fortunately in a context where the team and stakeholders were there to help and cover for the gaps I was leaving. But not all Product Owners are so lucky.

The Product Owner anti-patterns below are some of the ones I experienced myself, and illustrate why it is important for Scrum Masters and Agile Coaches to help Product Owners, not only the teams.

7 Product Owner Anti-Patterns

Let me say that I’m sure you can think of other anti-patters.  This list is by no means the only or the most exhaustive list. This list is here help us detect when things are going wrong, and what we might be able to do to help the Product Owner (more on that below).

The Fly-By PO, lacking Vision that the team can use

Fly-by PO’s come to the team room, drop an idea, have a short conversation, and fly away. There are several reasons why they might repeat this pattern over and over again. One common reason is that they are busy with other responsibilities. Here’s the thing. Those responsibilities are ALSO legitimate, and they are no less important than working with the team. We can help the PO by helping them crystallize the Product Vision so that the team can drive the product daily decisions most of the time, and review those with the PO less frequently.

In well-functioning teams, the team takes more and more responsibility for decisions. They do this because they are aligned, and have a shared Vision with the Product Owner. The team “feels” the Product! How do we enable that? More on that below.

The Blind PO, lacking definition of success for the business and metrics to measure it

A sure-fire symptom of this anti-pattern is when you have multiple conversations per week where the PO explains at length the “need to have more features”. Now, sometimes more features are indeed the best way to reach our goals. But just like most of us use only a very small set of Features of Word (I’m using a plain text editor to write this!), the customers of our products or services don’t need more Features. In fact, there’s only one reason to add one more feature to the product: It solves a problem our customers already know they have (not one we think they will or “should” have).

The Blind PO is that which can only add more Features to try to affect the success of the product. This inevitably leads to huge backlogs and lack of direction for the team.

In well-functioning Product teams (including PO!), there’s a very clear link between product and Business success. And we know how to quantify both, leading to easier decisions and a very clear focus on what adds value to the customers. We need to crystallize the business Value our product delivers. How do we enable that? More on that below.

The “lead” PO, when the Product Owner is also the manager of the team

This can happen when the PO is either the direct manager for the team or the manager for a team of other PO’s. When this happens, the PO will usually be in many meetings related to their line responsibilities. This, in itself, is not the problem. The problem arises when the “lead” role of the PO takes precedence over focusing on the product success. In these cases, I have had success in separating the definition of product success from the line responsibilities, by for example, naming someone in the development team to be the PO, and having the line manager as a key stakeholder. The Product Backlog management can then be done together with the team, or with other stakeholders, where the line manager is then seen as a subject matter expert (which they are!) on product success.

In great teams, the business and product success is always decided collectively, together with the Product Owner, but never by the Product Owner alone. As Scrum Masters and Agile Coaches, we need to be able to facilitate this process. How do we do that? More on that below.

The “Need for Control”, when the PO cannot let others make decisions

If you see a Product Owner insisting she needs to write the User Stories alone, as well as the Acceptance Criteria ahead of a planning meeting, then you have seen this anti-pattern. The core function of User Stories is that they are part of a conversation between the PO, Stakeholder, and Team. Without that conversation, a User Story is little else than another requirements document!

How can we help the PO’s understand that User Stories can be written by anyone? The PO is responsible for their prioritization and understanding, but the idea can come from anywhere! We need to help the PO release control, however, this cannot be done in one go. Don’t rip off the band-aid or you will cause bleeding! We need to slowly walk the PO towards a more collaborative approach that has very concrete advantages for her as well! How do we do that? With specific and focused coaching actions, but more on that below.

The PO as a shopping list manager: order taker and little else

In some organizations, especially in companies new to Agile, there’s the expectation that the Product Owner is little else than a Backlog Secretary. They are supposed to get demands (not ideas!), order them (magically?), and make sure the team is busy (all the time!). Well, the role of keeping the Backlog healthy and small enough is definitely an important role. But that’s not what Product Owners should be spending most of their time in. How can we help them to slowly take ownership of the Product itself (the outcome), instead of the Backlog (the tool)?

We have to help the Product Owner delegate some of the work related to Backlog Management (for example: have quicker prioritization meetings! A method for quick prioritization will be included in the FREE mini-course below). By releasing some of the Backlog management work, the Product Owner can then start to manage stakeholder expectations effectively so that they can focus on the value they bring as product experts, rather than Powerpoint, JIRA or Excel wizards. How do we do that? More on that below.

The PO is too busy to help the team, so they need the team to help them!

A Product Owner that is too busy may lead the team down the wrong path because they just did not have time to give feedback. This can lead to big problems down the line. And although the PO might have created a Vision document for the team (as we saw in the Fly-by PO anti-pattern), that does not yet guarantee that the team can deliver what the PO has in mind. The collaboration practices between PO and team are critical to enable the team taking on some of the tasks that are expected from the PO. Only then can the PO solve the very legitimate other requests she gets from the rest of the organization. Driving collaboration between PO and team sits squarely in the Scrum Master assignment, but how can we make that happen? More on that below.

The Cowboy PO, riding lonely into the sunset (of their product?)

When PO is in a hurry, pressured from all directions, they will resort to “doing it themselves”. Kemosabe style! The problems are obvious: single-point of dependency, keeping the team waiting, bus factor of 1! And the list goes on.
It’s is critical to understand that Cowboy PO’s are trying their best, they genuinely want to help but are running out of ideas (and possibly motivation) to do the hard work of sparking collaboration. Here again is where a great Scrum Master comes to the rescue! We, as Scrum Masters and Agile Coaches, can help the Product Owner prioritize their work to focus on generating that collaboration that will help her reduce the work-load, and get back to focusing on working together with Stakeholders and the team.

We may need to help facilitate certain ceremonies (many of which we cover in the course below), or just establish a more regular check-in with the team using effective facilitation practices that help the team carry more responsibility. How can we make that happen? More on that below.

Making it happen

Now it is time to make it happen. But there’s a problem: we don’t manage the Product Owner. As Agile Coaches and Scrum Masters, we can help the Product Owner. First, we need to help the PO realize the problem, and then motivate (and support her!) to find a solution. How can we do that? With the most important tool we have in our toolbox: Coaching Questions! Here’s one example. For teams that are missing a Vision from the Product Owner, we might want to ask the following questions from the Product Owner:

• If you were able to easily and successfully communicate the direction of the product how would that help you?

With this question, we are helping the Product Owner visualize a different reality and think through the benefits of that possible future. If they can’t think about those right away, we might want to ask:

• Imagine what impact it would have in the planning meeting if you never had to explain why we do certain features, but instead, you would get ideas back from the team, that felt like they were reading your mind before you could?

Again, here we focus on the benefits that a shared Vision could bring. In the hope that the Product owner would be able to find their own reasons to create that shared Vision. But sometimes that is not possible, so we might ask instead:

• What is preventing you from getting the team and stakeholders to understand your goal of the product and the business?

With this question, we tackle the possible limiting beliefs the Product Owner has related to her ability to communicate with the people around her. With questions like these, we can open the lines of communication, and show that we have aligned goals with the Product Owner! Finally, we want to get them to find their own ways to solve the problems that are keeping them stuck in the anti-patterns we listed above.

But do you have permission to help the Product Owner?

“The Product Owner will never listen to me!” This is a phrase I’ve heard from countless Scrum Masters and Agile Coaches. And sometimes, it is true! So first we need to consider how we obtain permission to help the Product Owner. And we do that through a Coaching Agreement that we set up to be able to help the Product Owner. In the course below, which you can get for free right now, we will cover:

• The Coaching Questions we can ask Product Owners to help them avoid or resolve the Anti-Patterns listed above
• How to help transition Product Managers to the Product Owner role, and set up and coaching agreement that we need to do that
• How to define Metrics that can be used to help us succeed and the key difference between Vanity Metrics and ACTIONABLE metrics!

Putting it all together

The three video modules I created for you include concrete actionable ideas you can use immediately to help your Product Owner be Awesome!

Sometimes we need more, and Product Owners face many other problems in their aim to help the team make the product a success. In the full course (the mini-course is FREE! ;), we will also cover:

• How to define a Product Vision: a step-by-step guide to preparing, hosting and facilitating a Vision workshop for your Product
• Roadmaps that actually work! Especially when traditional roadmaps tend to drive the product development process deep into the waterfall!
• Quick prioritization techniques, using 2 minutes, instead of 2 hours. So that we can involve all stakeholders, even the busiest (and usually critical) ones!
• How to size Backlog Items in a way that does not need estimation, and helps drive collaboration. The focus being collaboration, not estimation! In this module, you also get the NoEstimates book for free!
• Quickly crafting acceptance criteria. Where we include cheat sheet that helps you write acceptance criteria for anyone, even in a coffee break!