The Product Owner (PO) role in organizations that are scaling up Agile projects requires not only nuances how the role is applied but also requires refocusing the typical activities in the role (however this does not mean that they don’t they get out of buying pizza or other relevant food occasional). The primary responsibilities of a scaled product owner are:
1. Prioritization of the backlog: The backlog is the bailiwick of the product owner. Whether the Agile effort is scaled or not, managing and prioritizing the product backlog is the most important activity that the product owner performs. The backlog defines what gets done and when it gets done. The difference in scaled efforts is one of complexity. The product owner of a scaled effort typically needs to balance the needs and wants of a wider range of stakeholders (scale usually is equated to size of the effort, the number of teams and the number of involved stakeholders – larger means more).
2. Facilitation of interactions between the team and subject matter experts (SME): Team members and SMEs outside team often need to talk and interact in order to flesh out user stories or to validate what is being built. Getting the attention of the right SMEs is not always easy. Often SMEs are really busy people, don’t speak software development or don’t know the Agile effort actually exists, therefore, can’t be accessed without help from the PO. The product owner, as the link to the business, needs to help make those connections. When the team needs access to resources they don’t have, the PO is often called on to ensure the team(s) gets the resources needed to deliver. In scaled efforts, this role is often done in collaboration with a program manager, release train engineer (SAFe) or scrum master, depending on the size and scope of need. The PO leverages his or her political connections and capital to make things happen. In scaled efforts, the product owner will generally need to have (or have access to) more political power to ensure the effort has access to the resources and SMEs they need. The PO, due to their stature, often has more clout in the business than scrum master or program manager, who are both perceived as not being part of the business team.
3. Clarification of needs and requirements: The scaled product owner continues to provide clarification of needs based on their business acumen. The problem is often that in a large effort it is rare that a single person can have all of business acumen needed; therefore a scaled product owner needs to actively create situations where collaboration with the team, other business stakeholders and potentially other product owners happens effectively. Clarification of needs through collaboration requires that the product owner provide broad leadership across the entire scaled effort, rather than with a single team.
4. Connections between team(s) and SMEs: Arguably acting as a connector might be considered as a special form of facilitation. However, drawing the distinction between action as a connector and as an intermediary is important. Many POs act as intermediaries between business SMEs and the team(s). The PO collects and distributes information, insulating the SMEs from the team (and vice versa). The issue is that intermediaries often add their own perspective to the data they transport, and potentially filter the information they share. Connectors, find a way to ensure that development personnel and SMEs talk and interact with each other in the most intimate process possible. We have discussed the impact of intermediaries in communication; all communication is a network, even if it is as simple as between two people.
The idea of a PO acting as the single decision maker at all levels of an effort tends to fall apart at scale. The primary product owner still acts as a point of prioritization, but when deciding on whether a button on a screen needs to be one or two centimeters to the left or right often needs to be made by people acting in the PO’s proxy. SAFe tackles this hierarchy issue by layering product management into the hierarchy of decision makers. Other practices leverage a hierarchy of product owners much akin the to the hierarchy of rings in Tolkien’s Lord of The Rings trilogy. The goal in all cases is to create a decision tree with decisions being made at the level of the effort that makes the most sense. Because a single product owner can’t be a the single conduit of decisions and knowledge as the size of the effort and number of the teams increases, the role of the product owner shifts from the single decision maker to a connector and facilitator.