In this installment of my blog series on “Anti-patterns that Doom Product Owners to Fail” I tackle the topic of uncommitted Product Owners, and what happens when they aren’t interested, available, or engaged. You may run into one or many of these situations when an Agile transformation happens, so be extremely careful when you decide who is going to become a Product Owner. Now, let’s take a look at these anti-patterns:
The Product Owner was “promoted” from a Manager position
Problem
In working with large companies going through Agile transformations, I have noticed a tendency for companies to try dropping existing middle-managers into either Product Owner or Scrum Master roles. But just because their old title and job responsibilities contain the word “Manager” doesn’t mean the person will be good at either of these jobs. Their traits and tendencies may even be detrimental to their ability to succeed in either one.
Solution
Don’t assume that a manager is a good fit for a Product Ownership role. Being a Product Owner does involve some management, but it’s not the management of people or tasks – it’s management and responsibility for the Product Backlog. If you are going to attempt to fill a PO role with a manager, make sure s/he understands the differences between the roles and that the expectations are clear. Then keep a close eye on their performance to see if it’s a good fit, and if not, make a change.
The Product Owner delegates his/her responsibilities
Problem
Product Owners shouldn’t do the job of Product Ownership all alone – they should have help from the rest of the Scrum Team. But some Product Owners take this to mean that they can delegate everything, including important decisions that only the Product Owner should make. In essence, the person who makes the decisions (often a Business Analyst) becomes known as a Product Owner Proxy, which isn’t usually a good thing.
Solution
Make sure that the Product Owner knows what tasks s/he is specifically responsible for. There should also be a clear understanding about which things can and cannot be delegated – principally making critical decisions. The Product Owner is still responsible for the Product Backlog and value maximization of the delivered product; some work can be delegated, but not all of it. If the PO does decide to assign things to others, make sure the people doing the work understand where the boundaries are between their work and the Product Owner’s.
The Product Owner role was imposed upon them
Problem
The person given the Product Owner job didn’t even want it. They might have been the default choice because of their subject matter expertise, availability, or other reasons, but that doesn’t mean the person wanted the job. People who have change thrust upon them versus being involved in the transition generally aren’t happy. This will cause a negative attitude, and the person will be very lackluster in their performance as a Product Owner.
Solution
Don’t give someone a job that s/he doesn’t even want. Get the candidate’s opinion about taking on the Product Owner role before making an assignment. You should also educate the person about the skills and responsibilities needed to be a Product Owner. Then, do an honest assessment of whether the person meets the requirements for the role. If the candidate does express interest after knowing all the facts, it’s more likely that s/he will be willing to step up to the plate to do the job.
The Product Owner leaves the Team to their own devices
Problem
The Product Owner doesn’t feel a sense of responsibility to the rest of the Scrum Team and leaves them to their own devices. A Product Owner who isn’t available or present won’t actively communicate with the Team. As such, decisions may be delayed, questions will be left open, and the Team will become hamstrung by the Product Owner’s apparent absence.
Solution
The Product Owner must be held accountable for his/her responsibilities. If the PO isn’t responsive or available, the Team should try to re-establish the necessary connection with the Product Owner. And if that doesn’t work, they should escalate to the Scrum Master to resolve the issues. It may be that the Product Owner has other responsibilities that are unknown to the Team, and the Scrum Master can help remove those from the PO’s plate.
The Product Owner is present but not engaged
Problem
In this case, the Product Owner may show up in body, but not in spirit. A disengaged Product Owner is almost worse than the previous problem. If the PO is merely going through the motions but not doing any meaningful work, the Team won’t make forward progress. The Team could end up meandering meaninglessly without a real captain at the helm of the ship.
Solution
Don’t assign someone who is lackluster about the product as a Product Owner. Passion for one’s product is an essential attribute of a successful Product Owner. Be sure that the PO understands that s/he is part of the Team and not off on a separate island in a silo – the Product Owner is the most crucial of any Scrum role.
Only in the role because they are a department head or manager
Problem
When organizations go through an Agile transformation, specific roles inevitably become almost unnecessary. Chief among them are managers (already mentioned) or department heads. These leaders are used to directing work and usually resist the idea of allowing a small team to self-manage. When introducing Agile, it’s a threat to traditional management jobs. Managers may see the Product Owner or Scrum Master roles as their only options. Otherwise, to be a mere developer on a Scrum Team would seem like a demotion.
Solution
Before sliding someone into the role of Product Owner, make sure you understand the person’s motivations for wanting the position. If they are signing up only out of fear, they will most likely be ineffective as a Product Owner. Or, even worse, the person may actively sabotage their Scrum Team to cause the Agile transformation to fail to maintain their status within the organization.
Not invested in the product – it’s just a “job”
Problem
If your Product Owner doesn’t care and considers their role as a job more than a career, then s/he won’t be invested in the product. Without support from the Product Owner, the Team will feel apathetic. Rather than being an inspiration and source of direction for the Scrum Team, this type of Product Owner will drag the Team down.
Solution
Don’t give the Product Owner role to someone whose interest is merely lackluster. The Product Owner needs to be passionate about the product and feel a true sense of ownership. If the PO possesses these attributes, the Scrum Team will support the Product Owner’s vision and do whatever it takes to deliver successful outcomes.
Product Ownership conducted by Committee, not one person
Problem
Last but not least is when there isn’t a single Product Owner who is responsible for making all product decisions. Instead, a committee of competing stakeholders plays the Product Owner. This situation will NEVER work. There’s just no way that a whole bunch of cooks in the same kitchen will make anything edible. The same is true when it comes to this situation.
Solution
There must be ONLY ONE Product Owner for a product. That person is solely responsible for maximizing product value and managing the Product Backlog. But, the Product Owner will still consider the needs and requests of the stakeholders. Sometimes, the Product Owner will make decisions that may make some stakeholders happy and others unhappy. However, this problem tends to work itself out, as transparency allows stakeholders to see where their requests are in the Product Backlog.
Final Thoughts
Product Owners are the most critical people on Scrum Teams. Their importance really can’t be overstated. To succeed, a PO must communicate, be a part of the Scrum Team, and represent both the stakeholders and the Voice of the Customer. Being a Product Owner is a hard job to do, but by avoiding the anti-patterns in the blog, you’re much more likely to succeed.
So, what do you think? Have you seen any Product Owners exhibit any of these issues? What happened? Have you seen anything else that has caused problems on a Scrum Team when it comes to the Product Owner? I’d love to hear your stories – good or bad! Please drop me a note in the comments below!