7 min read
Our Product Owner Can't Make Decisions. What Is Going On?
A Product Owner with no authority is usually a Product Owner Proxy: a Business Analyst or an IT-side lead. What it costs, and why not to smooth it over.
If your Product Owner cannot make decisions, you most likely have a Product Owner Proxy: someone with the title, but not the authority to order the Product Backlog or say no. It usually takes one of two forms, a Business Analyst or a lead from the IT side. Do not smooth it over. Scrum is built to make an organization’s dysfunctions visible, and this is one of the clearest it shows you.
The short version:
- A proxy has the title but not the authority, so every real decision goes to someone else.
- It comes in two forms: the Business Analyst and the IT-side lead.
- The cost is the wait, and it can be counted in dollars.
- A proxy is never the answer. Use it to surface the real problem.
- Business Analysts still belong on the team, as Developers.
I’m Michael Vizdos, a Certified Scrum Trainer® (CST) since 2006, one of the first 25 in the world. My Certified ScrumMaster license is #72, one of the first 75 ever issued (my Scrum Alliance profile). I see this pattern at many clients. It is the third check on my list in We Do the Scrum Events, but Delivery Hasn’t Improved. What Should Leadership Do?
What is a Product Owner Proxy?
The Product Owner is the one person accountable for maximizing the value of the product. A proxy has the role on paper and none of the accountability in practice. Decisions about the roadmap and priorities come from someone else, and the proxy passes them along.
The Scrum Guide is direct about the standard:
“The Product Owner is one person, not a committee.”
“For Product Owners to succeed, the entire organization must respect their decisions.”
A proxy meets neither one. The decisions are made elsewhere, and the team waits for them.
What does the Business Analyst version look like?
This person has zero authority over the product roadmap and priorities, because those are handed to them by someone else. Three more signs:
- They are not close to the customer. Ask them: “When was the last time you sat with the customer and listened, really listened, to their problems?” If the answer is a long time ago, the backlog is built on second-hand opinions.
- They write Business Requirements Documents (BRDs) that are not grounded in real customer problems. The document gets written, the team builds to it, and nobody checks it against the customer.
- They do not treat “Done” as shippable product at the end of the Sprint. To them Done is a handed-off document or a finished step, not a usable Increment. See the Definition of Done.
None of this makes the Business Analyst a bad hire. They are doing what the system asked of them.
What does the IT-side version look like?
It is similar, with one extra problem. This person comes from the technology group and knows the systems extremely well. That knowledge makes it easy to cherry-pick the most fun feature or solution instead of the one the customer needs to solve their problem.
The team builds exactly what was specified, and it can be well built and on time. It still does not solve what the customer actually has. A Product Owner is supposed to be knowledgeable about the customer’s problems, and an IT lead who knows the system is not the same thing.
What does it look like in a real team?
A client asked me to look at a team that ran every Scrum event and still was not getting anywhere. Their Product Owner was a Business Analyst, and a good one at writing things down.
At Sprint Planning the team would ask which of two items came first, and the answer was “let me check.” A couple of days later the answer came back from a director who had never been in the room. By then the team had guessed and started on something.
The requirements arrived as a Business Requirements Document. I asked the Business Analyst when they had last sat with a customer and listened to their problems. There was a long pause.
At the Sprint Review, the director saw the work for the first time and redirected it. That is the proxy pattern in one Sprint: the person in the room could not decide, the person who could decide was not in the room, and the team paid for the gap. (The client is anonymous, and I have left out anything that could identify them.)
It took a few Sprints. The director made the call to get the actual person from the business side to commit to becoming the Product Owner full time. That took negotiation, and some tough conversations among the director-level people about pulling that person off “real work” to sit with the team. Once it happened, the team was able to Focus. #deliver more effectively by the end of each Sprint.
This is a hard thing to do. If you are not the director, please do not make a career-limiting move to force it. Make the cost visible, bring it to the people who can decide, and let them make the call.
What does it cost?
In my podcast episode on an absent Product Owner, I put a number on it. A typical team of 6 to 8 people can represent roughly $80,000 for one two-week Sprint.
Here is the worked example from that episode. Say the team spent two full days of the last Sprint blocked, waiting for someone to approve something or clarify a feature. Two days times eight people is 16 person-days of lost productivity. Against an $80,000 Sprint, that is roughly $10,000 lost on one issue, or 10 to 15% of the investment every Sprint. (It is an illustration with round numbers. Use your own team’s.)
A proxy creates that wait every time a decision has to go back to the real decision-maker. Show leaders the number. It moves the conversation from “you are not following Scrum” to “this is your investment, and here is what the indirection costs it.” The full write-up is in Your Product Owner Is MIA? It’s Costing More Than You Think.
Is a Product Owner Proxy ever okay?
No. Full stop.
It is tempting to treat the proxy as a workable compromise, a relay between the team and the person who really decides. I do not recommend it. Every decision that has to travel to someone else is a delay, and a Sprint cannot absorb a delay on every question. The proxy also hides the problem. The team and the leaders can both pretend the role is filled.
Reality check: I know many of you are stuck with a proxy today and cannot change it this quarter. In the episode above I said that, when you are forced to work with a proxy, their only job is to carry priorities from the real decision-maker to the team, and the team’s questions straight back, so they are a conduit, not the source. Treat that as a way to survive the next few Sprints, not a place to settle. Something to ponder: if the conduit is working well, the person at the other end is the real Product Owner. Why do they not have the title?
Scrum is set up to help an organization highlight its dysfunctions. A proxy is the dysfunction showing up in a role, so use it. Push on it. Ask who really orders the Product Backlog. Ask what the person with the title could say no to today. Then take the answer to the people who can change it.
Does this mean getting rid of Business Analysts?
No. Business Analysts are valuable. On a Scrum Team they can be a contributing member as one of the Developers. The Scrum Guide defines Developers as the people “committed to creating any aspect of a usable Increment each Sprint.” That is not only people who write code.
What changes is the role. Instead of relaying decisions made elsewhere, the Business Analyst helps the team understand the customer’s problem, refine the work and deliver something usable each Sprint. The Product Owner role goes to someone who has the availability, the knowledge of the customer and the authority to decide.
What should leaders do this week?
- Ask who owns the order of the Product Backlog, and whether that person can say no to a senior leader.
- Ask your current Product Owner when they last sat with a customer and listened to their problems.
- Ask what happens to a team’s work when a decision has to leave the room.
- Make sure Product Backlog Refinement happens before Sprint Planning, with the person who decides in it.
- Put the person with real authority in the Sprint Review.
- Check that the last Sprint ended with something usable, not just a finished document.
What next?
Not sure whether you have a Product Owner or a proxy? Send me two or three sentences about how decisions get made on your teams, and I’ll tell you whether I can help, or whether it is something you can fix yourselves.
- Leadership or the system is the problem: executive advisory
- The Product Owners need skills: private Scrum training, or see how a private CSPO class works
- It is about you as a leader: 1:1 mentoring
Learn more on my services page.
Who wrote this?
I’m Michael Vizdos. I started in software delivery at EDS in 1991, so I have 35+ years in this work. I have been a Certified Scrum Trainer® since 2006 and have trained 4,900+ Scrum Masters and Product Owners since 2006, from about 1,500 organizations. More about my background.
Weekly, free, no fluff
Get one actionable Scrum idea a week.
Saturday morning emails on Implementing Scrum in the real world — the same cartoons and straight talk that built this site.
Subscribe — It's FreeStuck on something specific? Email me your situation.
