The product owner plays a pivotal role in an Agile project. That role is more complex as Agile projects are scaled and applied to new scenarios. Exploring three classic project types that most software organizations have, is a useful approach to exposing the potential nuances in the role of the scaled product owner (PO).
- Sourced Project Development – Organizations often hire third parties to do work that exceeds an organization’s capacity or capabilities. Historically processes and techniques were developed to ensure compliance including contracts, process and product quality assurance, reviews, and acceptance testing. The outsourced development process in this environment is a black box. The outsourcer does their thing and then throws the result over the wall to the organization that requested the work. When Agile is being used as the development framework, the PO should be from the company receiving the work product. This means embedding a product owner from another company into the development team. While embedding a product owner from the business makes perfect sense when using Agile techniques, it is often resisted due to the fear of transparency between organizations. In order to overcome resistance, embedding a PO from the business organization into the sourcing organization must be negotiated as part of the contract or other more classic techniques will need to be leveraged to enforce interaction and compliance. Typical PO capabilities such as being business focused, a connector and a decision maker apply to this form of a project along with contractual acumen. The PO needs to be well briefed on contractual and legal stipulations or limitations based on the contractual relationship and the ability to navigate the contract. My observation of this type arrangement is that the embedded PO acts as a catalyst to at least partially synchronize the goals of the two organizations. The synchronization process is more akin to a form of mediation (intervention in a process to build a common goal), which is a capability that is rarely needed on different types of projects.
- External Product Development. Product development scenarios are often more complex than standard internal projects (all things being equal) with stakeholders including product management, marketing, customer support, manufacturing and legal. This is on top of other IT and OPS groups. The larger pool of stakeholders increases the overall level of complexity that a product owner must interact with and represent. This type of complexity requires that the PO pay even more attention to ensuring a balance between the needs of each constituency. The product owner must be highly aware of the network of connections between stakeholder groups in order to foster interaction between stakeholders and the team(s).
- Internal Development. In most organizations, software development, maintenance and enhancements are focused on facilitating the delivery of the organization’s products and services rather than forming the core of the products or services. For example, developing and supporting functionality for an organization’s payroll or human resource systems are fairly typical roles for internal IT organizations to perform. In these scenarios, the PO will generally come from an internal department. Without external stakeholders, the communication channels that need to be managed tend to be shorter. One of the critical factors scaling generates is the number of interfacing applications. As the number of teams and the number of interfacing applications increases, the larger the network of influence that the product owner must have in order to connect the team with other teams and business units within the company. Product owners in this scenario need less polish than a PO that interfaces with customers, but will need just as much acumen to navigate internal politics in order to connect the team(s) with internal stakeholders that can and often do have different tactical goals.
The product owner role is difficult regardless of the type of work. Whether internal software development or outsourced development, each requires a nuanced approach to the product owner role. Understanding the nuances is critical for a selecting the best product owner for any piece of work.