Making better decisions as Product Owner
So, you’re a Product Owner? congratulations! perhaps you recognise what I refer to as “the reverse Spiderman syndrome”. Where Peter Parker’s motto is: “with great power comes great responsibility” has the Product Owner one a slightly different ring to it:
“With great responsibility comes absolutely no power” — The Product Samurai
So how does that work? Well, according to the Scrum Guide: “For the Product Owner to succeed, the entire organization must respect his or her decisions.” In practice this is not easy, since not many organisations realise how paramount this is. Lets explore some ideas on how you can improve your decision making.
Goleman’s six styles
Commanding style
Freshly minted Product Owners often find themselves utilising this style. “This is the backlog, this is where we are heading”. Very quickly they are met by resistance (or reality) and often resulting in disappointment and frustration.
If you tell people what to do, then at best that is exactly what they will do. The might do what you say, but at the first sign of problems or surprises they will push back to you. A nice early warning indicator of this behavior is a “Definition Of Ready.” In itself not an unusefull practice, but now it has turned into a contract or stage gate and the team will not start working before all requirements have been met.
So should you never use this style? Well, when my 4 year old daughter stepped in front of a car while crossing the road I did not “ask the team what they thought about possible outcomes” but screamed and acted as any parent would. There are those situations at work too, but far less than one may think.
Visionary style
“Follow me, my friends to new and unbegotten lands and great riches.” Visionary Product Owners see the world before others see it. The feel the pain of the people that are not yet customers and can make people share that dream.
Sometimes the visionary Product Owners are so far ahead that there is no connection between the vision and the day to day operations of creating a valuable increment. This can be easily spotted by the interaction between the Product Owner and the Development Team during Sprint Planning. Or even better: Product Owner and Support Desk.
Product Ownership is about bridging tomorrows ideas to where the rubber meets the road. You can’t just own part of that journey.
Affiliative style
The opposite of the commanding style is a Product Owner that makes sure that every single one is on-board. They like to talk, they like to listen and they are great relation builders. This ability makes sure that people actually want to follow them. People generally trust this Product Owner because they know they are heard.
You can recognize this Product Owner by phrases like: “We need to make sure we are all on-board? What do you think about this? Is there a middle ground? Did we forget someone for this decision? Did we get everyone’s input?”
The drawback of this style is that it may take a long time to get everyone aligned, but once they are things may move more quickly.
Democratic
If you don’t want to get everyone on the same page, simply because you don’t have the time, you may opt for the “let’s vote on it” solution. It’s fast and has the advantage that at least 51% agrees with the choice. It may work if all people have a similar level of insight in the vision and consequences for that choice.
“There is one good, knowledge, and one evil, ignorance. Education is the best hope for a democracy”
— Socrates
Its the system that brought you Donald Trump and Brexit, and ultimately killed Socrates, so he might be biased. As a Product Owner, use it with care unless you know that those who vote truly understand the consequences.
Pace Setting
There are times where you want to empower the team, times you want to take the lead and just do it, and there are situations in the middle. This is where you set the pace, control a bit more that you would like too, but with the goal of self organisation in mind.
These Product Owners take Development Team members along on customer visits, work together on analysis, bridge business to the team but are still mindful that they don’t monopolise them, share their ideas and fears so that the understands.
This and the next style, ultimately this may hold the key to scaling development.
Coaching
Coaching is my favourite style so I am biased but there is a lot to say for this way of interacting. It allows the team to come up with more solutions and allows the Product Owner to challenge them.
“Coaching is unlocking a person’s potential to maximise their own performance. It is helping them to learn rather than teaching them.”
— John Whitmore
Coaching doesn’t work when the team members are defiant and unwilling to change or learn, or if the Product Owner lacks proficiency…..
What is your favourite style? and which one do you struggle with? how can you get sharper and more flexible? or who can help you to fill that gap? Let me know in the comments, or clap if you liked the story and want to see more like it.
