In my journey through the world of Agile and Scrum, I’ve encountered a recurring challenge: what to do when the Product Owner is ineffective or, dare I say, incompetent. It’s a strong word, but I’ve met many Product Owners who fit this description, either because they lack the necessary skills or because their organisation doesn’t empower them to fulfil their role effectively. The outcomes are often the same: a team struggling to deliver value and a product that misses the mark.
Understanding the Problem
Before we dive into solutions, let’s clarify what we mean by an ineffective Product Owner. This can manifest in two primary ways:
- Incompetence: The Product Owner simply doesn’t have the skills or knowledge required for the role.
- Lack of Empowerment: The Product Owner may know what to do but feels constrained by organisational structures or policies.
Regardless of the cause, the Scrum Master and the team must step up to address the situation. Here’s how we can navigate this tricky landscape.
Steps to Support an Ineffective Product Owner
Engage as a Scrum Master: If you’re a Scrum Master, it’s your responsibility to support the Product Owner. This might mean facilitating conversations with stakeholders or helping the Product Owner understand their role better. If your team lacks a Scrum Master, appoint someone who is willing to take on this responsibility. They don’t need special skills—just a good understanding of the organisation and a willingness to build relationships.
Build Relationships: Start networking within your organisation. Who are the key players in leadership, HR, or other departments? Take them out for coffee or lunch. Building these relationships can create back channels that help the Product Owner gain the support they need.
Practice Politics: Yes, I said it—politics. Navigating organisational dynamics is a crucial skill for a Scrum Master. Engage in conversations that matter, and demonstrate your understanding of the product and the market. This can lead to invitations to important discussions where you can add value.
Educate the Organisation: If the Product Owner is truly incompetent, it may be time to educate the organisation about the role of the Product Owner versus the team. Help stakeholders understand the responsibilities and expectations of each role. This can shine a light on the issues and potentially lead to changes.
Encourage Open Dialogue: If you feel comfortable, have a candid conversation with the Product Owner. Approach the topic delicately, as this can be a sensitive issue. Gauge the situation and decide if this is the right path for you and your team.
Focus on Team Excellence: Ultimately, the team should strive to deliver the best product possible, regardless of the Product Owner’s effectiveness. If you’re consistently delivering high-quality work but the product is still not right, it’s essential to highlight that the issue lies with the Product Owner, not the team.
It’s worth noting that many people are promoted to their level of incompetence. They excel in their roles, get promoted, and eventually find themselves in positions where they struggle. This is a systemic issue within many organisations. We need to advocate for a culture that allows individuals to step back to roles where they can excel rather than forcing them to stay in positions that don’t suit their skills.
Conclusion
Navigating the challenges of an ineffective Product Owner requires a blend of support, education, and strategic relationship-building. As Scrum Masters and team members, we have a role to play in fostering an environment where Product Owners can thrive. By focusing on collaboration and communication, we can help our teams deliver the right products and ultimately drive organisational success.
If you found this discussion helpful, I encourage you to engage with me further. Whether you want to chat about Agile, Scrum, or DevOps, feel free to book a coffee with me through Naked Agility. Let’s continue the conversation!
So the question is what are the steps that the team can follow if the product owner is incompetent? Um, that’s pretty strong, right? Incompetence is pretty strong, but I have met a ton of product owners that would perhaps fit into that category or the other adjacent category, which is I don’t know what I’m supposed to do or my organisation doesn’t allow me to do the things I’m supposed to do. Right? So it’s not it manifests the same way; the outcomes are the same and ineffective product owner. Um, but the reason could be incompetence or I’m not allowed, right, within the bounds of the org or I don’t feel I’m allowed. Um, in both of those circumstances, I would probably suggest that there’s some um onus on the Scrum Master to figure out how to deal with that, right? It might not, might not be ideally the product owner is the person with the money who can resolve those problems, but often they’re not. So what can you as a Scrum Master do? Um, with the support of the whole team, right? Perhaps with the support of the whole team, perhaps with the support of the person who is the product owner to engage with the business, to engage with the organisation and the way the organisation is structured in order to enable a greater degree of product ownership, right? That’s part of the Scrum Master services to the product owner.
Um, if you don’t have a Scrum Master on your team, just pick somebody in your team who has an interest in dealing with some of those things and they can be the Scrum Master, right? They don’t need any special skills. Um, they just need to be a bit battle-hardened in working within your organisation, which if you’ve been working there a while, you probably are. And start going building those relationships, right? Who do you need to speak to, take out for dinner, buy a beer for in leadership, in HR, in the organisation to start building those relationships for them to start seeing your point? Build in those back channels.
Um, there’s, there’s, uh, what was that movie with the nuclear explosion? Um, uh, in the baseball game? Uh, Clear and Present Danger? No, it was the other one. Um, anyway, that movie which you probably remember better than I do. Uh, uh, the channels were how things got done, right, between the Americans and the Russians. There were people, uh, that are low in the organisation who are in either organisation who were able to have conversations to trade information, to find out things that are going on. That’s one of the skills of a Scrum Master: politic, right? It’s politics.
Uh, being able to practice um, um, politic, getting into um, the conversations that you need to get into. And in order to get into those conversations, you have to demonstrate an understanding of the topic. You have to make small suggestions around the side, perhaps an email with one person who then maybe invites you to some of those conversations because you’ve demonstrated your knowledge and your capability. Um, and then, you know, you don’t want to say anything unless you actually can add value. Add value where you can, build up your knowledge and experience in that space and encourage change. And that’s how everything gets done in organisations, right? Especially when there are lots of people that don’t understand how to do that.
So if you have an ineffective product owner, um, that’s the best route. If you have an incompetent product owner who really just shouldn’t be in that position at all, they are not, uh, the right person. The old adage is kind of true: people are promoted to their level of incompetence, right? Um, people are good at their job, so they get promoted to the next level up. Um, and then in the next level up, they’re also good at their job, so they get promoted to the next level up, and they get to a level where they’re no longer good at their job, and that’s where they stay.
Um, when in reality, organisations should offer that capability to drop back down, right? To, to, you might have the seniority, but I, I don’t want to do this job up here; I want to do this job here or this job even further down in the organisation. I really respect some of the things I, I meet people at Microsoft who’ve been a software engineer, a real coder, um, for 20, 30 years, um, inside of the organisation. And they take on more responsibility and accountability by um, mentoring other people, helping with other stuff, but not actually managing people, um, which often is not a skill that lots of people have, right? Just like taking any, anybody with skills with people and making them a programmer is probably not a good idea. The converse is also true.
Um, so maybe that product owner is just not meant to be in that position, and there’s very little that you as a team can do. Um, there’s certainly with the politic around the side, you could maybe let people become aware of the problem. Um, but you need to really skirt that moral and ethical area of um, should you be going behind this person’s back? Perhaps you go speak to that product owner and say, uh, say, say something in the first instance, although that might get you, you’ve got to gauge that situation yourself.
Um, but all the team can do ultimately is be the best team they can, um, deliver working usable product, be that competence at that level. And if we’re not building the right thing, that’s not the team’s fault; that’s the product owner’s fault. And hopefully at some point, the organisation sees that we’re continuously building awesome product, but it’s the wrong product. Um, and then they see that light of it’s the product owner that’s the problem, not the team. Um, and perhaps the Scrum Master can help educate with that, right? Rather than going behind the product owner’s back, just explain to the business what a product owner’s job is, what the team’s job is, what their roles and responsibilities are, and hopefully they’ll be able to see what the problem is.
Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else Agile, Scrum, or DevOps, then please book a coffee with me through Naked Agility.
