Your PM Surface Area Is Only Going to Keep Increasing

When the next generation of product managers (PMs) looks back at this era, what’s the one thing you think they’ll be grateful this generation of product leaders got right — and what might they look back on and think, “what were you thinking”?

On the first part — if you ask almost any product leader what the top three things a PM should be doing are, the word “customer” comes up almost every time: customer focus, customer understanding, customer perspective. I think that’s the biggest strength of the function, and it’s also the thing most immune to changes in technology. If you keep the focus on the customer and the underlying business problem, that will serve you well even as the frame of reference changes, the technology changes, and the way products get delivered changes. That’s the thing I hope the next generation stays grateful for.

On the second part — I’d point to the whole notion of siloed product-value delivery, which is already being disrupted. We’re moving towards a model where one person builds the product, launches it and gathers customer feedback — what people call the “product builder” phenomenon. I’d be cautious about assuming that’s the model that’s here to stay; I think there will be further specialisation within that role over time. So I don’t have a clean answer for what’s sub-optimal today, but if I had to bet, the current product-builder approach in its purest form probably doesn’t hold for the next 5-10 years.

As MBA students, we’re trying to make deliberate career choices, but the more people I speak to, the more I realise careers are often shaped by unexpected opportunities. Looking back, was product management always the destination for you, or did it emerge along the way?

I started as an engineer, in systems engineering — essentially debugging on Linux kernel systems, part of the hardware setup, about 20 years ago. I did my MBA after that because I wanted to move closer to the customer and business side. Frankly, in 2011, when I effectively became a product manager, the function barely existed as such in the way we talk about it today — it was a very nascent phase.

Did I sleepwalk into it? I don’t think that’s quite true — I definitely knew the kind of work I wanted to do, even if the label “product manager” was a little fuzzy at the time. I also understood clearly what I didn’t want to do. As an MBA student, I knew I didn’t want finance, I didn’t want marketing, I didn’t want HR. So, in some ways, I chose it by elimination, and then I read up on what it takes to succeed as a PM — understanding customer and business value, some depth in tech, and how to leverage platforms at scale. That suited my temperament as an engineer well. I thought combining my business understanding with tech leverage was a good fit, and from there it was really about following my curiosity — chasing the gap between where I wanted to be and where I actually was.

Your profile tells the story of the organisations you’ve been part of and the milestones along the way, but it doesn’t tell the story of who you became in the process. What’s one experience that quietly rewired how you think, and has stayed with you since?

The people aspect is probably the most overlooked part of product management, and I say that because the function is largely a very individualistic, intellectual one — PMs are largely expected to drive things alone, to own outcomes end to end. That sometimes leads to a culture with less focus on building the PMs themselves — the skills, the growth, the function as a whole. Evolving on that front has genuinely been a journey for me.

I’ve been managing people since 2015 — hiring them, growing them, and in some cases letting them go, or making that call for myself as well. That people dimension matters even more now, because the leverage of the function itself is increasing: your surface area as a PM keeps expanding, which makes the role of a PM leader — giving direction, keeping a group of PMs moving coherently in one direction, giving them a sense of purpose — even more critical.

I’ve worked in India, in the Gulf, for companies based in Europe and the US, across very different set-ups and maturity stages. If I had to name the single most overlooked, highest-leverage part of the job, it’s this — leading PMs, not just leading products.

You’ve worked across different domains, geographies and scales of organisation, including different e-commerce set-ups. How would you describe the difference in how product thinking actually happens across these organisations?

Even “product thinking” is only one part of the broader repertoire of product management. The function has existed for maybe 25 years in the US and 15-18 years in India, but it’s still not that well defined — it can feel like the blind men and the elephant, where everyone is interpreting the role in their own way.

It’s very important for a product manager to map the territory — to genuinely understand why the role exists in that specific context. You can get that answer at the interview stage, by asking your own questions as much as answering theirs, through your own research once you’re in the role, or from your network. That question — why does this PM role exist here — opens up a lot.

Broadly, I’d think of it in three archetypes. First, an early-stage start-up with fewer than 20 people, where the founder is stretched and focused on fundraising, and needs someone to actually build the product. Founders generally have strong product intuition, so your job is to support them in finding product-market fit.

Second, a more mature company extending its product lines or expanding geographically — say, an India-based company moving into the Gulf or Southeast Asia. There, your job is largely to scale the business; the core “product” work has often already happened, and your role is to support that geographic or category expansion. Third, a very large public company — big tech, essentially — where depth matters, and you need to deeply understand why that particular organisation exists and what business goals you’re there to support.

You have to understand the purpose behind the role, and then let your own job description evolve — not simply take what’s written at face value. Defining the role for yourself is, in a sense, part of the job of being a product manager.

Every experienced product leader has a decision they’d make differently with today’s perspective. What’s a product decision that taught you something you’ll never forget?

I wouldn’t call it unforgettable so much as illustrative of how things that were inefficient earlier are much easier to do now — the cost of getting things wrong has come down. Take a big consumer app trying to optimise something like user onboarding or transaction flows. Earlier, running an experiment required a large team; today, a much smaller team can run many concurrent experiments across platforms, with measurement largely automated.

Earlier, one real problem was that measurement itself wasn’t very scientific, so there was constant debate about whether an experiment was actually driving business value. If I look back, some of that early experimentation was slower simply because a chunk of user research — the more “secondary” research work — wasn’t automated the way parts of it can be today. That saved time doesn’t mean the job becomes passive; it just frees you to focus more sharply on identifying real gaps rather than spending your time on data collection itself. The ability to keep a continuous read on the market — how competitors are moving, how usage patterns are shifting — is also far better today than it was even a few years ago.

