The framework assumes a present, decisive PO. Here's the job when you don't have one.

Early in my time as a Scrum Master, I inherited a team with a Product Owner I think I met properly twice. He was a director with three other things on his plate, and our product was the smallest of them. He was lovely when you caught him. The problem was catching him. Questions piled up in a channel he didn't read. The team would reach a fork in the work, realize they couldn't go further without a decision, and quietly drift to something else. We were busy and we were stuck at the same time, and for a while I thought the answer was just to chase him harder.

It wasn't. Chasing a busy person mostly turns you into the thing they start avoiding.

What the framework promises, and what you got

The Scrum Guide is clear about the role. The Product Owner is accountable for maximizing the value of the product, owns the ordering of the backlog, and, in its own words, for them to succeed the entire organization must respect their decisions. The Product Owner is one person, not a committee {Scrum Guide 2020}. That's the design, and it quietly assumes someone present, empowered, and close enough to the work to answer the questions only they can answer.

Now look at your actual week. Your PO might be a senior manager doing this on the side. They might be travelling, wedged into back-to-back meetings, or responsible for four products at once. On paper the accountability is still theirs. In practice the availability is gone. That gap, between the role as written and the person as scheduled, is one of the most common realities in delivery, and almost nobody is taught what to do inside it.

And it matters more than it feels like in the moment. Across decades of the Standish Group's research into why projects succeed or fail, user involvement has repeatedly come out as the single biggest success factor, while a lack of it sits among the top reasons projects fail {Standish Group, CHAOS}. Your Product Owner is your closest line to that involvement. When they vanish, the risk isn't just that you're annoyed. It's the product.

Start with why they're gone, not how to corner them

Before any tactic, get curious instead of frustrated. An absent PO is almost always a symptom, and the cause changes what you should do about it.

• Overloaded? Your job is to make their part of the work smaller and cheaper, not louder.

• Doesn't know the team is blocked? Your job is to make the cost of the blockage visible to them.

• Never actually empowered to decide? No amount of chasing helps. That fix lives higher up the org.

• Genuinely checked out? That's a real conversation, had kindly and directly, not a process tweak.

Naming the real cause stops you spending a month on the wrong fix. A chasing problem and an empowerment problem look identical from the team's seat, but they need completely different responses, and only one of them is yours to solve. It also keeps the relationship warm, which you are going to need every single week after this.

Make decisions cheap to make

Here's the shift that changed everything for that team of mine. We stopped sending the Product Owner questions and started sending him decisions, already chewed.

An open question, can you look at the backlog when you get a chance, asks a busy person to do the framing, the thinking, and the deciding, all in time they don't have. So it waits. A decision with options, Option A or B for next sprint, and if I don't hear back by Thursday we'll go with A, asks for ten seconds and a nod. We'd done the analysis. We proposed a sensible default. We set a deadline that protected the team either way. Answers started coming, because we'd made saying yes almost free.

Then we batched them. Instead of pinging all week, we held the questions and brought them to one short, regular slot, already turned into options.

Five scattered got-a-sec interruptions became one ten-minute decision session. The PO felt respected instead of nibbled to death, and the team stopped stalling in the gaps between pings. Nobody had to become a hero. We just lowered the price of a decision until a stretched person could afford to pay it.

We also kept a tiny decision log, one shared page: the question, the options, the default we'd take, and the date we needed an answer. It did two quiet jobs. It let the PO catch up async, at 7am or between flights, without a meeting. And it created a gentle record, so when something was decided by default because nobody replied, that was a visible, agreed rule rather than me going rogue. A team that can decide asynchronously stops being hostage to one person's calendar.

Protect the team, and protect the role

Two guardrails matter here, and they pull in opposite directions, so you have to hold both at once.

First, shield the team. Don't relay every bit of PO churn straight onto them. If the PO changes their mind on Friday about something the team built on Tuesday, that's yours to absorb and reframe, not to dump raw on people who will just feel the whiplash.

Second, and this is the one people get wrong, don't quietly become the Product Owner. It's tempting. You're there, you understand the work, decisions need making, so you start quietly making the value calls yourself. For small, reversible things, fine, just agree a clear lane for that out loud. But the big what-are-we-building-and-why calls aren't yours to own, and if you swallow them you let the organization off the hook for a problem it actually needs to feel and fix. You can hold the gap open honestly. You shouldn't paper over it.

Escalate the pattern, not the person

If the absence is structural rather than the odd busy week, you'll eventually need to raise it, and how you do that decides whether it helps or backfires. Don't escalate the PO is never around. That lands as a complaint and puts a decent person on the defensive. Escalate the pattern, with evidence. Here are the decisions that waited last month. Here's how many days each one cost us. Here's the feature that slipped because of it. Make it about flow and risk, never about someone being bad at their job.

Most of the time the manager genuinely didn't know the arithmetic. They knew the PO was busy. They didn't know busy was quietly costing two sprints a quarter. When you show them that, calmly and with numbers, you're not throwing anyone under the bus. You're handing them the one thing that lets them actually fix it.

Holding the gap is the real skill

An absent Product Owner isn't a reason to stop delivering, and it isn't a licence to take over. It's a real constraint to manage with care, like every other gap between the clean framework and the messy week. You make decisions cheap. You batch them. You shield your team from the churn without hiding the cost from the people who can resolve it. And you stay warm with the person, because they're rarely absent on purpose, they're just stretched thin.

Do that well and you've shown the most underrated skill in this job: keeping a team moving and a relationship intact when the textbook conditions simply aren't there. And here's the quiet bonus, it makes a great interview story. Most candidates describe the ideal Scrum setup they read about. You can describe the messy one you actually steered through, which is the version every hiring manager has lived and is listening for. That isn't a workaround you apologize for. On most real teams, that is the work.

Sources

Schwaber, Ken, and Jeff Sutherland. The 2020 Scrum Guide.

Standish Group, CHAOS reports.