10 Painful Product Owner Mistakes

To the detriment of their Product

The Product Owner leads the team in its journey to create and sustain a product. She or he is accountable for maximizing the value of the product and for effective Product Backlog management.

Product Backlog management includes:

• defining and communicating the Product Goal;
• creating and ordering the Product Backlog Items;
• ensuring the Product Backlog is transparent and understood by the team and the stakeholders.

At first glance, Product Backlog management may seem like an admin responsibility. But if you unpack this accountability, to maximize the value of the product, you will see this term is a euphemism for:

• establishing a vision of the future state of the product;
• look into the current value and unrealized value of the product;
• translating this vision into a Product Goal;
• determining ways to verify if this Product Goal is being achieved;
• outline the direction to achieve the Product Goal;
• gather customer feedback, competitor analysis and other information to inspect if the team is moving in the right direction;
• adapt the Product Backlog according to new insights to achieve the Product Goal.

The Product Owner is vital for the success of the Scrum Team. Many Product Owners struggle. As a trainer, coach, writer, and Serious Scrum community member I interact with many Product Owners. From these interactions, I concluded the Product Owner accountability is widely misunderstood.

Here are the 10 biggest Product Owner mistakes, to the detriment of their product.

1. No ownership

This is a Product Owner in name only, owning nothing. Powerful stakeholders are calling the shots, determining the Product Goal and the order of the Product Backlog. The “Product Owner” is merely passing on requirements.

Why is this a problem? Well, these Product Owners don’t have any mandate to alter the Product Backlog based on new insights. And this is an issue. Scrum is a framework to manage complexity and work with the unknown. The Product Owner should be able to change direction and update the Product Backlog to optimize the chances to meet the Product Goal.

Without ownership, the Product Owner can’t succeed in their job.

2. Saying ‘Yes’ to everything

Closely related to the previous point is the Product Owner who says ‘Yes’ to every stakeholder request. Especially when the request comes from someone with power.

This is a bad thing because the Product Owner should ensure to maximize the value of the product. In a complex environment, it is impossible this always comes from upfront stakeholder requests. People with power aren’t always right and are limited by the information before they start doing the work.

The Product Owner should weigh all the requests, assess how they add to the value of the product and the Product Goal and then order the Product Backlog accordingly. And when the request is implemented, the Product Owner should ensure to have feedback on the actually delivered value.

3. No Sprint Goal / Planning to hit the velocity target

The Sprint Planning should evolve around the Sprint Goal. This should answer the question “What do we wish to achieve by the end of the Sprint?” The Sprint Goal is leading. It helps the team to pivot if they find they are no longer on the best path to achieve it.

Sadly many Product Owners aim to fill the Sprint Backlog with as many items as they can. They want to hit the velocity target and will even add small items to “fill the gaps” even when these don’t contribute to a goal.

They wish to have an efficient team that uses its total capacity. They shiver when they think some of the Developers would sit on their hands, being idle. They hate potential capacity waste.

But this approach doesn’t work in complex environments. Teams should have room to breathe and think. They should have the space to contemplate if they are still moving in the right direction, towards the Sprint Goal. By striving for high utilization, you miss out to deliver results.

4. Detailed planning

Scrum is a framework to create value in a complex environment. The desired value is an outcome, defined as a Product Goal. This goal is the North Star for the Scrum Team.

The team needs to take into account that “In complex environments, what will happen is unknown.”- Scrum Guide 2020. This means that detailed plans do not work. Scrum Teams need to be able to adapt to maximize the chance of meeting their goal.

Detailed plans don’t work beyond a Sprint, but also not within a Sprint. Even within the timebox of one Sprint, the Developers have a goal as their commitment. This Sprint Goal determines the actions of the team throughout the Sprint.

A Product Owner can suggest an approach during the Sprint Planning. But the approach has to be highly adaptable. It doesn’t make sense to create detailed plans that could be altered a day later.

5. Tell the team how to do their work

A Product Owner focuses on maximizing the value of the product. This means she/he takes the lead in what the team will focus on. But the Product Owner doesn’t decide how the work will be done.

The Developers are responsible for how they will do the work to achieve their Sprint Goal. They are the ones who create the product Increments. It is their accountability to uncover and implement the best possible solutions.

Sure, a Product Owner can challenge the decisions of the Developers. As an example, when the Developers wish to build a cool module to import data, a Product Owner could ask the question if they can’t suffice with a script. A module is cooler to build, but it doesn’t add value. As Leonard Da Vinci put it: “Simplicity is the ultimate sophistication.”In complex environments, you can’t say upfront what is the best way to achieve the Sprint Goal. This is also true for the Product Owner.

