Ill-defined Roles Block The Elevator!

As I considered the intricacies and difficulties of the Product Owner role, I was concerned that my perceptions might not be as inclusive as possible. In order to expand my understanding of the role and to test my experiences, I asked over fifty product owners why they thought the role was hard.  The majority responded and 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 product owner role is difficult, and perhaps consistently more difficult than any other role in software delivery.  Part of the difficulty is a reflection of information asymmetries, other difficulties arise because of how we use words or who is assigned to be product owners.  The next two of most common reasons the product owner role is difficult are:

  1. Having a Project versus Product Orientation. A product and project are very different constructs. A simple definition of a product is a set of related functions that are managed as a whole to satisfy a specific market need. The need and product evolve over time and typically follow a roadmap.   Projects have a beginning and an end, interact with and act on products.  Three simple comparisons illustrate the differences between the two concepts:
  •   Projects are temporary vs. Products are long lived.
  •   Products change based on need Projects have fixed constraints.
  •   Product teams are long-lived vs Projects teams are transitory.

Many short term behaviors occur when an organization adopts a project orientation rather than a product orientation.  Teams form and then dissipate as projects start and stop.  Stakeholders load up on the requirements, almost all of which are a top priority because they do not know when the next project will be funded.  In addition, changes to the requirements as stakeholders and teams learn are considered defects or at best change requests.  IN the end, these behaviors trade project optimization for the long-term value orientation a product focus would deliver. One of the most critical issues that arise when the two orientations collide, is that decision making becomes more complex. When project managers and product owners collide, one of the product owners responded:

“There is no clear owner or decision maker. This makes product development, prioritization, and stakeholder management very difficult.”

~Senior Manager – Strategic Planning
Name and Organization Withheld By Request

The Scaled Agile Framework Enterprise (SAFE) provides an example of an approach to shifting to a product orientation using the concept of a value streams and Agile release trains (ART). Value streams reflect a business orientation that integrates strategic themes and needs into how an organization delivers value. The products and services of most organizations tend to be long-lived, therefore value streams have the same long-term orientation. SAFe ARTs organize activity around value streams.  This is just one type of solution that seeks to shift organizations towards a longer term vision and focus.

  1. Ill-Defined Product Owner Role. The product owner role is defined with the broad statement such as “the product owner owns and maintains the backlog.” Alternately the role is defined as a laundry list (sometimes in intricate detail) of responsibilities ranging from attending meetings to the ultimate responsibility for the value delivered. The wide variety of definitions is bad enough between companies, however, definitions of the product owner often vary within departments within a company.  Ajay Reddy Author, Founder, Enterprise Coach, stated:

“The role is asked to be responsible for visioning, identification, sequencing (prioritizing), communication, and qualification of work among other things. In aberrant practices of the role, it is also made responsible for selection and scheduling etc.”

Within an organization, define the product owner role and hold the number of variations to a minimum so that a potential product owner and the rest of the team can have clear expectations. Clear expectations also make it possible to assess whether the PO needs to be a denizen of the Marvel Universe.

Kent McDonald, Product Manager, and Writer, Knowledge Bridge Partners  reminds us,

“The by-the-book description of product owner that requires someone to be all knowing about the problem and solution space, able to make decisions and make them stick, and available to the team as much as the team wants puts a lot of pressure on the product owner to be downright superhuman.”

The product owner role is difficult and can be even more complicated when the role is ill-defined or when we product concepts are overlaid on project concepts. Albeit common, these issues can be overcome.