AI Is Never Competing with Humans. It Works Side by Side

You moved from software development into business analysis, insurance-technology consulting and entrepreneurship before joining Zato as Head of Product. How did that path shape the way you think about the discipline?

I started my career in 2008 as a software developer and then moved into business analysis. That shift happened while I was working at a captive company, where I got the chance to sit directly with business stakeholders, gather requirements and see the development work through. That is where I realised my real interest was in bridging the gap between business and technology — business people often cannot fully understand technology, and technology people often cannot fully understand the business, and that gap is where I found my strength.

From there I moved to an IT consulting firm building systems for insurance companies globally, working on digital transformation of their business processes. I eventually started an innovation lab there, building new products across insurance domains. That is where I noticed something important: not every product we built was actually sellable. People liked the demo, but not everything converted to a sale. I realised there was a gap in my own product management craft, so I did an MBA focused on product management.

That degree took me into a lead strategy and product consulting role, working closely with customers to understand their pain points and build the right solutions. Somewhere in that journey I moved from product management into product leadership, then ventured into entrepreneurship with a friend. I have been with Zato, which builds an AI-native compliance platform for accounting firms, for the last few months. So the arc has been developer to product manager to product leader — and every stage added a layer to how I think about the job.

Zato’s whole pitch is turning manual compliance checks into something AI can handle. As a product manager, how do you make sure the product still serves the end user — and does AI start doing the work of a product manager itself?

I would push back gently on the word “automation.” We are not building simple workflow automation — we are building an AI-native platform where AI effectively does the work of an accountant: extracting information, compiling it into compliance documents and getting it filing-ready. It is not automation so much as transformation through AI.

So what should product managers be learning or unlearning in this era?

Earlier, we built deterministic systems: you gave a defined input and got a defined output, and anything else was a bug. Now we are building probabilistic systems, where the same input will not always produce the same output. That is where the real challenge — and the real skill gap — begins.

First, product managers need the judgement to decide how much accuracy they actually need from an AI agent, or from a chain of agents. Second, because the old input-output clarity is gone, you need the skill to precisely define what “working correctly” even means for a given agent. Third is the cost-versus-accuracy trade-off — deciding how much you are willing to spend for a given level of accuracy. And fourth, unlike deterministic systems, AI products need a learning loop: a way to feed outcomes back into the system so the agent gets smarter over time. If 90 per cent of a task is automated and a human still handles the remaining 10 per cent, you need to capture what that human is doing and feed it back so the agent improves.

There is one more shift worth flagging. Earlier, a human interacted with a system and the system gave an output. Now we are building chains of agents, where one agent’s output becomes another agent’s input. If your first agent is 90 per cent accurate and it feeds a second agent, that second agent needs to know it is working with 90 per cent accurate information, not 100 per cent. If accuracy drops by even 10 per cent at every step in a five-agent chain, your final output is only around 59 per cent accurate — the errors compound. Designing agent chains without losing accuracy at each handoff is a genuinely new skill for product managers.

So this is less about competing with AI and more about working alongside it?

Exactly — I would never say AI is competing with humans. AI is an enabler of human thinking, not something that overtakes it; it works side by side. AI can play several roles. It can be an automator, simply executing a task. It can be a collaborator — for instance, when a customer-support agent is handling a query, AI can surface information in real time and make the conversation more seamless. It can be a personaliser, the way Amazon or Netflix learn your behaviour and shape recommendations around it. And it can be a safeguard — proactively flagging a fraudulent transaction during payment processing, for example. But AI alone cannot do any of this. It works with a human for a better outcome, better efficiency and better productivity.

Given your background across insurance and now compliance, what’s the biggest mistake you see junior product managers making — particularly around the regulatory environment?

In regulated domains like banking, insurance, accounting and compliance, it isn’t enough to build the features customers need — you also have to understand how the domain itself is regulated. There can be scenarios where you simply cannot move data across geographies, or where a model you want to use crosses a line a regulator has drawn. Not every functionality carries the same level of regulation: a system that just recites information back might only need PII (personally identifiable information) masking, while one that exchanges information with a third party sits under a far stricter regime. As a product manager in a regulated space, you always need to ask whether a regulatory constraint applies before you build — because even a strong use case can be blocked by one.

And on the user side — what happens when a product manager projects their own assumptions about requirements instead of listening to what the customer actually needs?

It really depends on whether you are building for B2B or B2C. In an enterprise, B2B environment, the end user is often not the one making the buying decision — that might sit with their manager or service line head. You still need to understand the end user, but functionality tends to matter more than user experience, and because most users in a B2B segment have broadly similar needs, a representative sample of research is usually enough.

In B2C, user experience matters as much as functionality, and every customer can have a genuinely different opinion. That means you need a much deeper understanding of your persona and segment, pulling in demographic, psychographic and lifestyle inputs rather than a small sample. It’s not that customer understanding is unimportant in B2B — it’s just far more structured there than it is in B2C.

Product managers rarely have complete information and often have to make decisions under ambiguity. What signals tell you whether a product is heading in the right direction?

Whatever feature or product you are building, you start with an objective and define the metrics that will tell you whether it has succeeded — and just as importantly, how you will actually measure that metric. Saying “I want to know how many customers are buying this” isn’t enough; you have to define, for instance, exactly what counts as a drop-off. Once the product is live, you monitor those metrics continuously.

If the numbers aren’t meeting target, that isn’t an automatic signal that the feature has failed. You did research before you built it for a reason, so the first step is to investigate why the metric is off — not to jump straight to “this isn’t working.” Only once you’ve genuinely understood the root cause should you decide on a corrective action. There are certainly cases where, even after investigating, the product genuinely isn’t delivering — but you shouldn’t reach for that conclusion as the first move.

