The role of the Scrum Product Owner is probably the most misunderstood of the three Scrum Roles. As I look back at the different incarnations and interpretations I have seen of Product Ownership, I thought it was time to articulate the different stances I thought an effective and professional Scrum Product Owner might consider.

Inspiration

Besides my industry experience, my ideas were influenced by three Agile Thought Leaders.

Barry Overeem has done an amazing job in his viral blog on The 8 Stances of a Scrum Master.

Gunther Verheyen first helped me with epiphanies around Product Ownership through his PSPO workshop as well as through his powerful blog – Product Owner Role Summary.

Finally, Charles Bradley did a wonderful job on his blog and presentations on The New New Product Owner.

Misconceptions

Here are some common misconceptions that I have seen about effective and professional Scrum Product Ownership. 

In many teams, the Scrum Product Owner is perceived to be the sole person who types in user stories. This can often create a bottleneck and us vs. them mindset where members of the (Scrum) Development Team refuse to work on backlog items unless there are “ready” user stories. The Scrum Guide clarifies the Role of the PO by stating in the context of Product Backlog Management that “the Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.”

PO as Chief Story Typist?

In some companies, I have noticed the Product Owner play the role of an enforcer, whipping the Development Team into submission. This person challenges estimates, sets “stretch goals,” instructs the Development Team on what they will do in the upcoming Sprint, demands that there be steady increases in velocity and demands that people be “Team Players” and put in nights and weekends and do whatever it takes to meet their “Sprint commitments” (not forecast).

The Scrum Guide clearly states:

• The Role of Development Team: “They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn the Product Backlog into Increments of potentially releasable functionality.”
• Estimation of Product Backlog Items: “The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.”
• Sprint Planning: “The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.”
• The Sprint Backlog:
  • “The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment."
  • “Only the Development Team can change its Sprint Backlog during a Sprint.”

PO as Chief Whiplash Officer?

Perhaps one of the most damaging misconceptions about the role of the Product Owner is that they throw a bunch of user stories across the wall at the development team and then disappear to do more meaningful work, which is usually externally faced. This is a way of being which is more compatible with the Waterfall mindset, where the business unit would throw a requirements doc over the wall at the software delivery organization and then re-appear only towards the end of the project to try out the product.

Prequel

This blog builds on the foundation established in my previous blog – Sleepless in CXO Land: How Smart CXO’s Beat Stress With Strategic Scrum. If you haven’t read that blog, you may get more out of this one if you do so before moving on.

Now that we have identified some common misconceptions about Product Ownership and established a foundation for Strategic Scrum, let’s start exploring some possible stances of professional and effective Product Owners.

Stance #1 – Chief Inspiration Officer

Scrum teams work best when they are passionate and inspired. Unfortunately, sometimes, the development team feels disconnected from the impact of the work they are doing. They are unable to see the consequences the increment is having on the lives of their users. This can create disengaged or demotivated order-takers who may be doing what they are told, no more, no less.

An effective Product Owner must be able to inspire the development team towards a greater purpose that aligns with their personal purpose. I am not sure if inspiration can be taught or learned in a workshop or through a certification exam. The Product Owner must themselves be truly inspired by their Product and radiate a contagious passion and energy every waking moment.

Stance #2 – Chief Strategic Enabler

The Product Owner must create and communicate a compelling strategy that helps deliver on the product vision. This strategy must be easy to understand and believable and the Product Owner must behave in a way that enables the implementation of the Strategy.

Stance #3 – Chief Dot Connector

Sometimes, teams can lose sight of how their day-to-day actions or decisions tie-in to the Strategy. An Effective and Professional Product Owner reminds Development Teams how their work and items in the Product Backlog and Sprint Backlog enable the execution of the Product Strategy, which in turn helps realize the company mission and vision.

Stance #4 – Chief Portfolio Collaborator

There will be times when a large company has a suite of products that together may offer more to their customers than they might have individually. In such cases, the company may have a Portfolio of Funds that get allocated to enhance multiple products. When these funds are being allocated, a common anti-pattern is each Product Owner optimizing for their product, silo or “kingdom” which could sub-optimize for the larger organization.

