How agile Product Owners are killing development teams

Agile represented a giant leap forward above and beyond stage gate waterfall development practice. Agile is not without its own challenges as we all know. Often velocity is hard to measure and stabilize, team demos often attract no stakeholders after the first few, and sprint planning can sometimes take hours. These are all solvable to a degree with discipline. Some of the biggest problems teams face stem from the role of the Product Owner. In this article, I'll illustrate the problems associated with the product owner role and in the next article suggest a solution to the problem. There are three key problems associated with the role.

  1. The product owner role reduces ownership and demotivates team members.
  2. The product owner role distances teams from their customers resulting in lower quality products.
  3. The product owner role reduces team efficiency by poor communication through user stories.

The role of product owner reduces the ownership and motivation of team members by controlling what can be built and when. Product owners own what is built and in what order it is built. In autonomous agile teams, this often turns them into managers of a sort. Team ownership is reduced when individual members must ask permission to pursue a great idea to improve their product. The autonomy of the members of the team is diminished when they are no longer a group of equals. The product owner role creates this dynamic. Another unfortunate side-effect of having someone "own" the product is now great ideas become someone else's job. Team members fall into a routine of heads down coding instead of thinking about their products.

Even more problematic is the fact that the product owner role distances team members from their customers. The agile manifesto clearly states "The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation."
Where the whole team or a given team member might otherwise be motivated to talk directly with their customer or stakeholder with a product owner involved there is little incentive to do so. First of all that's the product owners job, and secondly, if the team member learned something very useful he must still face the prospect of rejection, or the uphill climb of selling the idea to the product owner who usually has his or her own priorities and exciting ideas to think about. Since the team members are not expected to, nor incentivized to speak directly with their customers a game of telephone is then played. Developers who often want to stay heads down, do stay heads down, and receive a lot of second or third-hand information from the product owner regarding what to build. The people building the product lose touch with the people they are building it for.

The product owner role reduces team efficiency due to poor communication through user stories. Due to reduced meaningful interaction with stakeholders those building the product often only know what to build through the user stories the read. Stories represent written second or third-hand product information. These stories have little context associated with them and so team members become more siloed in their thinking; incapable of thinking broadly about their own products. Instead of having a team of engaged people bringing innovative ideas to the fore you have one person thinking about the product and a much larger number very much unable to.

Teams thrive and brilliant products get created when teams are deeply connected to their customers/stakeholders. A key part of making this happen is ensuring that no one person has the power to own that relationship. The product owner through the ability to say what and in what order effectively controls the customer relationship. Remove this and distribute that ownership and see product development teams thrive.

If you're interested in what to replace it with, see my next article on how development teams can improve productivity by removing the role of product owner.