A concrete example: we built a straight-through processing system for an insurance company. Traditionally, a customer buys a policy through an agent, the agent fills out an application into a new-business system, and the lead time from application to completion can run five to seven days — not a good outcome, because the longer the delay, the more likely the customer drifts to a competitor or simply loses interest. We built a straight-through system where, for simpler products, the customer enters their details directly and the application goes through auto-underwriting against rules we defined — say, any application under $50,000 is good to go without manual underwriting, while a tobacco or alcohol consumer might require an additional premium or manual review.

We had set a 15-minute service-level agreement for issuing a policy, and it wasn’t being met. When we went back and analysed why, we found customers were filling in information but had no guidance on which of several suitable products was right for them, so many simply didn’t complete the application. So we built in product recommendations at the point of data entry, and where customers still didn’t finish, we had our agents proactively follow up to help them complete it. Once we made that change, conversion improved. The lesson wasn’t “straight-through processing doesn’t work” — it was that the real blocker was a guidance gap we hadn’t originally designed for.

Let’s talk about Zify. It identifies errors in documents and compliance checks — where in the product do you build in human checks, and how do you decide where they belong?

Zify is more than an error-finder. It’s an AI layer across the Zato platform that guides a user from the moment they onboard. It has two aspects: it continuously monitors what’s happening in the background, and it surfaces guidance whenever a user has a question — that part is fairly deterministic, because we know what a correct onboarding journey looks like.

The second part is more dynamic. As information from different sources is compiled into the papers required for a filing, Zify identifies variances, explains the reason for them, and suggests what the accountant should do about them. So it isn’t just flagging errors — it’s handholding the user through the whole journey, behaving almost like an accountant’s companion throughout the compilation process.

Zify operates under strict data-privacy constraints, and you can’t train your AI model on client data given how sensitive that domain is. How do you keep improving the product without that lever?

The key thing to understand is that we are not building a product based on models — we’re building it based on domain. Whatever technology changes come along, that shouldn’t create an issue for us, because we’re built to take advantage of models becoming better and more efficient, not dependent on any one of them. I don’t see technology advancement creating a hindrance to what we’re doing at Zato — if anything, it gives us more flexibility.

What’s one piece of advice you’d give an XLRI student who wants to build a career in product management?

I always come back to first principles. However much the technology advances or disrupts, the basic first principles of product management don’t change — solving the right customer problem, believing that value is created only when something is delivered and adopted, not simply built. AI will only speed up the mundane and repetitive parts of the job, freeing up time for the work that actually matters, so those first principles need to stay strong.

I’d also flag two traits. First, product management is fundamentally about making decisions under ambiguity, so you need to be comfortable with that. Second, you need to be able to handle failure without becoming too attached or emotional about it — the odds of failure in this field are genuinely higher than the odds of success, and every failure is a source of learning about how to make a better decision or build a better product next time. Without those two traits, I don’t think product management is the right space for someone.

It’s also worth knowing that product management has two different tracks. If you’re drawn to seeing quick results and want that sense of gratification, product execution — where the “why” is already defined and your job is the “how” — might suit you better. If you’re drawn to the ambiguity of product strategy, where you rarely have all the information and have to build a hypothesis and convince people why a particular idea is worth pursuing, that’s a different comfort level entirely. Know which one you’re signing up for.

What’s your perspective on the one-year MBA programme here, against the traditional two-year format?

For me, whether it’s a one-year or a two-year programme doesn’t really matter — you can build these skills even without a formal programme. What matters is the mindset you develop and the thinking process you bring. You could do a two-year programme and still not internalise the core principles of product management, and at that point, the duration is irrelevant. It’s about how much of what you’ve learned you can actually implement in the real world.

Having real-world experience before a programme is genuinely useful, because you already understand the real challenges and bring a sharper perspective to the classroom. And regardless of the programme’s length, most of the learning ultimately comes from your cohort. The content itself — a framework here, a matrix there — is available to anyone, anywhere in the world. What you don’t get without implementation and without a strong cohort is the nuance: the different ways people have handled similar challenges.

How do you decide where to bring humans into the loop for error handling in an AI-driven system?

The key question is recoverability. If something goes wrong and it’s still correctable, you have some room to work with. But if a failure can’t be corrected — say, you’re filing a return directly with a tax authority, and a mistake there can’t easily be undone — that is exactly where you should not take a chance, and where a human needs to be in the loop.

Where you do bring humans in, the goal is to reduce their workload as much as possible. If it’s a simple judgement call, that’s fine. But if you’re asking someone to review 200 data points, that defeats the purpose — it suggests your underlying model or implementation is wrong. The right use of a human in the loop is for judgement, not for review at scale.

On error handling more broadly: no single model gives you consistent accuracy across every scenario, so you always need a fallback in place — if one model underperforms, the system falls back to another, and then another if needed. The catch is that different models won’t necessarily give you the same accuracy, so you need to define the minimum acceptable accuracy before you build that fallback logic. You cannot simply implement one model and call it done.

It’s not always the case that you get the same input and generate the same output. That’s where the actual challenge comes in

AI products need a learning loop: a way to feed outcomes back into the system so the agent gets smarter over time

AI is an enabler of human thinking, not something that overtakes it; it works side by side

You should not simply skip to saying my feature isn’t working. Instead, you should investigate why the metric isn’t coming through — before you decide what to fix