An Effective and Professional Product Owner would optimize for the overall system and be a constructive collaborator with colleagues when engaging in Portfolio Management Conversations.

Stance #5 – Chief Hypothesis Proposer

No matter how smart the Product Owner might be, at the end of the day, the only source of truth in Complex Software Delivery is the market. Even the smartest person in the company may not be able to consistently guarantee exactly how the market will respond to the product. An effective and professional Product Owner must acknowledge this inherent uncertainty in Complex Software Delivery. The Product Owner must demonstrate humility by framing Backlog Items as hypotheses that must be tested by deploying to market.

Stance #6 – Chief Scoreboard Designer

Testing hypotheses through frequent and regular product deployment to production requires that the Scrum Team empirically measure the market response. An effective and professional Product Owner can enable empiricism by designing and continuously improving simple scoreboards that create transparency into what success would look like.

Stance #7 – Chief Flow Navigator 

Most companies face complex business problems and have complex solution architecture. This makes it extremely challenging for Scrum Teams to frequently and regularly deliver product increments that are both thin and valuable. An effective and professional Product Owner must navigate the overwhelming complexity of business processes and solution architecture by planning releases that take incremental steps from the current state to the desired state.

Stance #8 – Chief Risk/Reward Balancer

Managing the backlog is not trivial – it requires some very complex calisthenics that includes maximizing reward in the form of business value, controlling uncertainty and risk, and being a judicious steward of company time and money. An effective Product Owner must be good at the tight-rope walk of balancing risk and reward and resist the temptation to exclusively focus on some attributes of Backlog Items while excluding others.

Stance #9 – Chief Experiment Sequencer

Once the Product Owner has figured out how to compare and contrast Backlog Items based on risk and reward, they must now apply this approach to sequence experiments in the form of rank-ordered Product Backlog items that test their hypotheses. This will influence the Sprint Goals and the Sprint Backlog selected by the development team.

Stance #10 – Chief Clarifying Officer

Once the team starts sprinting, the primary stance of an effective Product Owner would be to offer clarifications and context that might help the development team make informed decisions. The Product Owner’s clarifications should give the development team a decision making framework that enables them to make decisions. This can help prevent an unhealthy dependence between the development team and the Product Owner, freeing up more of the Product Owner’s energies for more strategic challenges.

Stance #11- Chief Laser Beam Focuser

A common anti-pattern in Scrum is Product Owners or other stakeholders injecting change into the Sprint Backlog mid-Sprint. There is always a bright, shiny object and a flavor of the day that many people would love to change. Most people who believe that they are practicing Scrum are unaware or unwilling to follow the Scrum rule that clearly states, “Only the development team can change its Sprint Backlog during a Sprint.” One of my clients – CIO Michael Dunn – suggested that an effective Product Owner must protect the development team from distractions so they can focus on the Sprint Goal with the intensity of a laser beam.

Stance #12 – Chief Tea-Leaf Reader

As the market responds to product increments deployed to production, the verdict is rarely crystal clear. The scoreboard might have conflicting indicators that could be interpreted in many different, often contradictory ways. At this point, an Effective Product Owner must be able to read the tea-leaves and figure out exactly what the market is indicating with its response.

Stance #13 – Chief Learning Officer

As the Product Owner reviews the scoreboard and “reads the tea-leaves” to figure out what the market might be indicating with its response, they must take the stance of a teacher and guide that enables the entire organization to gain validated learning and insights.

Stance #14 – Chief Value Optimizer 

Last but not the least, the most important stance of an effective Product Owner is the CVO – Chief Value Optimizer. The Scrum Guide says, “The Product Owner is responsible for maximizing the value of the product and the work of the development team. How this is done may vary widely across organizations, Scrum Teams, and individuals.” This might feel like a symphony conductor, guiding and inspiring the complex work of many talented and inspired professionals in service of a greater goal.

...

Let me know if any of these stances help the Product Owners in your organization to be more effective.

Until our next conversation, Keep Calm and Scrum On!