Operations Discipline Is What Separates Real Products from Demos

4 MINS

Half my career has been spent in the operations underbelly of consumer products — capacity planning at Zomato, escalation matrices at People Interactive, stakeholder management with outsourcing partners at Swiggy. None of that was glamorous. All of it was load-bearing. It taught me that the difference between a real product and a polished demo is operational discipline, not design polish.

The product manager who can't read an Ops dashboard is half a PM

Every PM I respect can read an ops dashboard fluently. Open rate, average handle time, abandonment rate, escalation rate, queue depth. These aren't BPO metrics. These are the heartbeat of any consumer product that has humans somewhere in the loop — and almost all of them do.

If you can't tell the story of the last 24 hours by looking at the ops dashboard for 90 seconds, you don't know your product. You know your roadmap.

That's a difference that matters more the bigger the product gets.

What operations taught me that product school didn't

There are three lessons I keep coming back to:

Capacity is a leading indicator of churn. When ops gets stretched, customer experience degrades two weeks later, and churn spikes a month after that. If you're not watching capacity, you're being surprised by churn.

Process exceptions are product gaps. Every escalation matrix I've owned was, fundamentally, a list of failures of the product. Each item is a feature request the user couldn't articulate.

Outsourcing partners are users. The vendor team handling tickets is using your product 8 hours a day. They have more in-depth feedback than your "power users". Most teams ignore them. I've never met a great consumer-product PM who didn't have at least one of these instincts deep in their bones.

How this connects to AI

When I see AI features rolled out as "agent assists" or "summarisation tools" inside operations, the ones that survive are the ones that respect operational discipline.

They don't break the queue. If your AI summary is slower than the human reading the ticket, it's a regression, not a feature.

They surface confidence, not just answers. An ops user can act on "70% confident" much better than an opaque "here's the answer".

They have an off-switch with no friction. If ops can't disable the AI for a tenant in 30 seconds during an incident, you've shipped a liability. The teams who get this right are usually the ones with operations backgrounds. The teams who get it wrong are usually the ones with only product-design backgrounds.

What I look for when I'm hiring or working with PMs

After ten years in this space, here's what I quietly check for:

Can they describe the worst day of their last product? If yes, they were close to the operations of it. If they describe the best feature, they probably weren't.

Do they know their CSAT and their NPS by heart? Or do they "have to look it up"?

Can they sit through a customer-care call without flinching? That hour is more valuable than any user research session. These are the small tells. They're underrated. They're what separates someone who *manages* a product from someone who *runs* one.

The discipline I'm taking into AI

Whatever I build next — at Auctane, in Curious PM, after that — I'm carrying these instincts with me. Polish ages. Operational discipline compounds. And in a world where everyone has access to the same AI models, the operational discipline around how those models are deployed is the only durable advantage a product can have.

That's the bet I keep making. So far it's been the right one.

What Building AI Photography at OYO Taught Me About Useful AI

Hrishi skipped presentations and built real AI products.

Hrishi Swaroop Bhatnagar was part of the March 2026 cohort at Curious PM, alongside 17 other talented participants.