Skip to main content

14 Stances of Highly Effective Product Owners

July 12, 2017

Symphony Conductor

 

INSPIRATION

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

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 in his blog and presentations on The New New Product Owner

MISCONCEPTIONS

Here are some common misconceptions that I have seen about Effective & Professional Scrum Product Ownership...

PO As Chief Story Typist...?

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

PO As Chief Whiplash Officer...?

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

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

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

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

STANCE #8 - CHIEF RISK/REWARD BALANCER

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 #9 - CHIEF EXPERIMENT SEQUENCER

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 #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 FOCUSSER

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 #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 it's 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 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 #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.

IN SUMMARY

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

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

WHAT NEXT...?

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!


What did you think about this post?

Comments (7)


Ravi Verma
03:14 pm July 13, 2017

Thanks for the kind words Iwan. I agree that it is important to amplify that Product Owner is accountable for delivery of value from the Scrum Team.


Tim Ingram
04:55 pm July 24, 2017

Depends on your organization. In mine, there are also product managers. Those are the fall-guys. As a PO, I am more internal focused and the PMs are external.


JW Washington
08:27 pm October 18, 2017

Thanks!
Excellent analogies; short, descriptive, and concise. As a Scrum Master, I can use this to bring focus to the PO I am currently working with, but also as tool for myself if I should have any future aspirations as a PO.


Ravi Verma
05:34 pm September 9, 2020

Thanks JW! Hope it helped.


Aref Maleki
09:20 pm December 27, 2020

Thanks a lot for such wonderful summary!
I have a question around "Only the Development Team can change its Sprint Backlog during a Sprint"!

This is true in theory but doesn't work easily in the real world as devepores are hired by company and the moment the product lead (product manager) says we have deadline or we must to take in a ticket to the Sprint for some reasons what should the developers do? Even the POs of the of the teams has no power to say no!
Devs cannot just simply reject their manager's request. (you may say the dev needs at least to discuss it with the PO or the product manager to maybe compromise some other tickets). And imagine this happens often let's say for 5-6 months as the company has to meet some deadlines! And still company is forcing using the Scrum while the team already complained about the situation indicating that this is not the Scrum (they are right)!

One the thing that is missing in Agile / Scrum concept is the role and power of managers is not considered! They expect employees to be self-organised while they have not changed their mindset or due to the business status they always have to force the teams to do more / change the sprint backlog / ....

Maybe Scrum is not needed for such a circumstances?


Alec ROY
01:52 pm May 17, 2021

An Agile team and a Scrum Team is an empowered one. If the word of someone outside the Team has more value than the ones inside the team, welcome in a non-Agile world. This is a pre-requisite for the team to succeed : empower them. You can't do Scrum without being Lean and Agile, and you can't be Lean and Agile without letting the teams do.

If the PO is the Product Owner. He.she owns it. Period. Even the CEO shouldn't have his.her word to say in the decisions. He.she has the ability to convince the PO to change, but no more than everyone else.

In your situation, if the existing team has a deadline, the thing that can vary is scope (https://en.wikipedia.org/wi....

I am afraid you're not using Scrum, you're using Scrum's roles, events and artifacts, but your company is missing the theory and the values (the heart of Scrum).

As a Scrum Master or Agilist, I encourage you to help your company grow in that way :) force on you.


Aref Maleki
08:47 pm July 18, 2021

Thanks Alec