The Best Healthcare Products Are Built in the Middle
Competing Truths. Shared Purpose.
Healthcare products rarely fail because one stakeholder lacks expertise. More often, they struggle because every stakeholder sees a different—and legitimate—version of the problem.
A clinician may see a workflow that interferes with care. An operations leader may see inconsistency and avoidable effort. A business leader may see cost, customer value, and strategic opportunity. An engineer may see architectural constraints, technical debt, and scalability. A compliance or policy team may see risk that cannot simply be designed away.
Product leadership lives in the middle of those perspectives.
The work is not merely collecting requirements from each group and finding a compromise. It is developing enough understanding of the problem to recognize where those perspectives reinforce one another, where they conflict, and which tradeoffs matter most to the people who will ultimately experience the product.
That distinction is especially important in healthcare, where optimizing one dimension can easily create consequences somewhere else.
A workflow optimized entirely for speed may remove a moment of deliberation that protects against error. A highly configurable system may accommodate every stakeholder request while becoming nearly impossible for users to navigate. An automation intended to reduce administrative burden may obscure information a clinician needs to exercise judgment. A sophisticated AI model may produce an accurate prediction without providing enough context for someone to decide what to do with it.
There is rarely one stakeholder who can see all of those consequences independently.
Translation Is More Than Communication
Cross-functional product leadership is sometimes described as the ability to “speak both business and technology.” In healthcare, the translation problem is considerably broader.
Clinical language has to become product behavior. Business strategy has to become measurable capabilities. Operational realities have to inform workflow design. Data definitions have to become information users can trust. Regulatory and policy constraints have to become appropriate controls. Technical architecture has to support not only today's requirements but the ways the product may need to evolve.
And each translation can lose something important. That is why requirements gathering alone is insufficient. A stakeholder can accurately describe what they want and still propose the wrong solution. The more useful questions are often underneath the request: What are you trying to accomplish? What decision are you making? What happens if the system gets this wrong? What information do you need to trust the result? Where is consistency essential, and where does professional judgment need room to operate?
Those questions move the conversation from requested features to the actual problem.
Sometimes Good UX Should Add Friction
The conventional goal of user experience design is often to remove friction. In healthcare, that principle needs qualification.
Some friction is waste: duplicate documentation, unnecessary navigation, repetitive data entry, searching across disconnected systems, or forcing users to reconstruct information the organization already possesses.
That friction should be designed out.
But other friction can be protective.
A consequential action may deserve an explicit confirmation. An unusual result may need to interrupt an otherwise routine workflow. A high-risk decision may require additional context before proceeding. Automation may appropriately accelerate routine work while deliberately slowing the user when circumstances fall outside expected parameters.
This is sometimes described as defensive UX: designing not only for the ideal workflow, but also for predictable mistakes, incomplete information, unusual circumstances, and the consequences of getting a decision wrong.
That matters enormously in payer environments such as Care Management and Utilization Management. Efficiency matters, but so do clinical judgment, appropriate review, regulatory obligations, consistency, and the consequences decisions may have for members.
The product question therefore isn't always:
How do we make this faster?
Sometimes it is:
Where should this be effortless—and where should the product intentionally make someone stop and think?
That decision cannot be made by design, clinical operations, technology, or business leadership in isolation. It belongs in the middle.
AI Makes the Middle Even More Important
AI intensifies the same challenge.
A model can surface risk, summarize information, detect anomalies, recommend next steps, or prioritize work. But a prediction alone is rarely the complete product.
A care manager who sees that a member is “high risk” still needs to understand what information matters and what action may be appropriate. An executive looking at an AI-generated insight needs enough context to distinguish a meaningful signal from an unusual but explainable data pattern. A clinical reviewer cannot responsibly substitute an opaque recommendation for the professional judgment expected of the role.
This is why I view AI as a capability within a product, not the product itself.
The product includes the data, definitions, workflow, explanation, user experience, governance, escalation path, and human decision surrounding the model.
That also changes the product leader's questions.
Not simply:
Can the model predict this?
But:
Who will use the prediction? What decision will it influence? What evidence or explanation will they need? What happens when confidence is low? How will users challenge an incorrect result? Where should human judgment remain explicit? How will we know whether the capability is actually improving the outcome?
Those questions become particularly important in healthcare because an opaque system can do more than frustrate a user. It can influence how limited resources are prioritized, how clinical information is interpreted, how providers interact with health plans, and how members experience access to care.
The goal should not be to automate judgment out of the system. It should be to give people better information with which to exercise it.
Alignment Is a Product Capability
The strongest healthcare products are therefore not simply the result of good technology or good clinical strategy. They emerge when teams create a shared understanding of the problem—and preserve the important differences among the people solving it.
Alignment does not mean everyone sees the problem identically.
A clinician should bring a different perspective than an engineer. An engineer should identify risks an operations leader may never encounter. Business leaders should challenge teams to demonstrate value. Product leaders should not erase those differences; they should make them useful.
That requires curiosity, enough domain depth to ask meaningful questions, and enough humility to know when someone else's expertise should change the direction of the product.
It also requires recognizing that some of the most important product decisions live in uncomfortable spaces between seemingly desirable goals:
Speed and deliberation.
Automation and judgment.
Standardization and flexibility.
Innovation and trust.
Immediate delivery and long-term scalability.
Business value and human impact.
Those tensions are not obstacles to product work. They are the product work.
Healthcare will continue to introduce more sophisticated technology, more integrated data, and increasingly capable AI. But technology alone will not determine whether those products improve healthcare.
The harder work will remain in the middle: understanding the people, decisions, incentives, constraints, risks, and consequences surrounding the technology—and helping experts with very different perspectives build something none of them could have designed as effectively alone.
Great healthcare product leadership isn't about having all the answers. It's about creating the conditions in which the right questions are asked, competing truths are understood, and diverse expertise becomes a product people can trust.
