Doing the Product Owner Role Poorly is Like Drowning!

The product owner role is evolving in most organizations. The role has its roots in the roles of product managers, project managers, business subject matter experts (SME) and project sponsors from other methods.  The roles and the responsibilities of the role are critical in any Agile approach to delivering value. The product owner role is difficult, and perhaps consistently more difficult than any other role in software delivery.  The reasons the role is difficult can be traced to several solvable scenarios. The most common reasons 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

Each of these issues is important in its own right and is eminently solvable with the right amount of focus and energy. Some of the energy might be spent on process changes, training or culture change. The culture change might include changing how an organization thinks and works and some really hard scenarios that change might require changing the impact of the culture outside the organization on the organization.

Defining and exploring each of these issues will provide readers with an understanding of why the issue can reduce the ability of a team or teams to deliver value and, more importantly, ideas for tackling these issues.  The first two are:

  1. Product Owners From IT.  Product owners represent the voice of the customer.The person in this role is ultimately responsible for what is on the backlog, how it is prioritized and is accountable for the value delivered by the effort delivered.  Arguably these responsibilities once resided in the list of responsibilities of the sponsor and to a lesser extent, the project manager. The ability to own the backlog and the value delivered requires not only business acumen but the power to make decisions that impact how the business behaves. Those outside the business hierarchy typically do not have the knowledge or political power.   In scenarios where the business can’t or won’t participate as the product owner consider several potential solutions.  The best solution often is not to take the project. In scenarios where the team wants to use Agile techniques and the business won’t communicate, problems typically arise and the team will tend to develop a we/they attitude which causes friction. Perhaps a more pragmatic set of solutions includes adopting a hybrid control based/Agile approach.  In this scenario, deliverables are often used to identify what needs to be delivered and to assign the responsibility and accountability for delivering value.   An extreme version of this issue occurs when work is outsourced and the product owner is from the organization the work has been outsourced to.  The firm delivering the work can in no way speak for the business.  This extreme version often generates a mismatch between what is delivered and what is needed. This scenario requires upfront agreement on formal processes, deliverables, inspections, and contracts so that both parties are safe.
  2. Product Owners Are Not Part of The Team. The product owner is a team member.  A team member needs to participate in the ceremonies/meetings/gatherings (pick the word you want to use) the team uses and be available to review activity of other team members, groom the backlog, answer questions, help the team to network properly and to provide leadership. The responsibilities identified as belonging to the product owner require intimate interaction and communication, this level of intimacy is rarely possible for outsiders to attain.   The simplest solution is for the product owner to commit to being part of the team even if their participation is limited. The product owner needs to be very upfront and transparent about their level of participation and how they expect the team to adapt to their level of participation.  The extreme outsider is represented by the outsourced scenario.  In this scenario the product owner representing the business is an employee of a separate company; the company that owns the contract and the ability to control payments. Outsourcers often do not want outsiders to see their internal processes and potentially dirty laundry. Making this scenario work requires a culture change in both organizations.  The product owner and team must develop an environment of trust and a focus on a common goal.  The product owner and others on the team need to adopt the team as their primary team rather than their work group or even the organization they ultimately are paid by.  Where this culture change does not occur trust must be replaced by deliverables, standard auditable processes, and the contracts that enforce them.

Both of these scenarios, if not corrected, create information asymmetry in which both sides of the equation suffer.  Ensuring that the product owner is from the business and acts as a team member does not totally erase any possible chance of information asymmetry, but it reduces the likelihood that the business or development will end up on the short end of the stick.  As the product owner role is used and explored in an organization, the person or persons playing the role look for ways to avoid information asymmetry and other shortcomings forcing the role to evolve.  

Next: Avoiding and/or fixing scenarios 3 – 7.