Product dysfunction isn’t a people problem. It’s a systems problem.
Before I tell you what The Operating Gap is, let me tell you what it's for.
New here? This one’s from the archive — first published back in April, before most of you subscribed. I went back and sharpened it, because it’s still the clearest example I’ve got of this pattern. If you read it the first time, the story’s the same. Just tighter.
The dev team was drowning — multiple backlogs, a release plan due, bugs still open from 3 releases back, and new priority requests landing every week.
From outside, it looked like the team wasn’t delivering.
The team was fine.
Every sprint, the same thing happened. Hundreds of tickets from an accessibility audit had piled onto the backlog. The team was mid-build on new functionality in another area. And with no real QA (quality assurance) gate, user bug reports kept climbing.
Next sprint. Same story.
They made the calls they could — moving the software forward while competing priorities fought for the same hours. No buffer. No dedicated capacity. Accessibility kept losing.
It accumulated. Sprint by sprint, invisibly — until the backlog outgrew what anyone could manage.
Someone on the team had been quietly absorbing the pressure — shielding everyone else from what was building above them, holding the line where they could, pushing back where they couldn’t. When that stopped, the team stood exposed. Nobody — not the leads, not the business — knew what they were actually sitting under.
Here where I Started
The backlog was over 800 tickets. That number alone made the work feel impossible: an undifferentiated pile of debt with no clear start, no clear end, no way to know what actually mattered.
First move: draw a cutoff for version support. Then deprecate anything that fell outside it. Next, prioritize — disciplined work to sort what still had actionable data from what was just noise. After triage: 256 tickets. Still heavy. But doable, if the team could stop the inbound.
The team was struggling.
Nobody had balanced the workload for these competing priorities running at once. Two overwhelmed engineers. One still onboarding. 256 tickets. 4 sprints to clear them.
The business looked at the pile and saw a delivery problem. It never acknowledged the extent of what a small team was actually carrying.
I looked at it and saw the inevitable result of a system with no buffer built into it. No workload structure accounted for what the team was carrying. Just people doing their best inside a setup where success was nearly impossible.
The people weren’t the problem. The system was.
This is the pattern I’ve spent years watching play out across product teams and delivery organizations. The names change. The industry changes. The structure is almost always the same: indecision, unclear priorities, and testing in production pile up until you get a backlog like this one. Processes that should exist don’t. Leaders hand out workload with no plan, and people get set up to fail.
This newsletter covers the dysfunctional patterns you’ve lived inside. I’ll show you what’s broken — and the levers you can pull to make a difference.
If you’re tired of watching good teams fail or of receiving another vague project without a plan, this is for you.
— RaeVyn
If your team is living inside a pattern like this one, I help organizations see the structure underneath it — and build what’s missing. Send me your stories: message me on Substack