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 (DA) tool kit.

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 (sometimes mistakenly called backlog grooming or backlog refinement)
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
Manages requirements dependencies with other teams, negotiating and reprioritizing as appropriate

When representing the agile team to the stakeholder community, the product owner:

Is the public face of the team to stakeholders
Demos the solution to key stakeholders who weren’t able to attend the regular 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:

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 team representative to the overall stakeholder community as a whole.
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.
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.
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.
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.

Figure 1. The role of Product Owner (click to enlarge).

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 (click to enlarge).

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?

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. 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.

The Product Owner Role: A Stakeholder Proxy for Agile Teams

Product Owners at Scale

Where Do Product Owners Come From?

Recommended Reading