Relationships of a good Product Owner – part #3

Why good relations inside and outside of a product organisation are key to the success of a Product Owner.

In my first and second blog post on this topic I explained about the five key relationships of a Product Owner and studied them on four archetypal Product Owners Tom, Carl, Peter and Wendy.

The system

This final blog post on the matter I will show you more about the system, the Product Owner lives and acts in. The Product Owner exchanges with these major other roles:

• His Development Teams
• Higher Management
• Scrum Master
• His Stakeholders, Customers Users

The goal

Imagine being an Agile Coach in this system and eager to make the Product Owner successful with all his strengths and weaknesses. What would you focus on, what are details to look at, what is to avoid, what is to try?

And finally, how does that relate to the archetypal Product Owners of my recent blog post?

A matter of trust

Good relationships start with trusting each other. Lets start with two variables representing this:

Suppose we have two variables representing the level of trust one party has for the other. The relations are pretty clear: over time, there is a mutual benefit from each other. The more I trust you, the more you will trust me. But it takes time, this is not love at first sight.

As you can also see, this is a reinforcing loop (over time).

Archetypal manifestations

Lets put in some variables that are supposedly strong with the archetypal Product Owners I described in my previous blog post.

Tom, the techie, is probably interested in a good technical architecture and design of the product. Carl, and probably Peter too, do have a sense of urgency in controlling everything and everyone. Wendy does not have any specialities, that come to my mind immediately. Lets see for the result:

The variable sustainability of architecture and design is on that Tom is specifically interested in (though any Product Owner would like to get a sustainable architecture and design!). Now, Tom will gain a lot of trust in his Teams if he sees that the architectural design is good – and vice versa.

Carl and Peter will probably focus on urge to control and strength of control exercised, I expect it more towards the delivery. Wendy will not control much, Tom maybe more the architectural aspects of the development.

The more you feel the need to control, the more you will do it. This is important to know, because on the other side, if the PO trusts his Teams he will not feel the need to control and thus does it less. On the bad side of it, the more Teams are actually controlled the less trust they have in the “controller”, aka the Product Owner. And, unfortunately, this is also a reinforcing “negative” loop.

Another means of “control” is the variable #predicted and done items, representing the Teams’ ability to deliver what they promised. Now, every Product Owner wants that. And if this number is high then a Product Owner is truly happy and he will trust his Teams even more. Also this relation takes time, a high number for one Sprint does not save the Product Owner’s world forever. But this is also a very strong relationship, because if both the Teams and their Product Owner work on that number they truly respect each other and it means also that the Product Owner has done his work during refinement well, ie. explaining the why and what to the Teams.

Common Product Backlog

A central object to work on for both the Teams and their Product Owner is the Product Backlog. A lot of the collaboration work between both sides is done over it. That’s why variables like accuracy of backlog ordered according to highest customer value, % items PO accepts on target system are worth adding to the system model. What adds to it because of its high dependency to the other two is the variable degree of CI practices performed. All three add to the system model like this:

The above mentioned dependency is actually a reinforcing loop between the degree of CI practices performed and % items PO accepts on target system. The more the Teams use CI practices, the more a Product Owner is able to view implemented features on its target system – and that’s what we are aiming for in Scrum. But the CI practices also influence the Teams’ promises of done items because the underlying automatisms of CI allow the Teams to concentrate on real implementation work.

Both the acceptance rate on target system and the prioritization of backlog items according to highest customer value influence positively the trust, Teams have in their Product Owner. This is what Teams actually expect from their Product Owner!

LeSS Adoption Goals

In a LeSS adoption there are two major goals:

• Always work on features with the highest customer value
• Flexibility of the whole organisation to shift at product level

We want to reflect that with two final variables, % items of highest customer value teams deliver each sprint and ability of teams to shift at product level. These variables integrate well in our system model:

If Teams are good at delivering what they promised then of course they are able to shift direction at product level easily. No work in progress means you are always open for new directions. Given that you will also be able to work on the items with the highest customer value. In addition, over time, the accuracy of your backlog ordering according to highest customer value (a true Product Owner’s task) will support that.

Back to …

It is now time to get back to Tom, Carl, Peter and Wendy. How does this system model relate to their performance, the good and bad habits they have? How will the Scrum Master in their organisation act upon this?

In a way, it does not matter, if it’s Tom, Carl, Peter or Wendy. The things to do as a good Product Owner are the same for all of them. But you could avoid things or try focus on other things more:

Tom, the techie

• avoid focussing on … sustainability of architecture and design
• try working on … % items PO accepts on target system
• try working on … accuracy of backlog ordered according to highest customer value

Tom’s focus must shift from pure technical issues towards real Product Backlog work. This will enlarge his domain knowledge and in the end gain the trust from the Teams he believes he already has because of his technical expertise.

Carl, the control freak

• avoid focussing on … urge to control
• try working on … % items PO accepts on target system
• try working on … accuracy of backlog ordered according to highest customer value

Carl must get away from the deadly loop of “more control leads to less trust”. Instead learn to do proper Product Backlog work and thus gaining the trust from the Teams.

Peter, the patriarch

• avoid focussing on … strength of control exercised
• try working on … % items PO accepts on target system

Although it is my belief only that Peter should avoid exercising control it is still valid for him to accept backlog items on the target system. Why? Because doing that he must be with the Teams, regularly. This will increase their trust in him.

Wendy, the waiter

• avoid focussing on … believing in a high level of trust Teams have in their PO
• try working on … % items PO accepts on target system
• try working on … accuracy of backlog ordered according to highest customer value

Wendy believes too much in the trust the Teams give her. Sooner or later she will not have their trust anymore. As with Tom, Carl and Peter she should focus on doing the Product Owner’s work properly. With Wendy it might take a bit longer since she is new to the domain and the role but eventually she learned all that is required and the trust comes back.

Back to …

In this system model it becomes clear that the two variable % items PO accepts on target system and accuracy of backlog ordered according to highest customer value are key variables. Thus if a Product Owner will focus on accepting backlog items on the target system, in fact forcing the Teams to prepare that, will gain him trust, and also he will gain trust in the Teams. And if the Product Owner always orders his Product Backlog according to the highest customer value, the same effect will appear.

A Scrum Master coaching Tom, Carl, Peter or Wendy in their job should help them to work on these two important issues and avoid the above mentioned activities. This will certainly lead to a better Product Owner.