The “Kid in a Candy Store” Product Owner and the “See Saw” Product Owner
This is the second of two articles that address the specific challenges you may be facing in your work with Product Owners. The first article focused on two very different types of Product Owners: The “Big Picture Thinker” and the “Aspiring Developer”. In this article, the focus is on two types of Product Owners that appear to be different on the surface but who create surprisingly similar challenges for the Agile team: The “Kid in a Candy Store” Product Owner and the “See Saw” Product Owner.
The “Kid in a Candy Store” Product Owner wants every requirement on their list to be treated as a critical priority. In their minds, there is no distinction between those features that deliver the highest business value for the organization and those that are nice to have. Everything is a must have. Even more importantly, there is no incentive for “Kid in a Candy Store” Product Owners to make that distinction. Their reluctance (or their inability) to provide the team with clear priorities could be due to several factors, most notably, their fear of being responsible for making incorrect decisions.
The “See Saw” Product Owner appears to be able to make decisions on priority requirements at first but will not stick to the decisions that they have made. These are the Product Owners who will give you a list of wholeheartedly endorsed critical priority requirements one week and then waver on (or completely negate) their selection the following week. Their inability to provide the team with decisive priorities could be due to several factors but fear of making the wrong decision is the most likely reason for their behavior.
Although their methods may vary, the primary driver behind both of these challenging Product Owner types is essentially the same: Waterfall thinking. Historically, business users have been given “one bite at the apple” to identify everything they need in a solution. This thinking makes the “Kid in a Candy Store” Product Owner want to load in everything up front before the window of opportunity closes. It also makes the “See Saw” Product Owner second guess their original decisions to minimize the potential of something critical being left out when the solution is released.
The most effective technique that you can use to overcome the “now or never” prioritization mindset of these Product Owners is to reinforce Agile thinking. Assure each Product Owner that priority setting in an Agile environment is an emergent process and that there will be ongoing opportunities for them to review built features and to adjust their priorities as needed throughout the process. Emphasize that, with Agile methods, the Product Owner controls the definition of “done” and determines when features are approved for release. Not only does explaining Agile methods combat the “once chance to get it right” mindset of these Product Owners, it switches the focus of the discussion from selecting high value features to clarifying requirements. It also encourages an environment of collaboration and trust instead of rules and rigidity.
Another effective technique for overcoming the “now or never” mindset is to use the identification of Minimum Viable Product (MVP) as the basis for establishing the minimum set of functionality that is required to be in the solution before it is released. This assures the Product Owner that all of their essential features will be included, regardless of the order that each feature is delivered. Leveraging MVP frees the Agile team to prioritize their backlog by more important criteria, such as the features that require the most upfront investigation and experimentation, the ones that are the highest risk, or the ones that require the longest lead time.
A third technique is to remove “Priority” language from the discussion with these Product Owners. Replace emotive terms like “critical priority” and “low priority” by using numerical top-down ordering instead of priorities, or by using “planning poker” for business value assignment with the caveat that this approach requires multiple Product Owners and subject matter experts to work together on the estimations. If the Product Owner still insists on using priorities, try asking for relative priorities like “more critical” and “most critical” to get a top down order in the backlog without minimizing the importance of each requirement.
Approaches like these not only remove the pressure of the Product Owner making language-based priority judgment calls, (e.g. what should be “critical” versus “high”), they also serve to maintain the value of the stories at the bottom of the backlog instead of calling them “low priority” features.
One final technique is to conduct either of the following role playing scenarios:
- The “Top Five” scenario where executive management will only allocate an initial budget for building five stories. They want to see a demonstration of the five stories fully built and fully tested to determine if additional funding should be allocated. Ask the Product Owner which five stories would they choose and why? Put their selected stories at the top of the backlog and then repeat the exercise with the remaining stories, putting the newly selected stories directly beneath the previous ones. This scenario forces critical thinking, decision-making, justification of selected stories, and removes the challenge of trying to order the entire backlog. Answering the “why” question can also elicit key details and insights into each story selected (and not selected).
- The “Bottom 10%” scenario where executive management cuts the product budget by 10%. The Product Owner needs to remove 10% of the stories from the backlog. Which stories would they choose to cut and why? Put the cut stories at the bottom of the backlog and then repeat the exercise with the remaining stories, putting the newly cut stories on top of the previous ones. This approach minimizes the severity of the decision by taking the focus off of the highest priority stories as well as providing the “why” question for key details into each story removed and the ones that remain.
If your team can help these challenging Product Owners unlearn their Waterfall thinking, it will pave the way for a much more collaborative and productive environment for achieving your shared goals.
