About

How I got here

I studied Computer Science at VIT, which was 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 worked on after making that move was 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.

I left Zuper in July 2026. In August I joined VoiceStack as an Associate Product Manager, building AI-powered phone systems for dental practices. Which is a longer way of saying I went from contractors to clinics, and from dispatch to the front desk.

The move looks like a bigger jump than it is. Both are vertical software sold to businesses where the software isn't the point. The work is. Both have an operational moment that quietly decides whether the business makes money: in field service it's dispatch, in dental it's the phone. And both have the same uncomfortable truth underneath, which is that the person you're building for is already overloaded and does not want another system to learn.

What's genuinely new is the domain. Healthcare has compliance surfaces field service never had, callers who are in pain and have no patience for a menu tree, and integrations into practice management systems that have been running since before I was writing code. I'm early enough that the honest position is that I know the shape of the problem and very little else yet.

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

For a long time this section said I was building toward AI product work. That's no longer the right tense. VoiceStack is a voice AI company, and the work is the thing itself now rather than the thing I'm aiming at.

The preparation wasn't accidental. The voice agent running on this site is a real system I designed and built: RAG architecture, audience detection routing, STT tuning, latency decisions. I built it before I had any professional reason to, and the problems I hit are the same ones that decide whether production voice agents work: latency you feel rather than measure, speech recognition failing on proper nouns, knowing when the agent should stop talking and get a human. Building it is why I had opinions about the domain before I had any experience in it.

What I want from the next few years is narrower than it used to be. I want to get properly deep on one hard domain. Deep enough that my instincts are worth something rather than borrowed. That took two years in field service. I expect healthcare to take at least as long, and I'd rather be honest about that than arrive claiming expertise I haven't earned.

The through-line stays the same: 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.