Accept no substitute.

The product owner (PO) role even when performed as described straight out of the book is difficult.  The role is often even more difficult than it needs to be, with information asymmetries between the PO, the team and stakeholders ranging to ill-defined roles. I asked over fifty product owners about why they thought the role was hard to augment my perception. I have scattered excerpts from their responses throughout the essay.  Based on observation and responses the most common reasons the role is difficult are:

  1. Product Owners Are From IT
  2. Product Owners Are Not Part of The Team
  3. Having a Project versus Product Orientation
  4. Overly Broad and/or Ill-Defined Product Owner Role
  5. Using Proxy Product Owners
  6. Adopting Technical and Business Product Owners
  7. Allowing Part-time Product Owners
  8. Failure of Product Owner to Lead
  9. Product Owner with Controlling Personality

The next set of difficulties are:

5. Proxy Product Owners.
POs come from the business and are the voice of the customer.  As part of the role, POs prioritize the backlog and make far-reaching decisions about what will be built, configured or assembled. Sometimes someone other than the person that should be the PO is tapped to play the role. This occurs for many reasons.  One reason organizations select a proxy is that the PO role requires an amount of time and effort that might not be available from the right person.  A second common reason that IT and the business have not agreed on the need for the role.  Proxy product owners reduce the amount of business acumen available to the team while they are making the myriad of decisions that a team makes daily. Proxies can also reinforce the divide between IT and the business, increases the need for oversight and gate-like reviews, which don’t foster trust, slow decision making and increase cost.  Simply put, each Agile team needs a real product owner from the business, or they risk delivering the wrong functionality 
The solution for this issue is fairly stark.  Don’t accept a proxy product owner. One quick technique to recognize whether someone is a proxy is to determine if they need to get permission to make decisions.  If a proxy is all that your organization can deliver, leverage the person as a business analyst and leverage classic deliverable sign-offs and reviews to generate important decisions.  Rework will be higher and delivery rates will be slower, but what finally gets delivered will be closer to what is needed.

6. Adopting Both A Technical and Business Product Owner.
This scenario might be considered a special type of proxy product owner.  Organizations that adopt this approach are typically accepting and solidifying the hard boundaries between the IT and the business.  The problem (or at least assumed problem) that this solution addresses are the perception that the product owner cannot speak for or advocate for the non-functional requirements of a piece of work.  For example, I recently heard this approach justified with the explanation that the business product owner did not understand technical debt, coding standards, class structures, interfaces and hardware requirements(it was inferred that they did not want to understand).  No one in the organization wanted to address the underlying behavior.

A product owner must have a grasp of both the technical and functional components of their product.  This is another instance where the project/product conundrum seeps in.  It is easy to ignore or lean on someone else for a specific piece of knowledge if the need for that piece of information will go away sometime in the near future. Remember that projects have a stated completion date, while products do not. Teams and organizations need to educate product owners on the technical aspects of the work they are involved in delivering.  Product owners need to actively seek technical acumen to augment their business knowledge.  Failing a willingness to tackle the knowledge gap by either side having both a business and technical product owner might be the best pragmatic solution, but a solution that is significantly sub-optimal.

We continue delving into the problems that beset the product owner role in our next installment.