Here's the structural problem with digital health product development: the buyer and the end user are almost never the same person. A health system executive approves the purchase. A nurse, a care coordinator, a patient — someone with no vote in the procurement decision — has to use it every day for the next five to ten years.
This isn't unique to healthcare. Enterprise software has always had this tension. But healthcare amplifies it in ways that matter, because the stakes of getting it wrong aren't just inefficiency and poor adoption — they're care quality, clinician burnout, and patient outcomes.
What gets built when you optimize for the buyer
When the buyer is a health system, you build for what health systems care about: compliance, reporting, integration with existing infrastructure, cost reduction, risk mitigation. These are real concerns. They're worth solving. But they are organizational concerns, not human concerns.
The end user — the clinician, the care worker, the patient — has a completely different set of problems. They need things to be fast, because they have twelve other things to do. They need information surfaced in context, not buried in a dashboard. They need the product to fit into the way they actually work, not force a new workflow onto people who are already stretched.
When you optimize for the buyer, you tend to build the first list. The second list — the end-user list — becomes a phase two that never quite arrives.
"Successful products evoke delight. They make hard things easy. The organizational benefit is the byproduct of making hard things easy for the person who actually uses it."
Why EHRs are still terrible
This is why. The major EHR vendors won their contracts by satisfying health system requirements — interoperability, compliance, billing integration. They did not win them by making clinicians' lives better. And once the contract is signed and the switching cost is enormous, there's very little market pressure to fix the user experience.
The result is clinicians spending a third of their time on documentation that a well-designed system could handle in a fraction of that. Not because the technology doesn't exist, but because nobody was optimizing for the clinician when the original product decisions were made.
The fix isn't complicated — it's just hard
Put the end user in the center of the product development process before you build anything. Not as a stakeholder to consult, but as the person whose problem you are primarily trying to solve. Then ask whether the organizational benefit follows from solving their problem — because in most cases, it does.
Faster, less frustrating workflows for care workers translate directly to throughput, retention, and quality metrics that health systems care about. A patient portal that's actually easy to use drives the engagement numbers that appear in value-based care models. The organizational benefit is real. But you don't get it by building for the organization. You get it by building for the person.
The procurement process needs to change too — health systems need to evaluate products on clinician and patient experience metrics, not just feature checklists. That's a slower cultural shift. But individual product teams don't have to wait for it. They can start by asking the right question: who actually has to live with this product every day, and what does their life need to look like?
