Skip to main content

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.


Besides my industry experience, the 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

Barry Overeem - 8 Stances of a Scrum Master

Barry Overeem – 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

Gunther Verheyen - Product Owner Role Summary

Gunther Verheyen – Product Owner Role Summary

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

Charles Bradley - The New New Product Owner

Charles Bradley – The New New Product Owner



Here are some common misconceptions that I have seen about Effective & 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 a 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

  • Role of Development Team: “They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn 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 mis-conceptions 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 mind-set, where Business 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.

PO as Chief Disappearing Officer…?


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.

Prequel - My Blog on Strategic Scrum

Prequel – My Blog on Strategic Scrum

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 & Effective Product Owners.


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 herself be truly inspired by their Product and radiate a contagious passion and energy every waking moment.

PO as Chief Inspiration Officer


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.

PO as Chief Strategy Enabler

Stance # 2 – PO as Chief Strategy Enabler


Sometimes, teams can loose 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 & Vision.

PO as Chief Dot Connector

Stance # 3 – PO as Chief Dot Connector


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.

PO as Chief Portfolio Collaborator

Stance # 4 – PO as Chief Portfolio Collaborator


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 # - PO As Chief Hypothesis Proposer

Stance # 5  – PO As Chief Hypothesis Proposer


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 # 6  – PO As Chief Scoreboard Designer


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 Process and Solution Architecture by planning releases that take incremental steps from current state to desired state.

Stance # 5 - PO As Chief Flow Navigator

Stance # 7 – PO As Chief Flow Navigator


Managing the backlog is not trivial – it requires some very complex calisthenics that include 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 # 7 - PO As Chief Risk/Reward Balancer

Stance # 8 – PO As Chief Risk/Reward Balancer


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

Stance # 9 - PO As Chief Experiment Sequencer

Stance # 9 – PO As Chief Experiment Sequencer


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 #10 - Chief Clarifying Officer

Stance #10 – Chief Clarifying Officer


A common anti-pattern in Scrum is Product Owner 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 #11 - Chief Laser Beam Focusser

Stance #11 – Chief Laser Beam Focusser


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 it’s response.

Stance #12 - Chief Tea Leaf Reader

Stance #12 – Chief Tea Leaf Reader


As the Product Owner reviews the Scoreboard and “reads the tea-leaves” to figure out what the Market might be indicating with it’s response, she must take the stance of a teacher and guide that enable the entire organization to gain validated learning and insights.

Stance #13 - Chief Learning Officer

Stance #13 – Chief Learning Officer


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.

Stance #14 - Chief Optimizing Officer

Stance #14 – Chief Optimizing Officer


So here is a summary of the 14 Stances of Highly Effective Product Owners and how they relate to the 10 elements of the Strategic Scrum framework introduced in my previous blog – Sleepless in CXO Land- How Smart CXO’s Beat Stress With Strategic Scrum

At A Glance - 14 Stances Of Highly Effective Product Owners

At A Glance – 14 Stances Of Highly Effective Product Owners

You can also review the slides that summarize this blog on SlideShare.


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

Until our next conversation, Keep Calm & Scrum On!