How organizations or enterprises define the roles and responsibilities of the Product Owner (PO) and how they organize their resources can vary. The factors that influence this decision are numerous, and these variables certainly can change over time. But, generally how the PO position is defined hinges on the type of organization: Software Product Organization (SPO; i.e. Amazon) or Software Supported Organization (SSO; i.e Wells Fargo), the domain (public or private), the size and complexity of the product, and where the product is in its life-cycle.
Striking the right balance presents a dilemma for organizations, especially if they attempt to lean the value stream by minimizing hand-offs and delays from collective decision-making between numerous “product owners” – which is done to avoid burning out personnel or slowing down development by over-burdening a single individual.
PO R&R’s by Layer
Type & Domain
The type and domain of an organization can aaffect how the PO’s roles and responsibilities are organized.
For private entities, they likely fall into two general types; either an SPO or SSO:
- Software Product Organization (SPO) – organizations that produce software as its primary product (Amazon, Adobe, Expedia, etc.)
- Software Supported Organization (SSO) – primary product or service is something else and software is used to support the primary product or service (insurance and banking companies, grocery stores, motor companies, etc.)
Public entities usually fall into the SSO type.
For SSO’s, the PO position is not a usual position, doesn’t fit naturally within the organizational structure, and can even present a disruptive presence. Consequently, one may find several anti-patterns within SSO organizations because rarely does management fully understand and appreciate the scope, complexity, and responsibilities of the PO position. When a PO within an SSO says “jump” the general response is “why”?
For SPO’s, solving the Product Owner dilemma is fairly straight forward as the position likely grew organically, and therefore functions naturally within the organizational structure. Consequently, in SPO’s the PO role is fairly well-defined, is empowered by executives to make critical decisions and is accountable for the product’s success. When a PO within an SPO says “jump” the general response is “how high?”
If the product is small and does not grow too rapidly in size and/or complexity, then a single, “General” Product Owner can likely handle all three layers (Tactical, Strategic and Visioning) of responsibilities. The synergies and efficiencies gained with having one person empowered with the responsibility for product delivery are just too great to ignore.
But business structure and existing organizational expertise may play an influence on this structure. For instance, if a business has a very strong Product Management department (or in the case of public domain entities, with strong executive and SME control), they may desire to maintain the vision and strategy responsibilities of the product, and delegate the tactical work to a “specialized” Product Owner. While not ideal, this situation is manageable, particularly if there is close communication and clear lines of responsibilities defined. In any case, having one experienced, empowered, and properly trained PO is optimal.
PO R&R’s within Product Life Cycle
Likewise, the product life cycle can impact how an organization solves the Product Owner roles and responsibilities dilemma.
As the product matures, new market opportunities and user demands can encourage the beginning and growth of new features and capabilities. If additional development teams are formed to address unique requirements, then the ability of a single PO to serve all of these teams adequately soon comes into question. As the life cycle matures, release schedules can become more frequent and complex adding more layers of responsibility to the PO. Finally, with maturity, more and more types of users may be identified, further compounding the PO’s ability to “stay in touch” with these users well enough to properly guide the Product Vision and Road Map. Where the product lies within the product life cycle can contribute to the enterprise solution.