When a Product Owner isn’t Held Accountable

Next up in my blog series on “Anti-patterns that Doom Product Owners to Fail” is the topic of accountability. Product Owners need to be accountable for the outcome of their product, but sometimes they aren’t. Read on to learn about these anti-patterns to avoid:

Not the “one neck to ring”

Problem

The Product Owner is really where the buck stops, or to use a common phrase (that I’m not overly fond of), the PO is the “one neck to ring.” In other words, if the Product Owner doesn’t have complete responsibility for the outcome of the product, s/he’s not the owner of the product at all. When this happens, responsibility tends to live much higher up on the food chain, which is a huge problem.

Solution

Ensure the Product Owner has the authority to truly “own” the product and then hold the Product Owner accountable for the product outcomes. Use metrics to track critical KPIs that define product success. Then, if the product isn’t successful, only one person is to blame.

Throws the team under the bus

Problem

Let’s say that your Scrum Team had a lofty Sprint Goal, but for some unexpected reason, the team wasn’t able to accomplish their goal. Instead of being transparent and explaining the cause to the stakeholders, the Product Owner deflects responsibility and blames the team or makes excuses for them.

old trolleybus riding on night street

Solution

Win as a team, lose as a team. The Product Owner is also a member of the Scrum Team, and while s/he is ultimately accountable, the whole team is responsible to get the work done. Never throw your team under the bus. Be honest with your stakeholders and always support your team, regardless of whether you meet your goals. This will build trust between both the team and your stakeholders.

Not held accountable for the product and its outcomes

Problem

Have you ever worked at an organization where failure isn’t acknowledged? Unfortunately, I have been in this position before, and it’s bizarre. Rather than recognizing that something didn’t work, was over budget, or the product wasn’t valuable, the company swept it under the rug. It was a cultural problem, and everyone was too “nice” to do anything about it. Unsuccessful Product Owners could continue to operate under these conditions without any consequences or remediation.

wood typography photography blur

Solution

Don’t be afraid to fail. Failure will happen. It’s how we learn and discover new things. Look at failure as a learning opportunity, not a negative problem that has no solution. At the same time, hold the Product Owner accountable if s/he doesn’t learn from these mistakes and continues down the wrong path. Things will always change – change is constant – but keep working toward your measurable goals and focus on outcomes.

No one can identify or who the Product Owner is

Problem

Do you have an identified and empowered Product Owner? If you don’t, then you are in big trouble. Sadly, this situation does happen in some organizations. No one is willing to “own” the product, and it’s unclear who is sailing the ship. When this does occur, the team will seriously struggle without having a single source of direction and decision-making.

group oo people having a meeting

Solution

You must have a named Product Owner who has full authority to make all decisions regarding the product. The Product Owner cannot be multiple people or a committee. Nail down who owns the product and give him/her the tools needed to get the job done.

Takes all the credit for the team’s work

Problem

Sometimes when I write about these anti-patterns, I have a hard time believing that I have seen them happen – but I have. In this case, the Product Owner takes all the credit for the team’s success. Rather than letting the Developers showcase their work, the Product Owner keeps them away from the stakeholders and presents on their behalf, taking all the credit and glory.

Solution

Again, it comes back to being a team. Give credit where credit is due. There is a specific reason that the Sprint Review is Developer-led and not necessarily the Product Owner. Rather than hiding the Developers in the closet, shine a light on them and let them bask in the glow of pride in a job well done.

Always making excuses

Problem

Excuses, excuses. Product Owners who are constantly making up excuses about why something has or hasn’t happened can drag a team down. Using excuses is also a form of dishonesty or lack of transparency; this will cause stakeholders to feel angst and ultimately cause trust to erode.

Solution

Always be honest. You can explain reasons why something happened, but don’t use excuses. No one cares about your excuses. So instead, be truthful and transparent. As long as you can do this and provide a way forward, the chances are good that your stakeholders will be understanding.

Final Thoughts

Being a Product Owner is no easy task. To succeed, a single PO needs to be fully authorized and able to make all product decisions. Product Owners should be humble and act as a member of the team, and win or lose as a team.

Now, it’s your turn. Have you seen any issues like these with Product Owners at your organization? Feel free to share your horror stories with me. I would love to hear all about it!