As unfortunate as it gets, despite all the years of practicing scrum, number of training sessions and variety of coaches leading product ownership workshops, some of the organizations seem to not be able to easily embrace this seemingly simple concept. The “Product owner” role is still misunderstood by the management, the teams, and sometimes even by the scrum masters.
The paradox is, if you ask people to describe the role itself, it would not be a problem for them. Yet, as it is often the case with any great ideas, the problems start at implementation phase. What contributes to such difficulties?
Often it is simply the “who?”. The introduction of this role makes a room sound like a parliament of owls. Who has the knowledge of the product, the market, the customer needs? Who can tell the team what needs to be done for the product to be desirable? Who can speak both business and tech language? Who-who-who…
And, the most important “who” in big organizations, who has the power to decide?
How many times I had a conversation like this one:
– But our product owner is <XYZ executive>
– But how they can be a product owner? They don’t ever see the team
– Yeah, but they make all the decisions.
– But isn’t it <Name> who prioritizes the team’s backlog, writes stories, defines acceptance criteria, etc?
– Yeah, but the <XYZ executive> is the TRUE product owner.
Problem#1: The name of the role itself
This may sound like a nonsense to some of my readers, yet I see many people getting opposed to the name of the role itself. You may be wondering what’s wrong with the name of the role? And I tend to think it’s the “owner” part. It’s like if when you ask “Who is the product owner?”, people hear “Who’s the boss here?” Not as funny when it actually happens 🙂
When this problem arises, the key is to focus the conversation not on the name of the role, but on its responsibilities. The name is just a name, and you could pick your own in your organization. After all, this same role is called the “Service Request Manager”. As long as everyone in the organization is aligned on what they should expect from people in this role – the goal is achieved.
Problem #2: The art of delegation
We often talk about reducing the number of “single points of failure” within the team when it comes to knowledge sharing. However, in less of a flat hierarchies we’re often dealing with the single points of failure above the team level. The scrum guide says that the Product Owner must be a part of the delivery team. Yet quite often people in higher hierarchical levels are forced to say “I am the product owner”.
If the understanding of the role and responsibilities is not an issue, and it doesn’t simply mean that the product is financed from “their” budget, an experienced coach would know: this person needs your help. I’ve seen more than one scenario where a manager would assume the product owner role for various reasons. Whether it is the necessity to “stay on top of things” for an important deliverable, or an attempt to “make it perfect from the first try” – it all comes down to the same root cause: the lack of trust.
However, what has to be understood is that this approach doesn’t work in a long run. The team lead by the product owner they report to most likely will not hit the highest performance bar. Simply because instead of realizing the power of the group, and look at their boss for answers and guidance, putting even more pressure at them. Should I even mention that, depending on the culture, many employees would be afraid to challenge the view of their manager and bring up their own creative ideas?
What is the better approach? Well, there are two. In some cases the old good “hire more people” approach works. If you have the budget, you could try to find an experienced product owner with an expertise in your product, target market, and has all the skills to make your team successful. However, when it comes to niche or complex products, these specialists are unicorns.
What’s the solution then? It’s to look around. Product owner role is still new to some industries, and there is no abundance of highly skilled candidates to pick from. This forces companies to pivot to cultivating the talent internally.
So “who” should be taking on the product owner role? The answer is simple: first look for competency, second – for desire. Most likely, there is already someone in the team who has some knowledge of the product, as is willing to take on the new challenge and learn the new skill.
What should the leader do to make the new PO successful?
Only 3 things:
- Motivate – the person could be inclined towards undertaking the new challenge, yet still be uncertain of things like future career path, a fear of failure – whatever it is, a leader must address these concerns and make sure that there is no mental blocker on the way of the new product owner;
- Allow focus – similarly to the mental blockers discussed above, more tangible blockers must also be removed: the leader must allow the new PO to focus on their new responsibilities and not just add these on top of their current role. Product ownership is a full time job
- Mentor – if the leader is capable of performing the role themselves, there is nothing that should stop them from teaching others. If the role is new for the leader, it is best to seek for help from an experienced coach or other PO’s within your organization.
Of course, it takes time and patience to train the team, including training the Product Owners. Just like any new skill, it has its own learning curve. Yet this is what it means to be a leader: it is to help your team to be successful and discover talents within.