We often say products are built by understanding the customer. Has curiosity about human psychology given you an edge in understanding not just what customers say they want, but what they actually do?

It’s a constant, ongoing thing, and yes, it genuinely helps — you can, to a fair degree, map what a customer’s next step is likely to be, but that depends heavily on understanding the incentives on the other side of the interaction. Where behaviour isn’t purely rational, that’s exactly where the value of understanding psychology shows up — it helps you account for the parts of a decision that a purely logical model would miss.

In an era like this, every stakeholder believes their problem deserves top priority. How do you distinguish between what’s genuinely important and what’s simply demanding attention, and connect that back to the customer?

The way I approach it is to tie every request back to the direction the company has already set — the board’s priorities cascade to the C-level, to business strategy, to a specific product area. If the board wants to focus on profitability, for instance, that gives you a lens to evaluate a request against. Generally, once you frame something in those terms, people can identify for themselves whether it’s genuinely a priority.

The second thing that helps is being transparent about cost — laying out plainly what a request will actually cost to build, rather than treating it as a free option. Once people see the real cost, they often answer their own question. The genuine challenge is that people don’t always align on how to measure that cost — someone is looking purely at revenue, someone else at a different metric — so finding a common unit everyone agrees on is not always straightforward.

The third piece is knowing when to escalate. It’s fine to ask for help when you’re genuinely stuck, but stay transparent, keep communicating, and don’t surprise people. Prioritisation is an iterative exercise, and being clear about the implications of any given trade-off — for better or worse — makes the whole process easier to manage over time.

AI is making it easier than ever to build products faster, but not necessarily easier to build products customers truly love. How do you make sure AI accelerates real customer value rather than just accelerating output?

There’s a category of work that’s simply overhead — replying to routine email threads, scheduling meetings, other administrative tasks — and AI can pick a lot of that up for you. That’s time you get back by automating the repetitive parts of the job that don’t need your personal judgement.

The real value is in what you do with that reclaimed time — it should go into understanding customer problems more deeply, and into initiatives that have a genuinely higher probability of moving the needle, rather than being spread thin. Focus matters as much as speed.

There’s a real risk here too. Because AI-assisted tooling makes it cheap to run many experiments at once, you can end up in a situation where pricing shifts in one test, the interface colour changes in another, and a feature disappears in a third — and from the customer’s point of view, the product feels inconsistent from one visit to the next.

As a product manager, you need strong guardrails to keep the experience coherent for any given customer, rather than fragmenting it into a patchwork just because the tooling now makes that easy. You want to keep a consistent, holistic view of the customer rather than treating every micro-segment as a separate experiment purely because you now can.

Do you think the best product managers of the future will be the ones with the best ideas, or the ones best at adapting those ideas as the environment shifts?

I’d say it’s really about the second part — the ability to act on an idea and adapt it as you learn from the customer. If you can adjust your strategy based on real customer response, that’s what actually drives success; if you’re not seeing that kind of positive adaptation, something earlier in the process probably isn’t working.

What I don’t think will change is the pace of relearning this job demands. Increasingly, the compounding of what you already know gets disrupted faster than it used to — you build up expertise, and then the ground shifts again before you’ve fully banked it. You have to make peace with that as part of the job. If that pace genuinely doesn’t work for you, this may not be the right industry — some other field might suit you better — but going forward, I think that’s simply the nature of the work.

As the product management domain keeps evolving, what do you think will differentiate an exceptional product manager from a good one — and how would you recommend aspiring PMs consciously build that?

A lot of what I’d say here I’ve already touched on. But if I had to isolate one thing, it’s the ability to just get started with relatively little friction — building your basic toolkit and staying genuinely engaged with what the customer needs, and then being able to translate that understanding into action.

You’re pursuing the one-year MBA programme here with several years of work experience behind you. What would you say for a programme like this, as opposed to a traditional two-year one?

Coming in with real work experience changes what you get out of a programme like this — a lot of what’s being taught lands differently, and generalised knowledge about how people and organisations behave becomes more concrete because you can map it against things you’ve actually seen. I think that makes the subject open up more for you than it might otherwise.

The other thing worth saying is that this is probably the one stretch of time where you genuinely have the liberty to explore outside your own lane — even if your background is technical or product-focused, it’s worth using this window to build a working understanding of adjacent functions like marketing, rather than only going deeper into what you already know. You’re going to work alongside those functions throughout your career, so having a baseline understanding of how they fit together is valuable well beyond this programme.

Quickfire

A myth about product management you’d like to bust?

That it’s a management role. I think it’s more of a leadership role than a management one — people sometimes over-index on the “management” part of the title.

If AI could permanently take one task off your plate, what would it be?

Following up on messages and threads — that kind of repetitive administrative work is exactly the sort of thing AI already handles well.

Complete the sentence: the best product managers don’t just build products, they …

… build businesses. One assumption that’s shifting now is just how tightly business outcomes and product success are correlated — that link is only getting stronger.

Ask any product leader what a PM’s top priorities are, and ‘customer’ comes up almost every time. That’s the biggest strength of the function, and it’s also most immune to changes in technology

Your surface area as a PM keeps expanding, which makes the role of a PM leader — giving direction and keeping PMs moving coherently — even more critical

If I had to name the single most overlooked, highest-leverage part of the job, it’s this — leading PMs, not just leading products

The cost of running an experiment is no longer the constraint — your judgement about which experiments to run is. Be careful: cheap testing can turn your product into a patchwork