About

I think about products the way a good translator thinks about language — the job isn't to convert words, it's to convert meaning.

Most product problems arrive as noise: a contractor asking for a tweak, an ops team raising an exception, a customer describing a workaround they've lived with for two years. The surface request is rarely the real problem. Getting to the real problem requires sitting close enough to the work to see what's actually breaking.

That's where I've spent the last two years.

How I got here

I studied Computer Science at VIT — enough to understand how systems are built, not just described. Then I joined Zuper as an implementation engineer, which meant I spent almost a year configuring the product for real customers before I ever had a product title.

That sequence wasn't accidental in hindsight. Implementation teaches you things discovery calls don't. You see where the configuration breaks. You watch which workflows get abandoned. You learn that the gap between how a product was designed and how it's actually used is where most of the real work lives.

When I moved into product, I already knew where the bodies were buried.

The most significant thing I've worked on since making that move is the roofing vertical — building it from zero, from no architecture to a cloneable system that every roofing customer now onboards into. That work taught me that the hardest part of building something new isn't the configuration. It's knowing what you don't know yet — and designing the process so that the unknowns surface before they become architectural mistakes.

How I think

A few things shape how I approach product problems — not as hobbies, but as cognitive tools.

Moral complexity from fiction

I grew up reading Harry Potter — not for the magic, but for the architecture of a world with real internal logic, characters who contain contradictions, and problems that don't resolve cleanly into good and evil. That's useful for product work. Most hard decisions aren't between right and wrong. They're between two reasonable positions with different tradeoffs.

Pattern recognition from thrillers

Dan Brown taught me to follow threads. Every customer complaint is a data point. The interesting work is finding what connects them — the pattern underneath the noise that points toward the actual system problem.

Formation thinking from football

FC Barcelona taught me that the best teams don't always have the most resources. They have the clearest identity. Messi left. Financial chaos followed. Real Madrid and others could simply buy their way out of any problem. Barca couldn't. And yet — players still chose them, took pay cuts to be there, and a group of young kids alongside Lewandowski under Flick delivered anyway. That's not talent. That's system, belief, and a way of playing that people want to be part of. Early product work at a Series A or B company feels exactly like this. You're not the one with the biggest budget or the most engineers. You win by knowing exactly what you're building and why — and by having people who believe in that enough to give more than the resources require.^*

Restraint as a product principle

The mental model I keep returning to: just because I can doesn't mean I should. In product, this means the best decision is often the one that removes a feature, narrows the scope, or says no to the reasonable request that would quietly break three other things.

One other thing worth mentioning — I have a habit of hiding easter eggs in internal tools I build. Admin panels that only reveal themselves after a specific sequence of clicks. Riddles instead of login screens. Dan Brown-style entrances to low-stakes internal dashboards. It's not secure. It's not scalable. But for a small team tool built on a weekend, it makes the thing feel alive — and reminds me that good products have personality, not just function.

Where I'm going

I'm currently building toward product roles at Series A or B companies where I can work directly on product decisions, move between customer problems and product systems, and be close enough to the work to actually shape it.

My long-term goal is to become an AI-first product manager. Not in the sense of bolting AI onto existing workflows, but in the sense of rethinking what product management looks like when intelligence is built into the core of a product. What interests me most is how AI changes the fundamental questions of product work: what to build, how to prioritize, what "good" even means when the system can learn and adapt.

I'm particularly interested in what AI means for products where the stakes are real and the users don't have patience for friction. The design constraints are harder. The margin for abstraction is smaller. The solutions have to actually work. That's the kind of product problem I want to spend the next decade on.