If your team is moving slowly because every decision has to travel up the chain of command and back down before anyone can act, you may be experiencing one of the most common and costly scrum anti-patterns: product owner in name only.
This anti-pattern doesn't mean you're doing something wrong. It usually means your organization hasn't fully invested in your role. But the result is the same regardless of cause: delayed value, delayed feedback, and a team that can't be truly responsive or agile.
The good news is that there are concrete steps you can take to move from permission-seeker to empowered decision-maker.
What does a product owner without authority look like?
A product owner without authority holds the position but lacks the permission to make final product and priority decisions on their own. Instead of guiding the team directly, they function as a relay: gathering requests from stakeholders, passing them down to the team, and escalating decisions back up whenever something doesn't fit neatly into prior approvals.
This isn't a personal failure. Organizations often create this situation unintentionally through hierarchies that weren't redesigned when scrum was adopted, stakeholders who haven't let go of day-to-day control, or a culture that expects decisions to be validated at multiple levels before anyone acts on them.
The difference between authority and empowerment
It's also worth distinguishing two things that often get conflated. Authority is what the organization grants you. Empowerment is what happens when that authority meets the confidence and capability to use it. A product owner can build trust, demonstrate competence, and position themselves to lead, but they can't fully empower themselves. The organization has to meet them halfway.
How organizations unintentionally undermine product owner authority
Before looking at solutions, it helps to understand why product owners end up in this position. A few patterns show up repeatedly:
Stakeholders were not educated on what product owners need to be successful in scrum teams
Most organizations that adopt scrum don't restructure how stakeholder relationships work. Stakeholders are often experienced, well-meaning people accustomed to directing work. They may hold the product owner responsibility in high regard without understanding that it works best when it comes with real authority. Without that insight, they continue operating as they always have, not out of malice, but because no one told them that doing so undermines the system they're trying to adopt.
There are no agreed-upon rules for how stakeholders communicate with the team
In many organizations, stakeholders are accustomed to going directly to team members — telling them what to build, when, and in what order. When those informal channels aren't replaced with a clearer structure, the product owner gets bypassed. The backlog becomes a dumping ground for competing priorities, and the product owner spends more time managing noise than making decisions.
There's no shared understanding of what the team is actually responsible for
When a team's purpose isn't clearly defined and visible to all stakeholders, requests arrive from every direction. Without that clarity, the product owner has no defensible basis for saying no or for redirecting requests to the right team. When team purpose is clear to everyone, conversations about priority become much more straightforward.
The cost of delay to your team
The impact shows up in two ways: value and feedback.
Feedback delays. When stakeholder input has to pass through multiple layers of hierarchy before it reaches the team, or before the team can act on it, the feedback loop stretches. Scrum's core premise is that short, frequent cycles of delivery and learning drive better outcomes.
Value delays. Every day a product decision sits waiting for approval is a day customers don't receive the value your team is capable of delivering. In fast-moving markets, those delays compound. What should be a quick adjustment to priority becomes a multi-week bottleneck.
The ripple effects are real: sprint goals that drift, teams that stop trusting their own direction, and stakeholders who grow more skeptical of scrum because they don't see the responsiveness they were promised.
How to gain authority as a product owner
Changing the preconceived notions of scrum in an organization takes time. When it comes to gaining authority as a product owner, it requires building trust with your organization, demonstrating competence incrementally, and working alongside your scrum master to reshape how decisions get made. Here's where to start.
Streamline the path between you and the people who can say no
The most direct way to reduce decision latency is to shorten the chain. The goal isn't to bypass stakeholders. It's to get as close as possible to a single point of contact with authority, rather than routing decisions through multiple layers of approval.
This often means having honest conversations about responsibilities, decision rights, and communication with the team. Your scrum master can be an important ally here, helping facilitate those conversations without putting the product owner in an exposed position.
That said, not every conversation needs to flow through you. When a team member needs clarity on context or intent, connecting them directly with the right stakeholder is often more effective and avoids the risk of something getting lost in translation. What does need to come back to you is any insight that could affect what gets built. The goal isn't to be in every room. It's to stay accountable for what the team builds and why.
Build credibility through smaller experiments
If you're operating in an environment where your judgment isn't yet trusted, don't fight for big decisions. Instead, identify smaller increments of work that you can move on without needing permission, and then deliver on them well.
This is also where a well-built team becomes a multiplier. Teams with broad, overlapping skill sets, where members have depth in one area but can flex into others, can execute on small decisions quickly without waiting for a specialist to weigh in. When the team can move with confidence on their own, it reduces the number of decisions that need to be escalated in the first place. Consistent delivery on small experiments builds organizational trust, which eventually translates into greater autonomy on larger ones. Show the work. Make the wins visible.
Use evidence to make the cost of delay impossible to ignore
This is one of the most powerful tools available to both product owners and scrum masters. For every decision that has to go up the chain of command and back down before the team can act, there is a measurable cost: time lost, value not delivered, opportunities missed.
Quantifying that cost, even roughly, shifts a conversation about authority to one about business outcomes. Stakeholders who are reluctant to let go of control often respond differently when the delay is framed in terms of delivery impact rather than process preferences.
Evidence-based techniques also help ground your product decisions in facts rather than assumptions. User research, market data, and team performance metrics all strengthen your position as someone making informed decisions—not guesses.
Educate your organization on what an empowered product owner actually enables
Many organizations adopt scrum without fully understanding what it requires of their leadership structure. Stakeholders who are used to approving every decision aren't acting in bad faith. They're operating from a model that made sense in a different context.
As a product owner, part of your responsibilities include helping your organization understand what changes when a product owner is truly empowered: faster decisions, shorter feedback loops, more responsive teams, and better outcomes for customers. Your scrum master should be a partner in this education effort, helping leadership see the systemic value of distributed decision-making.
A word on the reality of control culture
It’s worth naming something that courses and frameworks don’t mention. In some organizations, advocating for product owner empowerment can be risky. Challenging the control culture may put you in direct tension with people who have a stake in maintaining their oversight. That’s a real constraint, and it deserves honest acknowledgement.
If you're in that situation, the approach is still the same, but the pace is different. Focus on what you can impact. Build trust through delivery. Find allies, starting with your scrum master. Document the cost of delays where you can.
The goal: An empowered product owner who enables an agile team
When a product owner has the authority to make decisions, maintain the product backlog with purpose, and facilitate real communication between developers and stakeholders, the team can do what scrum promises: deliver value early and often, respond to change, and improve continuously.
Authority isn't handed to you on day one. It's built through trust, demonstrated through results, and protected by an organization that understands why it matters.
If you want to go deeper into product ownership, the Certified Scrum Product Owner® (CSPO®) certification provides product owners with the foundation and community to gain that authority with confidence.