Dhiraj Sharma
Product Lead specialising in retail advertising automation, PPC tooling, and e-commerce SaaS. Based in Hyderabad, India.
I studied Computer Science Engineering — not because I wanted to build software, but because I was fascinated by what software could do. Every industry, every business problem, every inefficiency in how people work: somewhere in there was a computer science application waiting to make it better. I was always more interested in the application than the architecture.
That instinct led me to an internship in customer success at an AdTech SaaS company at the end of my third year. Working directly with digital advertisers — watching how creatively they'd adapt tools built for one purpose to solve entirely different problems — opened up a way of thinking I hadn't encountered before. I became genuinely good at finding solutions for customer use cases using what already existed. That led to helping advertisers grow, scale, and get profitable results for their own clients.
When the opportunity came to move into product — starting with the Shopping Ads side and helping engineering with process and execution — I took it and never looked back.
Since then I've owned product domains spanning Google Shopping, Performance Max, Microsoft Ads, Amazon Ads, feed optimisation, campaign automation, and reporting — all with the same goal: solve real business problems using technology, in ways that scale from a small e-commerce advertiser to an enterprise moving millions of products.
Lead with context, not control
When an engineer, designer, or junior PM pushes back or brings a different perspective, my first move is to understand the reason behind it — not defend my original position. As the person making the call, I owe it to the decision to stress-test my own understanding before arriving at a conclusion. Sometimes a five-minute decision takes thirty. But two people walk out of that conversation with a better grasp of the problem than either had going in.
"It is very important to lead with context and not with control."
I care deeply about information hierarchy and guided paths through complex products. In a world where someone will give your tool a very short window to demonstrate value, the user needs to see what the product does for them on first glance — and get where they need to go without getting lost. Complex use cases need clear guided paths, not a collection of random capabilities thrown into a UI.
Tunnel vision is one of the most common failure modes I watch for — in myself and in teams. When everyone's judgment gets compromised by being too close to a problem, someone needs to step back and see it clearly. That's a core part of how I see the PM role.
Start with the workflow, not the feature
Before deciding what to build, I map how the user actually does the work today — every step, every tool, every point of friction. The right feature only becomes obvious once the workflow is understood.
Skipping this step is how you build the wrong thing efficiently.
Complexity belongs in the product, not on the user
If a domain is technically complex, that's a product design problem — not a reason to expose complexity to the user. The job is to absorb it: translate machine errors into plain language, reduce what's visible at any one time, guide rather than inform.
A product that requires expertise to use is an unfinished product.
Fix the foundation before you differentiate
It's tempting to jump to the interesting, differentiated work. But features built on broken foundations don't stick — and they create debt that compounds. Get the basics right first.
Differentiation on broken ground just adds to the confusion.
Reliable beats clever
A system that works predictably at scale is more valuable than an elegant solution that breaks under load or edge cases. I consistently prefer robust, maintainable approaches — especially in infrastructure and anything an enterprise account depends on.
Clever is impressive once. Reliable is valuable every day.
Constraints sharpen decisions
Some of my best product decisions came from having no designer, a small engineering team, or a hard deadline — not despite those constraints. Constraints force clarity about what actually matters.
The question isn't "what can we build?" — it's "what should we build with what we have?"
Measure what actually changed for the user
Revenue and retention matter — but they're lagging signals. The leading signal I care most about is whether the user's actual experience changed: how long something takes, how many steps it requires, how often they need support.
If hours became minutes, the product worked. If the tickets stopped, something real was fixed.
Travelling
Genuinely passionate about experiencing different cultures and ways of life — in India and abroad. Every chance to travel is a chance to see the world from a perspective that couldn't have been imagined otherwise.
Rookie musician
Learning more, but honest about where the ceiling is. The goal isn't to be a professional — it's to enjoy it. That's enough.
Hyderabad, India
Senior PM roles, product leadership, and advisory work in AdTech or retail media