Maximizing Utility: How I think about Product Management

Product management is fundamentally about trying to please everyone and coming to terms with the fact that you cannot. Every user has legitimate needs, strong opinions about what matters, and their own version of what the product should be. The work is in synthesizing all of that into something that maximizes utility for everyone, even if no single person gets exactly what they want. Coming from an economics background, I naturally think in terms of trade-offs and equilibrium. There's always a balance to be found between competing priorities. The challenge, and honestly the fun part, is figuring out where that equilibrium is and how to get there.

My approach starts with listening. I spend a lot of time doing user interviews because that's where you actually learn what people are trying to accomplish, not just what features they think they need. Jobs to Be Done is a framework I return to often because it cuts through surface-level requests and gets at the underlying problem. I've learned that understanding users means recognizing their constraints, whether that's time pressure in a clinical setting or workflow complexity that makes even simple tasks difficult. In healthcare especially, where people are already stretched thin, I make an effort to meet users on their terms. Shadow them, watch how they actually work, figure out where the friction is. A good product should solve problems without creating extra steps.

Once you understand what users need, the hard part begins: prioritizing and refining and prioritizing and refining. You cannot build everything at once, and even if you could, some features aren’t worth building. On the flip side, I've pushed back on premature launches because shipping something half-baked just forces users to adapt to a subpar experience. Better to get the core right first, then iterate based on what actually moves the needle.

Last, but definitely not least: data. As I’ve noted above, I rely heavily on user interviews and qualitative feedback and that’s because numbers do not always tell the full story. There's a great anecdote Jeff Bezos tells about calling Amazon Support during a business review to prove that the reported wait times were wrong. However, without the numbers to back up the story all you’re left with is anecdotal evidence and that doesn’t always go hand in hand with a strong business case. Data will always be imperfect, so the more you have to decision on, the better your outcome can be. The goal is always to maximize utility, to find the version of the product that works best for the most people, knowing full well that perfect is impossible.