Product owners are accountable for maximising the value of the product. Common tasks are developing clear product goals and managing initiatives. These initiatives are made visible through a product backlog which contains a list of items that are ordered in a way to best accomplish the current goal. Items start out pretty high-level and are afterwards split or 'refined' into smaller, more actionable tasks for developers to work on.
Building a valuable product is discovering what job needs to be done. A product owner discovers this by spending quite some time talking with customers, stakeholders and sale teams (who indirectly sense what customers struggle with). He or she will also talk with developers to include non-tangible features such as performance, scalability, security, etc. You could say that half the job is developing goals and initiatives through a backlog while the other half is building the situational awareness needed to do this.
Spotting the proxy product owner
The main symptom is seen when ownership doesn't go beyond the title. Organisations inexperienced with Scrum tend to put someone in charge of refining product backlog items and ordering them. Talking is limited to busy business manager who make the real impactful decisions.
To illustrate, an enduring performance issue means pulling out a charm offensive to persuade these same managers for approval to act. I've also witnessed impactless decisions such as typography take weeks because the wrong people needed to approve this. Or features start to solely resolve around business insights and policy while the actual users end up in the background.
It's inevitable that these symptoms start to hurt. Focus seems impossible or technical debt reaches a critical point. Maybe the team feels demoralised as impact seems outside their control. In the end, everything goes a bit slower and neither the business managers nor the Scrum Team feels satisfied with the results.
Break the spiral with trust
Often these business managers, let's call them stakeholders, are unaware of what happened until it's too late. They explain how their organisation differs and that this is the only way to make agile work. Sometimes they even get frustrated and disregard agile altogether. Luckily, these drastic measures are not needed as the root cause is almost always the same: a lack of trust and a misunderstanding of the stakeholder role.
In Patrick Lencioni's leadership fable The Five Dysfunctions of a Team we discover how trust allows us to engage in productive conflict which in turn leads to commitment, accountability and results. With enough trust stakeholders are confident that the product owner sets a product goal that aligns with business goals. With enough trust we are willing to bet that initiatives can be properly executed. But in return we can leverage autonomy together with deep situational awareness to make better decisions faster.
Ready, Set, Action!
As a Scrum Master, it's your responsibility to remove barriers between stakeholders and the Scrum Team. As always, you start coaching by recognising where they are so you can meet them half a step ahead. It's futile to begin with an elaborate explanation of a perfect way of working (does this even exist?). Instead briefly sketch that the idea is to work on building trust to gradually move ownership to the product owner, then follow up with a small change to create momentum.
Coach the product owner to become autonomous. It's a skill to determine the right amount of proactive behaviour, transparency and knowing when to reach out for advise or feedback. Secondly, teach to transform situational awareness into powerful questions that will bring insights to stakeholders. These type of questions confirm that you understand what the product is actually about. It might even show gaps in their thinking. In both cases it will become easier for stakeholders to let go of control. Only then will you want to start bringing up your own initiatives.
Coach the stakeholders to learn to trust and over time to act as a coach. Besides trusting the product owner to do the right thing, the distance from the product allows them to keep a strategic overview. Tell them to guide product owners by pointing out flaws in their thinking to which they are blindsided by being too close. Lyssa Adkins also gives some great tips such as being present and attentive in sprint reviews, talking about business trade-offs, managing expectations and holding the team accountable.
Finally make sure that the product owner is talking with the right people. Stakeholders can help by introducing the product owner, but he should not depend on this and build a strong network himself. As ownership grows week-over-week, you will start to realise that this was the key to a product that is both delightful and profitable.
