About

I treat every product problem like a system. Before jumping to solutions, I ask: what's the actual constraint here? Is it a data problem, a workflow problem, or an incentive problem? I try to distinguish between symptoms and causes, and between what users say and what they actually do.

I've built models, run pipelines, and shipped product features — which means I have a grounded sense of what's actually hard to build versus what just sounds hard in a planning meeting. That grounding changes how I scope and how I prioritize.

I'm most useful in the early and middle stages of product development — defining the problem, scoping the first version, and making the tradeoffs explicit. I communicate in writing first. I prefer clear PRDs, sharp problem statements, and decision docs over long meetings.

I'm comfortable being wrong and changing my view when data or user feedback says to. The goal is to be right eventually, not to win the argument. I've had to make the call to cut scope when it was unpopular, and hold it.

I've worked across student-run product organizations, enterprise consulting, and solo projects — and had brief exposure to how Microsoft thinks about product and systems at scale. That range has been more useful than a single deep track would have been.

Honestly? Clarity. Products that are clear about what they do. Teams that are clear about what they're building and why. Communication that doesn't hide behind jargon. That's rarer than it sounds.

I'm interested in AI infrastructure, marketplace dynamics, data tooling, and healthcare technology — spaces where the underlying complexity is real and the product decisions actually matter. Where getting it wrong has visible consequences.