Healthcare Product Leadership: Building Products That Belong in Care

This is my front door to product leadership in healthcare, and I want to start with a confession: the discipline is not special. Discovery, prioritization, empowered teams, honest metrics, these are the same fundamentals good product people use everywhere. What is different is the terrain. In healthcare the person who uses your product is rarely the person who buys it, a wrong call can reach a patient, and regulation is not a footnote. So the fundamentals hold, but every one of them bends. This page is about how they bend, and how I lead through it after a decade building healthcare products.

Here is the through-line for everything below. Lead for outcomes that reach a patient, not output that fills a roadmap. The roadmap, the sprint, the launch, none of them are the point. The point is whether a clinician's day got easier or a patient got care faster, proven, not assumed. Hold onto that and the rest of product leadership in healthcare falls into place.

What makes it different

Every product-leadership instinct you brought from consumer or general software is still useful in healthcare, and every one needs an adjustment. I keep a short mental table of the differences, because they explain most of the mistakes I see. In general software the user is usually the buyer; in healthcare an administrator often buys what a clinician has to use. In general software you can ship and iterate fast; in healthcare a mistake can harm someone, so the bar to ship is higher. In general software regulation is background; in healthcare it shapes the product. And the sales cycle is long, so feedback loops stretch. None of this means the discipline changes. It means the defaults do.

The adjustment I make most often is on the buyer and user split. When an administrator buys and a clinician uses, you have two customers with different definitions of success, and a product that delights the buyer while burdening the clinician will be bought, deployed, and quietly abandoned. I design for the user's day first, then make the buyer's case in their language. Ignore either one and you lose.

Discovery before commitment

The most expensive thing a healthcare product team can do is commit to building before it has tested whether the idea is worth building, so I run discovery first, always. Marty Cagan frames product risk as four questions you have to answer before you commit: will people value it, can they use it, can we build it, and does it work for the business. In healthcare I add a fifth that is not optional, clinical and regulatory risk: is it safe, and is it allowed. Discovery is how you answer these cheaply, with prototypes and evidence, before you spend a year building the wrong thing.

The discipline is not to eliminate risk, it is to attack the biggest risk first. If value is the open question, put a rough prototype in front of real clinicians before you engineer anything. If clinical safety is the open question, pressure-test it before you fall in love with the idea. Cheap experiments on the scariest risk, in order, is what discovery actually is. Teams that skip it do not save time, they just find out later and at higher cost.

Prioritize by outcome, not output

A full roadmap is not a sign of a healthy product, it is often a sign that nobody is choosing, and choosing is the job. The failure mode I fight hardest is the roadmap measured in features shipped. Output feels like progress and is easy to count, which is exactly why it is dangerous. I prioritize by outcome: the change a piece of work creates for a patient, a clinician, or the business, weighed against the effort to get there. The best work is high outcome and honest about effort. The trap is the pile of low-outcome features that keep everyone busy and move nothing.

Saying no is the part nobody trains you for. Every stakeholder has a feature they want, and a roadmap that says yes to all of them is a roadmap with no strategy. I would rather ship three things that move an outcome than thirty that keep everyone placated. In healthcare the cost of the wrong yes is higher, because engineering time spent on low-outcome features is time not spent on the thing that actually helps a patient.

Empowered teams, with a clinical partner

The operating model that works in healthcare is an empowered team that owns an outcome, with a clinical partner inside it from the start, not a compliance gate bolted on at the end. Two ideas have to hold together. First, empowered teams: give a team a problem and the ownership to solve it, not a feature list to build. Second, clinical partnership: put clinical and compliance expertise inside discovery, so safety and regulation shape the product early, when it is cheap to change, rather than blocking it late. The anti-pattern is the team that builds in isolation and meets compliance at the finish line. The lanes below show how I split it: product owns the outcome, engineering and design build, and the clinical partner is present throughout.

Measure outcomes that matter

The gap between what healthcare organizations deploy and what they actually validate is the clearest sign that we measure activity instead of outcomes. A KLAS and UPMC study on AI governance put a number on this that I keep coming back to: 93 percent of health systems reported deploying third-party AI, while only 44 percent had a dedicated environment to test and validate those tools. Deploying is an output. Validating is the beginning of an outcome. That gap is the whole problem in miniature. Good product metrics track whether the thing actually worked, honestly defined and adjusted for reality, not how many tools you shipped.

The same study found the usual culprits underneath: manual workarounds, spreadsheets, and inconsistent definitions across teams. That is not a metrics problem on the surface, it is a data problem underneath, which is why product metrics and the data foundation are the same fight. You cannot measure outcomes honestly on data nobody trusts. If you take one metrics lesson from me, it is this: count what changed for the patient, not what shipped from the team.

How the four areas fit together

This cluster is organized around four sub-topics, and they are not a list, they are a loop that a healthy product practice runs continuously. Discovery and validation is how you decide what is worth building. Roadmapping and prioritization is how you choose what to build now. Teams and operating model is how you organize to build it well. And metrics and outcomes is how you learn whether it worked, which feeds the next round of discovery. It is a loop, not a line. And in the agent era, the same loop applies to a new question I have written about separately: what to build on a billion-user platform, and what to own yourself.

Score your product practice

Before the next planning cycle, it is worth an honest look at whether your product practice is built for outcomes or for output. Answer these five as they are, not as you wish they were.

My take

After a decade of this, my belief is simple. In healthcare, product leadership is not about shipping more, it is about being honest, relentlessly, about whether the thing you shipped made care better. The regulation, the clinical stakes, the slow feedback loops, they are not obstacles to good product work, they are the reason it matters. Lead for the outcome that reaches a patient. Everything else is output.

Start wherever your practice is weakest: the discovery you skip, the roadmap you cannot say no to, the team that meets compliance too late, or the metric that counts output. That is the highest-value place to begin, and it is where the rest of this cluster goes deeper.