Product Manager with experience across enterprise, agency, startup, and founder environment. Six years building products, leading teams, and turning user insights into business outcomes.
Along the way I became obsessed with why people do what they do.
I spent the first few years of my career thinking deeply about users long before I ever owned a roadmap. Then I lead UX and Product at an agency. Then I built a startup from scratch (learning MBA the real way).
Somewhere in that journey, I realised the part I loved most wasn't launching features. It was understanding what was happening in someone's head right before they made a decision.
At Mastry, we ran a 21-day learning challenge. We knew Day 6 was the hardest point. That's where most learners dropped off.
Instead of building a new feature, we sent a simple WhatsApp message on Day 5. The message acknowledged that tomorrow would feel difficult. Then it asked one question that reconnected learners to why they started. That message improved our Day 7 return rate more than many of the features we'd spent weeks building.
this is the kind of PM I amI think about the human moment before I think about the product solution. I ask "what is the user feeling right now?" before I ask "what should we build?"
I started my career designing products for large organisations and Fortune 500 companies. I redesigned internal tools used by hundreds of consultants, worked on large-scale digital experiences, and learned how to make decisions with imperfect information.
I learned research, UX, stakeholder management, and how to make decisions with imperfect information.
At Arabica, I led product and experience strategy and spent 19 months helping startups and businesses bring products to life. We shipped 13 products across B2B and B2C. Every project came with different users, different business models, and different constraints.
It was the fastest learning period of my career. I learned how to balance what users need, what businesses need, and what teams can realistically build.
Mastry was where everything came together. We grew to 17,000+ learners, generated ₹1.25Cr in revenue, built a team of 30+, and spent nearly two years figuring out what actually drives learning behaviour. As a founder, there was nowhere to hide. Behavioural design stopped being a framework. It became survival.
The biggest wins don't always come from the biggest features. Sometimes they come from understanding people a little better.
Spent a couple of months exploring something that felt impossible to ignore: AI.
Not just AI tools. But what happens when the cost of building drops dramatically and small teams can create things that previously required entire organisations.
Since then, I've been experimenting, building, and helping startups think through how AI fits into their products and workflows.
Part of that work involves consulting founders on AI adoption and process design. The other part involves building and breaking things myself.
AI-powered self-assessment PM Readiness tool for aspiring product managers.
Built around understanding operational fatigue for dark store managers and improving day-to-day workflows.
Driven personalisation for learning motivation and completion. Built on behavioural design principles from Mastry — currently in concept phase.
I'd love to chat. Whether that's a role, a project, a collaboration, or simply a good conversation.
Most of my career has been under titles like UX Lead, Product Lead, and Founder.
But the work itself has consistently been product work: user research, opportunity discovery, prioritisation, roadmap decisions, cross-functional collaboration, experimentation, and driving business outcomes.
The titles changed. The responsibilities didn't.
Yes.
From enterprise UX research at Accenture to 22 exit interviews that led to a redesign of Mastry's core product, user research has been a constant throughout my career.
I've learned that good research rarely gives you answers. It gives you better questions.
Yes.
I regularly use analytics, funnel analysis, cohort analysis, experimentation, and behavioural data to inform decisions.
Enough to trust data. Enough to know when not to blindly follow it.
Yes.
Every requirement document starts with a problem statement.
If I can't clearly explain what behaviour we're trying to change and why it matters, we're not ready to discuss solutions yet.
Yes.
Some of the best product decisions I've been part of happened before a single wireframe existed.
I've learned to involve engineers early, align on constraints quickly, and solve problems collaboratively instead of treating development as a handoff process.
Yes.
I've killed projects, paused initiatives, removed features, and changed direction when the evidence pointed elsewhere.
It's never comfortable. But prioritisation is often less about deciding what to build and more about deciding what not to build.