Product Owner: Team Protector
About a 5-minute read
Featured Image: Shutterstock - lassedesignen
For all the bluster around self-organization and independence in selecting the best path forward to reach a stated goal, Agile teams are incredibly fragile, fickle things. They require rigorous maintenance and the persistent building of executable runway to maintain their throughput. Because of this effort, it is unsurprising that Agile fails to achieve the responsiveness and empowerment at the core of its purpose, which leads to wariness around Agile practices or abandonment back to traditional project management. Frustration around Agile is valid — as a mindset, Agile paints a beautiful picture of what could be, but in practice, there are challenges translating the mindset to executable actions. Missteps can compound quickly and leave teams and organizations in a worse position than they started. I believe, however, that the consistent investment of effort in building and refining Agile practices, opposed to a “set and forget” approach, is of paramount importance in fostering a successful Agile environment. One of the most vital components for creating Agile success is strong product ownership.
Per Scrum.org, the product owner is accountable for effective product backlog management, which ties into the Scrum Guide description of being accountable for maximizing the value of the product resulting from the work of the scrum team. Removing Scrum from the description and broadly thinking about their role in Agile practices, product owners are the gatekeepers for the requests and work impacting their product. The product owner builds a roadmap (or collaborates in building one) to set the direction of a product, and then the product backlog is prioritized to align with the roadmap and direct the work to achieve the product’s goals. This arrangement is clearly communicated to any teams supporting the product so they may tackle the work in priority order. As work is completed, the product owner may be adjusting priority based upon learnings, team input, or evolving organizational directives. This is very simple and straightforward, right? Well, yes, obviously, but any organization is unlikely to keep things so neat and tidy. Disruption should always be an expected constant. Priorities can shift suddenly. Personnel and their knowledge and talents come and go. The work itself often ends up being more complex than represented on paper or in planning. Unexpected demands from leadership or other teams pit the innate desire to accommodate against curated timelines. Pick your nuisance, they exist and always will, but they are not insurmountable.
Product Owners cannot individually reshape an organization, but their actions can protect teams to keep product work progressing in the appropriate direction. This is done by utilizing the word “no” or the phrases “not now” and “let’s talk about it”. For example, perhaps John Q. Stakeholder comes to the team and states, “We should include this new feature being used at this other company I read about and I’d like functionality ‘x’ with this next deliverable.” There are several routes the conversation can go. The product owner can look at the product roadmap and backlog to see if the requested feature and functionality is already in the pipeline. If it is, the response can be a “not yet”, and perhaps the product owner has the ability to forecast when those pieces may be picked up by the team. If the requests are absent from the backlog, the product owner needs to give a firm “no” and examine if the stakeholder’s requests will ever be appropriate for the product. Either way, this latter scenario requires further conversation to confirm the initial “no” or see if future inclusion is possible. If the organization’s intake process is undefined, the stakeholder’s requests may be best handled by another team or are already on a backlog — that opens another doorway to chaos that we will quietly walk past for now. The takeaway from this example is that by simply being willing to utilize “no” and “not now”, the product owner immediately protects the team and the product’s goals. The product owner must keep in mind it is their responsibility to guide the product and maximize its value, not the stakeholders’.
“Wait,” you say. “It will never be that straightforward, and there are other factors to consider!” You are absolutely correct. Organizational culture, requestor authority, and technical complexities are just a few of the variables that make project work and product ownership challenging. When a product and Agile structure are newly adopted, I have seen organizations struggle or fail to properly empower their product owners with the necessary authority to make their products successful. Requests and expectations flow through legacy hierarchy and relationships. In other instances, product owners are not formalized roles but rather a responsibility of an existing role. These situations leave product owners beholden to managerial oversight and organizational politics that view products as vehicles for getting things done rather than true value delivery. Compounding this, when much is asked of products, little is then done to ensure products have the resources and structure to actually achieve their mandates, leaving them to be pulled into the morass of competing with the rest of the organization for time, technical know-how, and clarity. Again, product owners cannot single-handedly fix these issues but must continue communicating these challenges and acting as the lightning rod protecting the product team’s focus and direction. While a tall task, these individual contributions contribute to building the organization’s project, product, and Agile maturity.