To maintain quality and focus, we limit concurrent engagements and never overbook. When we work with you, our attention is fully on your needs. Whether you need a short-term boost or a long-term strategic partnership, we tailor our approach to deliver real value.
We operate on a fixed-price model, eliminating the need for time tracking or approval gates. Our engagements are based on a defined time period, ensuring full flexibility to collaborate on any topic within our expertise—technical, process-related, or strategic.
Get in touch today to discuss how we can support your organisation's agility, DevOps adoption, and value delivery.
What are the barriers that prevent developers from fully accepting a Product Owner as the final decision maker?
TL;DR; Developers may not fully accept the Product Owner as the final decision maker when stakeholders undermine the Product Owner’s authority, send mixed messages, or fail to consistently support their decisions. This leads to confusion, lack of trust, and developers second-guessing decisions. To address this, ensure stakeholders back the Product Owner publicly, document agreements, and foster open communication to build trust and accountability.
Bridging the Gap Between Developers and Product Owners 🌉
In the realm of
software development
, the relationship between developers and Product Owners is a critical one. Let’s explore why sometimes this relationship is strained and how to mend it.
Accountability: The Silent Culprit 🕵️♂️
Understanding accountability is key in dissecting the relationship between developers and Product Owners. We’ll delve into how its absence can create barriers.
Balancing ownership and decision-making is an art and a challenge. Let’s uncover the struggles that occur when the balance tips.
Inconsistent Backing
Fickle Stakeholders: Stakeholders altering their stance can be a disruptor.
Doubling Down on Distrust: This can lead to developers seeking validation from others instead of trusting the Product Owner.
Accountability and Ownership Hand in Hand 🤝
Aligning accountability with ownership is pivotal. Let’s explore how these two aspects can harmoniously coexist.
Cultivating Trust and Credibility
Open Communication:
Transparency
can prevent misunderstandings.
Consistency is Key: Regular support for the Product Owner’s decisions strengthens their position.
Navigating Through the Accountability Quagmire 🧭
The journey through accountability issues is intricate. Here, we’ll navigate through the maze and seek solutions.
Advice: How-To Bridge the Gap 🌟
Promote Accountability: Ensure stakeholders are accountable for decisions.
Uphold Product Ownership: Reinforce the Product Owner’s authority.
Encourage Open Dialogue: An open environment can mitigate undermining actions.
Examples and Recommendations 📘
Real-world examples offer insights into these barriers. Let’s explore some recommendations to overcome these challenges.
Case of Undermining
A Product Owner collaborates with a stakeholder, only for the latter to change stance in a group setting. To avoid this:
Documenting Agreements: Keeping records can prevent changes in stance.
Public Support: Voicing support for the Product Owner can solidify their authority.
Conclusion: Establishing Respect and Accountability ✅
To ensure seamless collaboration, addressing the issue of accountability is paramount.
Let’s conclude by revisiting the significance of fostering respect and open communication.
What are the barriers that prevent developers from fully accepting a product owner as the final decision maker? Wow, there’s a lot of barriers to that. I see that all the time at the moment. Other people not respecting other people who are perhaps more senior, not respecting the product owner is probably the biggest barrier, right? It’s other people coming down and saying something different to the team from the product owner or going behind the product owner’s back or agreeing with the product owner in person but then getting in a larger environment with more people and perhaps recording is on than disagreeing with them and seeing it different.
I had an experience recently where a product owner was really, really frustrated because they’d been collaborating with somebody in the organisation to get the backlog all like this is what we need, this is what we’re doing, and they’ve been collaborating with them quite heavily. They’ve had lots of private meetings with them where they collaborated and literally written the backlog items word for word like that key stakeholder, that’s the way they wanted it, and collaborated heavily on that. And then they get into the Sprint planning and the stakeholders like, “No, that’s not what I want.”
And it’s like, that is explicitly… there’s a couple of things there, right? Apart from being a bit douchey, right? That’s one piece. But because it’s then in that group team forum, it undermines the ownership of the product by the product owner, right? That totally undermines it. And if the developers, the people doing the work, see that the product owner is being undermined, well, I can’t really listen to the product owner. I still have to run it by Bob or I still need to speak to Janet or whoever it is that is doing the undermining. And as more and more of those things happen, the less the developers are able to feel that they are able to respect the product owner as the final decision maker, right?
And if you look at the Scrum guide, who needs to respect the product owner as the final decision maker? Everybody in the organisation. Everybody. Not just the people below them, but also all of the people above them. If you’re above a product owner and the product owner is consistently not making the right decisions, get rid of that product owner and get a new one. That’s your call, right? You’ve hired somebody to do a job. If you don’t think they’re doing a good job, you don’t undermine them. You get rid of them, right? And that maintains that respect of product management, that respect of product ownership, right? That the team sees that the person that’s appointed is respected by management, even if management might not necessarily 100% agree with all of the decisions that are made.
But if most of the decisions are made result in value delivered to the business, because that is the true outcome, right? What you find… yeah, I’m going to add an additional bit because what you find is that that disrespect or undermining of authority of the product owner comes from a position of maybe one key stakeholder not wanting to give all the information, not wanting to take accountability for their decision, right?
And it just results in nobody having any capability. Leadership doesn’t take the accountability, the product owner can’t take the accountability because they’re continuously undermined or the ideas are changed without their knowledge or understanding, and the developers… there’s no credibility in that story. So then if I were to come back to the question and answer it in one word, what are the barriers? There’s only one. What is the barrier that prevents developers from fully accepting a product owner as the final decision maker? And it’s accountability. Or in three words, a lot.
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.
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
Schedule a Teams Call with Martin Hinshelwood
Our Happy Clients
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.