6. Focus on output instead of value

I already discussed how detailed plans do not work in complex environments. The same is true for focusing on the output. With this, I mean a Product Owner who doesn’t verify if all the implemented features are actually bringing value. This is strongly related to not having a Sprint Goal.

This failure to verify the outcome is catastrophic in complex environments, where assumptions are dangerous. It is mindblowing to see how many Product Owners work this way, helping to create a feature factory.

“Delivering features doesn’t mean you are delivering value, just like telling a joke doesn’t mean people will laugh.” — Maarten Dalmijn

7. Ask the team to bypass the Definition of Done

This is another anti-pattern that has its roots in misunderstanding what Scrum is about. In this case, it is the misconception that teams commit to delivering within a Sprint.

Product Owners who look at Scrum this way will see a Sprint as a failure when the Developers don’t deliver their planned Increments. Some will ask the Developers to go ahead with deployment, even if this means that the Increment doesn’t adhere to the Definition of Done. For example, I have often heard Product Owners asking to skip the final testing activity.

This practice shows a failure to understand that the Increment and Definition of Done serve empiricism. They help the team and stakeholders understand if assumptions were correct and serve to get new insights.

When the team can’t show a Done Increment at the Sprint Review, the learning is the team had expected to meet their Sprint Goal, but new developments made them realise they couldn’t. This is valuable information for the next Sprint.

Sure, a team commits to meeting their Sprint Goal. But they may occasionally miss this goal. As long as this doesn’t happen every Sprint and as long as the team moves towards the Product Goal this should be ok. A team should feel safe to set Big Hairy Audacious Goals.

8. Neglecting the Sprint Review / Ignoring stakeholder feedback

For a Product Owner, the Sprint Review is arguably the most important Scrum event. It is Scrum’s steering committee. It is here where the Product Owner aligns with the stakeholders on how they can maximize the chances to meet the Product Goal. But many Product Owners neglect its value.

Some Product Owners view the Sprint Review as a demo or presentation to explain to stakeholders what the team achieved in the last Sprint. The stakeholders don’t get the opportunity to provide feedback. This makes the event a lost opportunity to learn, inspect and adapt.

Other Product Owners may use the Sprint Review to align with stakeholders, but they fail to have the important stakeholders at the table. They don’t succeed in explaining the importance of the Sprint Review and the collaboration of the stakeholders at the event. This again is a lost opportunity to learn.

Some Product Owners even won't consider any feedback from their stakeholders. I don’t think I have to argue why this is a bad thing.

9. Forgetting the big picture

Another misstep I have encountered is the failure to have a bigger picture in mind. These Product Owners only look one Sprint ahead. Whatever happens after that is up for grasp. Often I hear arguments like:

“We are working agile so we don’t plan beyond a Sprint.”

This is a faulty interpretation of Scrum and Agile. It is true that there will be many uncertainties and thus reasons to change course. But you can only adapt and respond to change if there’s a direction, to begin with. And this is the direction towards the mutual goal, the Product Goal.

Without the Product Goal and the accompanying big picture, the Product Owner is running blind.

10. Managing a team backlog

Many Product Owners don't own a product at all. They own a team’s backlog. Multiple Product Owners are in this situation. Their task is to ensure their teams work on the highest priority items as a cog in a wheel.

Together, these teams move along on an endeavour. The Product Owners don’t have to verify the value of the work of their team. They merely have to verify if the work was done according to expectations.

This setup often exists in a SAFe environment. The problem with this is that there’s no proper feedback loop on value. The teams work on items without knowing or checking if they bring the highest value. They are stuck in a team bubble.

Product Owners that have to work a team backlog have no resemblance with the Product Owner as intended by Scrum.

I also see this issue on a smaller scale, where multiple Product Owners are responsible for one product. In itself, I can see the merit of having multiple people doing the Product Owner work. Although this is not according to the Scrum Guide.

But they should then still work from one Product Backlog. Otherwise, they don’t align properly to maximize the value of the product. They would have a high risk of a scattered focus and misaligned goals.

Conclusion

The Product Owner is crucial to the success of the Scrum Team(s). She or he watches over the maximisation of the value of the product. This is why a Scrum Team exists in the first place.

But there are many pitfalls. A common one is an assumption that a Product Owner should be focused on timely delivery. Scrum does underline the importance of having a long term objective. But Scrum also acknowledges the uncertainty that comes with complexity.

Product Owners should guide their team(s) and stakeholders on the journey of value creation. They should focus on the outcomes and goals. They should embrace learning.

They should focus on the WHAT and let the Developers focus on the HOW. They should avoid long-term planning and micro-managing. They should let creativity flourish.