I was working with a client recently at a product team review, walking through the things they had produced. When one stakeholder pushed back on a priority for the next sprint, the team didn't discuss it — they just nodded, went back to their desks, and rebuilt their plan around what the stakeholder had said.
No discussion. No "here's why we sequenced it this way." No pushback of their own based on their ground truth.
Initially, this looks like a team that's responsive to feedback. It isn't. It's a team that has outsourced ownership of their own product to whoever spoke last in the room.
Here's the belief that has to shift before any of the rest of this works: a product owner doesn't serve stakeholders, customers, and the market — a product owner leads them. Not in the sense of authority over people who don't report to them. In the sense that leadership always means: someone has to synthesize competing inputs into a coherent direction, and then take responsibility for that direction. Stakeholders bring perspective. Customers bring signal. The market brings constraints. None of them are positioned to do the synthesis — that's the product owner's job, and it's a leadership act every time they do it.
The pattern
This organization came from a strongly command-and-control background — clear hierarchies, highly regulated industry, clear direction-giving, clear expectations that when someone senior spoke, you executed. Culture like this doesn't disappear just because a team adopts Scrum events and calls its lead a "Product Owner." The org chart changes faster than the reflexes — and the title doesn't mean much until the person holding it actually starts leading the product.
So what I saw, over and over, was product teams treating stakeholders as directors — people whose input was, functionally, an instruction — rather than as advisors, people whose input was one signal among several the team was responsible for weighing.
The distinction sounds subtle. It isn't. It's the difference between a team that owns its outcomes and a team that's just executing the most recent thing it was told.
Why this matters more than it looks like it does
A team that treats stakeholders as directors will always, eventually, build the wrong thing — not because the stakeholders are wrong, but because no single stakeholder has the full picture the team does. Stakeholders bring context, constraints, and priorities. They don't bring the synthesis. That's the team's job. When the team stops doing that synthesis and just relays instructions forward, you don't have a product team anymore — you have a very expensive order-taking system.
It also quietly kills the thing organizations say they want most from Agile: ownership. You cannot have a team that owns its outcomes and also treats every stakeholder comment as marching orders. Those two things are incompatible. Ownership requires the team to sometimes say "we heard you, and here's why we're doing something different" — and a command-and-control culture trains people out of ever saying that sentence.
What Could The Team Try?
The fix wasn't a framework. It was a handful of specific, repeatable practices — each one designed to move the team from receiving instructions to evaluating input.
- Design an alliance with each stakeholder individually — then quietly surface the inconsistencies. Rather than treating "the stakeholders" as one aligned voice, we sat down with each stakeholder separately to understand what they actually needed and why. Almost without exception, this surfaced real inconsistencies — Stakeholder A wanted speed, Stakeholder B wanted certainty, and both had described their ask as non-negotiable. Bringing those inconsistencies back to the room, gently and without blame, did something a command-and-control culture rarely allows: it made it visible that "just do what the stakeholder says" was never actually a coherent instruction. There wasn't one voice to obey. There were several, and someone had to reconcile them. That someone was the team.
- Get radically clear on the why and the thinking model behind the problem you're solving — this is product strategy. A team that can articulate the underlying problem, and the frame they're using to think about it, has something to push back with. A team that only knows the feature it's been asked to build has nothing to offer except compliance. Much of the coaching here was less about stakeholder conversations directly and more about making sure the team could say, clearly and confidently, "here's the outcome we're solving for, and here's the model we're using to evaluate tradeoffs" — before they ever walked into the room.
- Use the rule of three in reviews to get people evaluating options, not just reacting to one. When a team shows up to a stakeholder review with a single proposed direction, the stakeholder's only real choice is yes or no — which quietly reinforces the direction-giving dynamic. Showing up instead with three genuine options, each with real tradeoffs, forces a different kind of conversation. Stakeholders start evaluating and reasoning alongside the team, rather than approving or overriding from above. It's a small structural change with an outsized effect on the room's dynamic.
- Watch for the moment an idea gets prioritized because of who said it rather than its merits. This is the tell. In a command-and-control culture, the loudest signal in the room is often seniority, not logic — and teams learn to read that signal fast. Part of the coaching was simply naming it in the moment: "I want to check — are we prioritizing this because of the reasoning behind it, or because of who raised it?" Asked with genuine curiosity rather than confrontation, this question does a lot of work. It doesn't accuse anyone of anything. It just makes the team's own decision criteria visible to itself.
None of this was comfortable. Asking a team steeped in hierarchy to evaluate ideas on merit rather than seniority is asking them to risk something. Coaching that shift means holding space for that discomfort rather than smoothing it over.
The through-line
This is, I think, the real difference between coaching Agile practices and coaching product leadership. Practices can be taught in a workshop. Leadership — the willingness to synthesize competing voices into a direction and own the outcome — has to be built, relationship by relationship, decision by decision, in a culture that may be actively working against it. The framework was never the hard part. Teaching people to lead the very stakeholders they'd been trained to obey was.
I coach product organizations and product owners on exactly this kind of shift — from executing direction to owning outcomes. If this resonates with something you're navigating, I'd love to hear about it.