The Product Owner Role: A Stakeholder Proxy for Agile Teams

Recently reviewed The primary goal of a product owner is to represent the needs and desires of the stakeholder community to an agile delivery team, being the first source of information about the problem domain for the team. Each agile team, or in the case of large programmes an agile subteam, has a single product owner to go to for information and prioritization of their work and they do so right away. A secondary goal for a product owner is to represent the work of the agile team to the stakeholder community. In traditional terms, a product owner is in many ways an empowered business analyst without the burden of the bureaucracy surrounding big requirements up front (BRUF).

The role of product owner was introduced to the agile community by Scrum, although the onsite customer practice of Extreme Programming (XP) is very similar. This role has been adopted by the Disciplined Agile Delivery (DAD) process framework.

As a stakeholder proxy, the product owner:

  • Is the "go to" person for domain information
  • Provides timely information and decisions
  • Prioritizes requirements, defects, and other work items for the team
  • Is an active participant in modeling
  • Is an active participant in customer testing
  • Helps the team gain access to expert stakeholders
  • Facilitates requirements modeling sessions, including requirements envisioning
  • Educates team in the business domain
  • Is the gateway to funding
When representing the agile team to the stakeholder community, the product owner:

  • Is the public face of team to project stakeholders
  • Demos the solution to key stakeholders who weren't able to attend the normal iteration demo
  • Announces releases
  • Communicates team status
  • Organizes milestone reviews
  • Facilitates requirements modeling sessions
  • Educates stakeholders in the development process
  • Negotiates priorities, scope, funding, and schedule
There are several aspects about this role which I think are critical to understand:
  1. Product owners bridge the communication between the team and their stakeholders. As Figure 1 shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.
  2. Product owners are empowered. The product owner is the single person whom is responsible for prioritizing requirements and for providing the details explaining the requirements to the team. At scale this becomes a bit more complex, as you'll see below.
  3. Product owners facilitate communication. Product owners need good communication skills, including agile modeling skills. They also need to know who the stakeholders are, interact with them regularly, and when needed facilitate the interaction which the team has with them. Although it's convenient for deliver teams to think of product owners as the "one neck to wring" because it puts the burden of requirements responsibility on them, the reality is that the product owner can't possibly know all the details known by the true range of stakeholders at all points in time and as a result will need to bring stakeholder experts to the team to share their expertise with the team at appropriate times. The implication is that the product owner isn't always the direct source of requirements.
  4. Product owners prefer direct means of communication. There is significant evidence that the worst way to communicate information between people is via documentation, and that the most effective way is face-to-face around a shared sketching environment. Agilists in general prefer to avoid interim documentation and instead use more effective means for agile communication.
  5. Product owners need many business analysis skills. They need to be skilled in techniques to identify stakeholder needs, negotiate priorities between repeating stakeholder factions, and then collaborate with developers to ensure that the requirements are implemented effectively. This is business analysis 101 stuff.
Agile Product Management With Scrum

Figure 1. The role of Product Owner.

Product Owners at Scale

Figure 2 depicts a typical organization structure for a large agile team. The subteams will be organized either around the architecture of the system (a component team approach), around the requirements (a feature team approach), an internal open source strategy, or combinations there of. Regardless, each of the subteams will need to have access to a product owner (although any given product owner could work with more than one subteam). The product owners will be part of the product owner team, lead by a chief product owner. This product owner team will:

  • Manage the requirements for the overall program
  • Negotiate functional dependencies between requirements being implemented by different subteam, potentially reprioritizing requirements to reflect those dependencies
  • Manage consistency of the requirements between subteams
  • Assign requirements between subteams in a consistent and sensible manner

Figure 2. Organization structure of a large agile team.

To do these things the product owner team will need to coordinate regularly. There are several strategies to do so:

  • Have their own daily coordination meeting
  • Have a regular, perhaps weekly, meeting to discuss any requirements issues between subteams
  • Adopt electronic requirements management tools
  • Combinations of the above

Where Do Product Owners Come From?

Although a traditional business analyst could fill the role of product owner, particularly those from the business side of your organization, there is a risk that they will fall into their old habits of communicating via documentation. If they can overcome these tendencies and instead focus on collaboration, knowledge transfer, and skills transfer then becoming a product owner on an agile team is clearly a viable strategy for existing analysts. Otherwise the best product owners are empowered stakeholders who have been educated, trained, and mentored in the role of product ownership. Sadly, my experience is that many product owners aren't given adequate training in their role. Agile Excellence for Product Managers