Why Product Teams Fail (And It’s Not What You Think)

I recently finished reading Product Operations by Melissa Perri and Denise Tilles, and it hit me like a revelation I should have had years ago. The many times I’ve watched brilliant product managers struggle, burnout, then leave companies—I thought it was about hiring better people or giving them smaller scopes. I was looking at the wrong problem entirely.

The book nails something I’ve lived through but couldn’t articulate: Most product managers don’t fail because they lack skills. They fail because they’re trying to build products while simultaneously building the systems to do their jobs.

The Hidden Work That Kills Product Teams

"[Product managers] need to be great at user research, analysis, problem identification, problem solving, working with teams, experimentation, and all the other skills that are required of a fantastic product manager. But, without an infrastructure set up to enable them to execute on those skills, many companies will see their product managers and product leaders fail."

I’ve been that product manager. You know the one—spending half your time hunting for customer data across Slack channels, Salesforce, and support tickets. Building your own makeshift analytics dashboards because engineers or data teams are backlogged for months. Facilitating workshops to align teams on process instead of building strategy to direct the team toward what matters most to customers.

It can get exhausting. And it’s completely preventable.

The breakthrough insight from this book: organizations need operating systems. Whether its one based on product or not matters less, these days that is a product operating model where product managers actually do product management. Without it, even great PMs–and often every great engineering manager as well–spend more time being internal consultants and ad hoc systems builders than product builders.

What This Actually Looks Like

The authors organize product operations around three pillars, but what I love is how practical they make it:

Business Data and Insights - This isn’t just another analytics dashboard. It’s about connecting product metrics to business outcomes in ways that actually inform decisions. When your CFO asks how product investments are driving ARR, you have an answer that doesn’t require three weeks of manual analysis.

Customer and Market Insights - Instead of customer research living in a graveyard of Google Docs, this centralizes and organizes customer intelligence. Win/loss analysis, user research, competitive intelligence—all accessible when teams need it.

Process and Practices - Here’s where they get it right: this isn’t about imposing bureaucracy. It’s about scaling the things that work and eliminating the friction that doesn’t.

What struck me as most important here: You don’t need to implement all three at once. Start where it hurts most and build from there.

The Service Design Mindset That Changes Everything

“When I talk about ops, I’ve used words like method or service. That’s also the way I try to run product operations, by providing useful services that do the heavy lifting [for everyone involved].”

This reframe hits home for me. Instead of asking “What process should we mandate?” the question becomes “What service would eliminate the most friction for our product teams?”

Think APIs, not process documentation. Think platforms, not procedure.

For example, instead of a roadmapping template everyone ignores, you build a roadmapping experience: opt-in systems that prevent the need for copy/paste, backed by facilitation training, stakeholder alignment frameworks, and regular review cadences. The service evolves based on feedback, just like any product should.

Why This Matters More Than Ever

I keep thinking about all the organizations I’ve seen struggle with scaling product development. They hire more and more senior PMs, implement new frameworks, reorganize teams—but nothing fundamentally improves. Now I understand why.

They’re treating symptoms, not the system.

The difference between effortless-looking product organizations and constantly chaotic ones isn’t talent or methodology. It’s the invisible infrastructure that product operations provides. The best product teams aren’t superhuman—they have better systems.

What I’m Still Processing

Reading this book left me with some essential questions about my own experience:

  • How does an engineering organization operate without product management at all?
    • I need to understand this baseline behavior to make sense of how great product management and product operations complements it
  • What is the minimum viable product allocation? I have seen platform team statistics that recommend 10:1 engineer to PM, but I’ve experienced as high as 40:1. At what point is it just no longer a product role?
  • What lessons do I want to carry forward and advocate for to parse system problems from individual performance?

And most importantly: What would product development look like if we built the operating system first, then hired the talent to run on it?

I don’t have answers yet, but I know I’m thinking about team effectiveness differently now. The invisible work of product operations might be the most important work in a scaling organization.

Related: