From Customer-Led Development: How to Build What Your Customers Want When AI Can Build Anything — the operating manual for building what customers want when AI can build anything. See every chapter.
Most customer-led companies I've been inside have some version of a role that most other companies can't even define. Ask them what Product Ops does and you'll hear "project management," or "data stuff," or "operational support," which is a polite way of saying admin.
They're wrong. And the cost of being wrong doesn't show up on any dashboard. It shows up as customers who leave over features you already built.
The feature that shipped to nobody
Here's a composite of a story I've seen play out more times than I can count.
A mid-sized customer tells their account executive they need bulk export. Without it, their ops team is copying data by hand every Friday. The AE says, truthfully, "It's on the roadmap." The AE writes it in a call note. The note lives in the CRM.
Separately, three other customers ask for the same thing through support tickets. Someone tags them. The tags live in the help desk.
A PM hears about it in a user interview, sees it as a real pain, and fights for it in planning. Engineering ships it four months later. There's a changelog entry. Maybe a tweet.
Six weeks after that, the original customer churns. The exit survey lists their reason: "No bulk export."
Nobody did anything wrong. Sales listened. Support tagged. The PM prioritized. Engineering shipped. Every individual part of the machine worked. The machine itself didn't, because nobody owned the path from what the customer said to the customer knowing we did something about it.
That path is the job.
What Product Ops actually is
The cleanest way I can describe it: Product Ops is the EA for the product organization.
Not "executive assistant" in the schedule-meetings sense. EA in the sense that a great one makes an executive ten times more effective by handling everything that isn't the core job. A great Product Ops makes the whole product org more effective by handling everything that isn't building and shipping.
Concretely, that means owning the system that captures customer truth and routes it into decisions:
- Synthesizing feedback across channels, so the sales note, the support tags, and the interview insight become one signal instead of three fragments.
- Tracking promises to delivery, so when engineering ships, the customer who asked actually hears about it.
- Being the neutral arbiter when sales, product, and engineering read the same feedback three different ways.
- Measuring whether the system is healthy: how long it takes customer input to reach a decision, and how often loops actually close.
None of this is glamorous. All of it has to happen, or feedback starts falling through the cracks again.
The confusion, in one table
The easiest way to see the role is by the question each adjacent role asks.
| Role | The question they ask |
|---|---|
| Project Manager | Did we ship on time? |
| Product Manager | What should we build? |
| Customer Success | How is this one account doing? |
| Data / Analytics | What do the numbers say? |
| Product Ops | Did the customer who asked for this actually use it, and what patterns are we seeing across everyone? |
Every other role on that list is doing real, necessary work. None of them is accountable for the whole loop. That's the gap the bulk-export customer fell into.
Where it sits matters more than you'd think
One detail teams get wrong constantly: reporting lines. Put Product Ops under general operations and it optimizes for efficiency without asking whether the process serves customers. Put it under engineering and customer voice becomes secondary to developer metrics. Put it under sales ops and the roadmap gets captured by whoever's loudest on the revenue side.
It belongs under the Head of Product, embedded where customer truth needs to flow, with real access to strategy and the roadmap. Org charts are opinions about what matters. This one is a strong opinion.
The 3-PM mark
You don't need this role on day one. With one or two PMs, the system is small enough that people can hold it in their heads. A founder often plays Product Ops by default, because they're the only person who sees every channel.
Then the team grows, and something subtle happens. Each PM hears a slice. Nobody hears the whole. Feedback scatters across Slack, email, tickets, and call notes. Someone starts a promise-tracking spreadsheet that's out of date within a week. PMs drift toward spending a fifth of their time on operational glue instead of talking to customers.
Rule of thumb: Without Product Ops, customer-led breaks down around the 3-PM mark.
Not because people stop caring about customers. Because caring doesn't route information. Systems do, and systems need an operator.
The flip side matters too. If you're pre-product-market fit, still figuring out who your customers are, or you don't have basic systems in place yet, hiring Product Ops is premature. They need something to operate.
A leading indicator, not a luxury
Every operationally customer-led company I've seen up close put someone in charge of keeping customer truth flowing well before it felt necessary.
That's why I treat the existence of a Product Ops role as a signal. If you're evaluating a company to join, or one to learn from, check whether someone owns this. It tells you more about product maturity than the roadmap does.
And if you're the one running a product team and you recognized your org in the bulk-export story, the answer isn't to ask everyone to try harder. Everyone already tried. The answer is to make the loop someone's job.
The full chapter goes much further: the daily-to-quarterly rhythm of the role, the metrics that tell you the system is slipping, what to look for (and the red flags to avoid) when you hire, and three ways to start before you can justify a full-time seat.
If you want the complete system for keeping customer truth flowing as your team scales, it's all in Customer-Led Development.
And if ideas like "caring doesn't route information, systems do" are useful to you, subscribe to the Context Limit newsletter for more essays on how product teams actually work.