The Product Owner Role: A Stakeholder Proxy for Agile Teams

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:

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 delivery 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
Agile Excellence for Product Managers

Where Do Product Owners Come From?

The goods news is that there are several viable options for where Product Owners may come from:
  • Business analyst. Although a traditional business analyst could fill the role of product owner, there is a risk that they will fall into their old habits of communicating via documentation. Keep in mind that what agile teams really need are people with agile analysis skills who are empowered to make decisions. So, a better option is an empowered agile business analyst.
  • Business stakeholder. When business stakeholders are trained to be POs they are often very knowledgeable about the part(s) of the business where they have worked. However, they are often week on their new PO skills (understandably slow), potentially weak on parts of the business where they haven't worked, and often weak on the non-business aspects of your organization (including operations, support, audit, the existing infrastructure, and so on).
  • IT stakeholder. IT stakeholders have similar challenges to business stakeholders when in the role of PO. They are often strong in IT although weak in other aspects of your organization.
  • Product manager. Organizations producing software solutions for the marketplace, will often have established product management groups. Scott Ambler + Associates has worked with several companies in this exact situation and we've found that this option can work very well. The key challenges always seems to be freeing up the product manager to spend sufficient time with the development teams when in the role of PO, and for them to provide the details required by the teams.
  • New hire. This is hard to make work in practice. Although you MAY be able to hire someone with solid PO skills, they won't have the contacts that they require to do the job well. It can take many years to do this. However, if your organization is small this is a viable option.

My experience is that the best product owners are empowered stakeholders (from either the IT or business side) who have been educated, trained, and mentored in the role of product ownership. Having said that, it is often very difficult to find such people who are willing to fill the role of PO.

The role of PO is very hard to fill. Even when provided good training, which doesn't happen as often as it should, it will still be a struggle. If you're interested in good PO training, I suggest that you consider this 2-day Product Owner Workshop.