Six Common Mistakes of a Product Owner

How do you cope with the weak Product Owner?

You don’t – find a new Product Owner (PO) or stop using Scrum.  Scrum is based on the idea that an empowered, knowledgable business leader is setting direction for the product (or service) under development.  When that person does not exist, or is weak, Scrum falters and eventually fails.

Many times, a weak PO is just the result of someone not fully inhabiting their role.  Here are some patterns and commom mistakes that indicate the PO is not truly acting as the PO and some ideas to help them improve.

1. Unfamiliar with the domain: you cannot fix this problem.  The answer to this problem is to find another PO with the requisite knowledge and experience to perform the role.
2. Not a business leader: I see a lot of business analysts (BAs) acting as PO or as PO proxies (ugh!).  I have never seen this work.  If this is your scenario, I recommend educating the Stakeholders on the role and scope of the PO’s responsibilities.  Ask the Stakeholders to supply a business leader who is interested in performing this role.  I find framing the request as a timeboxed experiment with clear success and exit criteria helps a lot.  If the Stakeholders will not supply someone who is a business leader, gather the data to build the case that shows how a real business leader would deliver better outcomes to the customers.
3. Cannot say “no”: one of the main reasons why the BA as PO\PO proxy does not work is because most BA lack the courage (and authorization) to say “no” to business leaders, executives or customers.  In my opinion, a PO that cannot say “no” is completely useless because any “yes” they give is meaningless.  I have found a few ways to help a PO fix this issue.  I would begin by teaching the PO techniques to say “no” in a way that is respectful, yet firm.  Another option I have tried is to find someone who can say “no” (someone courageous and authorized) and ask them to be the PO.  If both these ideas are not going to work, then I would bring the situation to the attention of the Stakeholders and ask them how they would want me to proceed.
4. Cannot decide: a good PO needs to be comfortable making decisions in the face of uncertain and incomplete information.  However, there are times when PO has a really difficult time deciding.  One approach to help the PO with this problem is to offer the option of deferring the decision, i.e. making a conscious, deliberate choice to defer a decision to a specific date in the future and then revisit the decision on that date.  Perhaps by the time the new dates comes up, the PO will learn something new, the issue will fix itself or go away (hey..it happens!)  Alternatively, I might formulate a hypothesis with the PO and then design a low-cost experiment that will either prove or deny the hypothesis.  Or I might use a technique called pessimize to think about the various worse case scenarios that might happen.  Usually, pessimizing the decision makes the choice less scary.  However, that is not always the case, so my last recommendation would be to ask the PO this question, “What is the smallest decision we can make right now that will move us forward and still be safe?”
5. Micromanages the Team: there are a few things to do when the PO is acting like the boss or designing the product for the Team.  I would begin by reminding the PO that their role is to communicate needs and priorities of the product and to allow the Team to think through the technical solution on their own.  If the micromanaging continues, I might teach the Team members techniques to tell the PO “no” in way that is respectful, yet firm.  When people have agreed to unrealistic expectations imposed by other, they sometimes cope by micromanaging others.  If I saw persistent micromanaging behaviors from a PO, I would spend time trying to understand if this was the case and help PO reduce expectations and/or their stress levels.  If none of these strategies were producing results, then I would bring the situation to the attention of the Stakeholders and ask them how they would want me to proceed.
6. Unavailable to the Team: in order to reduce time spent waiting, the PO needs to give feedback to the Team throughout the Sprint and quickly respond to their questions.  When the PO is unavailable, this adds unnecessary delays.  If this was occurring frequently, I would have a private conversation with the PO about how they are contributing to the Scrum Team’s delays and ask if there was anything I could to help the PO.  If that discussion had no effect, then I would bring the situation to the attention of the Stakeholders and ask them how they would want me to proceed.

If you want more ways to see if your PO is not quite ready for the job, check out this article about common PO traps from Certified Scrum Trainer Roman Pichler.