The Product Owner Who Was Drowning in Tickets - Until She Stopped Being the Single Point of Failure

I had 347 unread Slack messages by 9:15 a.m.

Not because I was popular. Because nothing moved without me saying yes.

Every edge case. Every design tradeoff. Every 'quick question' that was never quick. The team had learned that the fastest way to unblock themselves was to ping me, and I had learned that the fastest way to keep things moving was to answer immediately.

How I became the bottleneck I kept complaining about

It started innocently. In the early days, the team was small. Four developers, one designer, me. Every question came to me because there was no one else.

Then the team grew to twelve. Then twenty. But the decision-making model never changed. I was still the person who knew 'the context.' I was still the person who could say 'no, the stakeholder actually meant this.'

And I wore it like a badge. Being indispensable felt like being valuable.

Until the sprint reviews started going like this:

• "We couldn't finish this - we were waiting on a decision from you."
• "We went with option A because you were in a meeting and we needed to move."
• "We didn't start that story because the acceptance criteria weren't clear and you hadn't responded."

Every blocker traced back to me. Not because I was slow. Because the system required me to be fast at everything, all the time, simultaneously.

The week I disappeared

I got COVID. Not the mild kind. The 'lying in bed for six days unable to look at a screen' kind.

When I came back, I expected a disaster. I expected half the sprint to be blocked, the backlog to be a mess, stakeholders to be furious.

Instead, I found something worse: the team had been fine.

Not great. Not efficient. But fine. They'd made decisions. Some were wrong. Some were right. All of them were made without me.

The team didn't need me to make every decision. They needed a system that made most decisions unnecessary.

The idea that rewired my thinking

I was reading the Team Helix blog during recovery - partly out of curiosity, partly because I was trying to understand why I felt so burned out in a job I used to love.

Two ideas clicked together:

1) Governance isn't about gates. It's about guardrails.

I had been the guardrail. A human guardrail with a response time measured in hours instead of milliseconds.

2) Decision context should outlive the decision-maker.

All of our decision context lived in my head. When I was sick, it was gone. When I eventually leave this role, it'll be gone again. The team didn't have a knowledge problem. They had a me-dependency problem.

The three changes that freed the team (and saved my sanity)

Change #1: We codified the 'obvious' decisions

I catalogued every question the team had asked me in the last month. Eighty percent of them had answers that followed a pattern: 'If X, then do Y. If Z, escalate.'

Not guidelines. Rules. With exceptions handled through a clear escalation path that didn't default to 'ask the PO.'

Change #2: We made constraints visible, not verbal

Instead of me verbally explaining 'the stakeholder cares about X but not Y,' we encoded those constraints into the work itself. Acceptance criteria became explicit tradeoff boundaries: 'Performance must stay under 200ms. Visual polish is secondary. Accessibility is non-negotiable.'

Change #3: We tracked decisions, not just work

Every meaningful product decision got a lightweight record: what we decided, what we considered, why we chose this path, what constraints applied.

This wasn't bureaucracy. It was three lines in a shared doc. But it meant anyone could understand why something was built a certain way - without scheduling a meeting with me.

What changed

My Slack unread count dropped from 300+ to about 40.

Not because people stopped caring. Because they stopped needing me to care for them.

• The team started making decisions in minutes that used to take days.
• Sprint reviews stopped being lists of things that were blocked.
• Stakeholders got more predictable outcomes, even though I was in fewer meetings.
• I started doing actual product work again - discovery, strategy, user research - instead of being a full-time decision-routing service.

My manager told me the team seemed 'more autonomous.' He meant it as a compliment. What he was actually seeing was a team that finally had the system to support autonomy.

A quick confession

There wasn't a specific week of COVID. There wasn't a single Slack message count that triggered the change. There wasn't one clean moment where it all clicked.

But the pattern is everywhere.

Product Owners don't burn out because they're bad at the job. They burn out because the job, as defined, makes them a single point of failure in a system that requires parallel processing.