Start with the user
Understand the person before the problem.
Who are they? What are they trying to accomplish? What gets in their way? I want to understand the job before I decide what the product should do.
About
I tend to get curious about things.
Then I can't quite leave them alone.
Why does this work this way?
What happens if we change this?
Is this actually the problem?
And occasionally: surely there is a better way to build this.
Most of my work sits somewhere between technology, people, and a slightly unreasonable number of questions. I like taking complicated systems apart, understanding what is actually happening underneath, and putting them back together in a way that makes sense.
I started out writing software, moved into product, and somehow ended up spending my days thinking about developer experience, how products behave at scale, AI, agents, workflows and so many other things.
Outside work, I'm usually learning something new, planning my next trip, taking too many photos, or going down a YouTube rabbit hole in the middle of the night.
I'm interested in the things that make ordinary things surprisingly interesting.
How I work
Six habits I keep bringing to the job, whatever the job turns out to be.
Go after the friction
Make the complicated feel effortless.
The best product improvements are often hiding in the awkward parts: the extra step, confusing handoff, or workaround users have quietly learned to live with.
Cut the question before you build
A smaller question usually makes a better product.
I like turning "How do we fix this?" into something specific enough to solve, test, and learn from.
Make impact part of the product
Shipping is an output. Impact is the point.
I want to know what actually changed: adoption, revenue, engagement, time saved, retention, or whatever outcome mattered to the business and the user.
Build for the 80%, then earn the 20%
Solve the core problem first. Expand from there.
There will always be another edge case, request, or refinement. I'd rather make the core experience genuinely useful for most people, learn from it, and incrementally work outward. This is a prioritization heuristic, not a literal 80/20 rule.
Prove it. Then keep score.
Evidence beats a convincing demo.
I like testing the thing, watching the metric, listening to users, and finding out what actually changed. If the number isn't good enough yet, the work isn't finished.
The journey
Robots, then software, then products.
NOW · 2026
Building and experimenting with AI
Currently somewhere between building agents, teaching them to remember, and making workflows do more than I thought they could.
SEP 2024 · SEP 2026
Product Manager 2 · Google
Went from building products to thinking about the systems underneath them. And parallely learned that 60+ stakeholders is, technically, a distributed system.
See the case studyFEB 2023 · AUG 2024
Product Manager · HighLevel
Learned to think in systems, not just features, and got comfortable making decisions when the numbers got big.
JUN 2022 · FEB 2023
Product Manager · Ula
My first real lesson in product: good ideas still need a reason to exist.
JUN 2021 · JUN 2022
PGP Management · Indian School of Business
An engineer learns to speak business. The engineer remains unconvinced by jargon.
JAN 2018 · JUN 2021
Software Engineer · JPMorgan
Learned how complex systems behave, and how quickly tiny things can break them.
2014 · 2018
B.E. Electronics and Communication Engineering · Thapar Institute of Engineering and Technology
Started with circuits, ended up slightly more interested in everything around them.