The Product Owner Journey, Part 2: Mitigation Strategies

In The Product Owner Journey, Part 1, we addressed the challenges faced by the product owner and how these are manifested within an organization that is going through an agile transformation. So how do we mitigate these challenges? What are the strategies that will enable you to remove these obstacles to true agility? In this post, we offer up some perspectives that may help you do just that.

Mitigation Strategy #1: Realistic, Bite-Sized Tasks

In our last post, we discussed the need to assess when and how the product owner is engaged with the team. By determining how much time someone can realistically provide to the effort and then assigning specific tasks that are manageable, you can engage a time-stressed product owner initially on activities where they can see the value of their participation. While this is a mitigation strategy, it still entails considerable risk. However if you can get to this point, you are in a better position to negotiate for more time and energy from that product owner later on.

Mitigation Strategy #2: Shifting to Oversight

An alternative option is for the product owner to depend heavily on one or two analysts or test engineers on the team to do a lot of the heavy lifting or time intensive work of developing the back log, acceptance criteria, and informal approval of completed stories. The product owner then just resolves conflicting requirement decisions, provides strategic direction, and provides cursory formal oversight. In a simple business setting with good people the risk may be manageable for a while but if the people are really part of the delivery team this is paramount to letting the team decide what to build.  The risk is the solution may lack coherency, they may not incorporate sufficient stakeholder input and build the wrong thing. They may build a camel when what was needed is race horse.

Mitigation Strategy #3: Establish a Proxy Product Owner

Another mitigation strategy involves establishing a proxy product owner. Such an individual develops a thorough understanding of the business to enable him/her to perform the proxy product owner role. They take high level direction and gain the trust of the actual product owner who doesn't have the cycles to perform as product owner.  This person performs nearly all of the product owner responsibilities and works closely with the development team and other business people.  A proxy holds no real authority other than what “referent power” they can gain from the “real product owner.”  It takes a very skilled and politically astute individual to operate in this role effectively.  A proxy product owner is often just a temporary position held for a year or two but, in some cases, he/she may evolve into a permanent position as the business knowledge acquired is a hard-to-replace asset. 

The future is bright but challenges still exist.

Months or years down the road on our agile journey assume we now have a person in the product owner role with all the right skills. HR has a job description with the words “product owner” in the title. On the organization’s career web site there are jobs with the title “product owner” posted.  Yet, there are still challenges. Some may say the product owner role is an invention of technical people and developers who want clean, simple answers. In a large organization the network of stakeholders is broad and diverse. The VP of engineering, the director of operations, the security officer, etc. and the actual end customer of the organization each have diverse concerns and priorities. There is often a high degree of inherent complexity in the perspectives and needs of these stakeholders. Beyond that the political climate is often a difficult factor with each stakeholder holding varying levels of power and influence.

The developers and scrum masters often lament about the lack of or failings of the product owner they have. Because of the “protection of the team” offered by the scrum master and the facade provided by the product owner they sometimes fail to appreciate the complexity of the product owner's world.

A good product owner recognizes that he/she is a focal point in a network of decision makers and stakeholders. The PO needs to establish the information feeds and gain the trust of the other decision makers in the organization so that the decisions they make are respected. He/she has the humility and wisdom to understand the decisions they make are not theirs alone but rather a synthesis and integration of multiple points of view. But, on the other side, it’s just as important to have an understanding of the technology and build rapport with the development team so that they can identify and recognize opportunities to create and deliver value.

I offer up an analogy: Once while gardening in my backyard I noticed three sunflower plants growing that I did not plant. I was weeding and almost pulled them out but then reconsidered. I thought, “It would be fun to see a few sunflowers grow in that spot.”  A good product owner is not just a requirements integrator but also listens to the team and understands the potential of the technology.

Opportunities arise from identification of the possibilities to create value from the tools and technology used to create the solution. Working at the nexus of need and opportunity is where an effective product owner thrives. They look at both sides, have the courage to make decisions and offer the vision that inspires the team to create great things. And that is certainly a journey worth taking.