I spoke with a product ops leader who has run operations at three very different companies: a 6,000-person fashion retailer, an IPO-track automotive marketplace, and a 200-person SaaS company. Different industries, different tools, different team sizes, completely different cultures.
The coordination failures were identical at all three.
That’s the part worth sitting with. When the same ops discipline, applied by the same person across three radically different organizations, keeps finding the same gaps, the gap is systemic. Coordination debt accumulates from the product development model itself, not from the particular people or tools involved.
The first thing that always breaks
At every company, the first fix was the same: making sure people understood what they were expected to do within the development cycle. Not which tools to use. Not which ceremonies to attend. Whether they knew their role in the sequence, when their input was needed, what “done” looked like at their stage.
Everything else varied. That stayed constant.
Process compliance is not coordination
At the 200-person SaaS company, teams followed the process. PRDs were written on time. Stakeholders were tagged in Notion. Every box on the checklist was checked. The coordination was still broken.
PMs and engineering managers were tagging each other in 300 to 400 Notion notifications a day instead of sending a five-minute Slack message asking for fifteen minutes to walk through something. The tagging was process compliance. The conversation would have been coordination.
This is a pattern I see repeatedly. A decision can look closed on paper — the PRD was approved, the ticket was created, the stakeholder was notified — but if the people involved never had the conversation where they surfaced the assumption that will blow up in sprint two, the closure is cosmetic. The rework is already baked in.
Where cycles actually break
Delivery, the middle of the product development cycle, is typically the easiest part to fix. The tools are mature. Engineering teams know how to ship.
The hard parts sit at both ends.
At the beginning: choosing what to build. With AI now generating more customer data, user feedback, and market signals than any team can manually process, the curation problem has scaled. Product teams have always struggled with prioritization. The volume of input they need to filter has multiplied, and the frameworks for doing that filtering haven’t caught up.
At the end: closing the loop on whether what was built actually worked. He called it “set and forget” — teams ship a feature and immediately move to the next one. Nobody circles back to assess whether the thing they built solved the problem it was meant to solve. That missing feedback loop means beginning-of-cycle decisions get made against stale assumptions. The cycle compounds.
The handshake signal
At the 200-person company, he tracks one specific leading indicator: time to confirm scope.
The product-engineering handshake — the moment when product and engineering agree on scope for a planning cycle — should happen by week two. When it slips to week four, something upstream is already broken.
The diagnosis forks from there. If scope was unclear, that’s a product problem. If scope was clear but engineering didn’t engage until late, that’s an engineering engagement problem. Either way, the delivery miss is locked in by the time the handshake slips. Waiting for the sprint review to discover it means finding out six weeks too late.
DORA metrics will register the same problem later as extended lead time. The handshake signal catches it weeks earlier.
Proactive ops versus reactive ops
He described two versions of himself.
Reactive: he shows up after deadlines have been missed. He asks why. He traces the cause. He recommends a fix. Teams experience him as the auditor. He called himself “the bad cop.”
Proactive: he catches the signals before the miss. The handshake hasn’t happened by week two. A cross-functional dependency hasn’t been confirmed. A stakeholder hasn’t been looped in. He nudges the team before anything breaks. Teams experience him as the enabler.
The difference between those two modes comes down to one thing: whether he has visibility into coordination signals early enough to act on them. Most ops leaders don’t. They’re buried in the operational work itself, producing reports, running ceremonies, chasing status updates. The reactive mode prevents the proactive mode from ever starting.
What AI actually changed
He uses AI extensively, but not to automate coordination. He uses it to automate the grunt work that was consuming his signal-reading time. Reviewing PRDs for completeness. Translating Jira data into the financial language his CFO needs. Assessing whether a roadmap item maps to stated strategy.
With that time recovered, he spends more of his day reading the human signals that AI can’t parse: which PM hasn’t talked to their engineering counterpart this sprint, which team’s energy has shifted since the reorg, which handshake is three days late and why.
AI made him more of a people-reader, not less. The tool handles the artifacts. The ops leader handles the relationships.
The scrum master gap
The dedicated scrum master — the person who sits in every ceremony and tracks whether process is being followed — is a role in decline. He was blunt about it.
But the needs that role was created to serve are only growing. Tracking whether action items from a meeting actually get done. Making sure the agreement from Tuesday’s planning session survives contact with Thursday’s priorities. Facilitating the conversation between the PM and the tech lead who disagree on scope but haven’t said so directly.
Those functions matter more as organizations add cross-functional complexity. Right now they’re falling through the cracks. The scrum master title is going away. The coordination work it was supposed to do is piling up with nobody assigned to it.
The pattern across all of this is the same. The product development model, and specifically the coordination layer inside it, is the structural variable that determines whether a team ships well or ships late. Tools change. Team sizes change. Industries change. The coordination patterns repeat.
An ops leader who can see those patterns early stops being the auditor and becomes the person who makes the system work.
This is the gap Growth Wise instruments. Not the sprint velocity, not the delivery metrics — the coordination layer upstream of all of it. The signals that tell you a miss is coming before anyone has missed a deadline.