Why Healthcare Is Hard to Build For (And Why That's the Point)

We were adopting a new login workflow for a department. The IT team had mapped it out, tested it, and was confident it solved the problem. It worked in every environment they ran it through.

Then we went to roll it out.

The actual workflow in that department didn't match what anyone had documented. The way staff moved between rooms, shared workstations, and handed off between shifts meant the new login process added time at exactly the moments they could least afford it. Nobody had asked them. Nobody had watched them work. The assumption was that the workflow on paper was the workflow in practice.

It wasn't. It rarely is.

That's healthcare. You can build something right and still get it wrong.

The Problems Are Different Here

Every industry has product challenges. Healthcare has a specific set that don't exist anywhere else, and they compound each other in ways that take time to fully appreciate.

Your users cannot opt out. A nurse using your EHR doesn't have the option to switch to a competitor because the interface is cluttered. A pharmacist verifying orders at 2am doesn't get to choose a different tool because yours is slow. The people using your software are captive. That creates a very different accountability than consumer products, where bad UX just means users leave.

The buyer and the user are almost never the same person. A hospital system negotiates a contract with an EHR vendor. The physicians who will actually use the system for the next decade often had no meaningful input into that decision. This creates a product dynamic where the customer you're selling to and the customer you're building for have completely different priorities, and your job is to serve both without losing either.

Resistance is not laziness. When clinicians push back on a new workflow, it is tempting to frame it as change resistance. Sometimes it is. More often it is something more specific: they have seen a version of this before, it created problems, and nobody fixed it. Clinical staff have long memories for the times technology made their jobs harder or put a patient at risk. That skepticism is earned. Building through it requires understanding where it comes from.

Alert fatigue is a product failure mode that doesn't exist in most industries. If your software sends too many notifications in a consumer app, users get annoyed and turn off notifications. In healthcare, if your clinical decision support fires too often on low-value alerts, clinicians habituate to ignoring all of them. Including the ones that matter. The downstream consequence of over-alerting isn't user annoyance. It's a patient safety event waiting to happen.

The regulatory surface area is enormous and uneven. HIPAA gets mentioned in every healthcare product conversation. ONC certification requirements, state pharmacy regulations, Joint Commission standards, payer rules — these shape what you can build, how fast you can build it, and who can access what. A feature that works fine in one state requires a complete rethink in another. The compliance layer isn't a checklist you hand off to legal. It's a core constraint on every product decision.

What This Actually Requires

Most of this isn't solvable with better engineering.

The login workflow that failed wasn't a bad build. It was a misunderstanding of the environment it was being dropped into. No amount of technical sophistication would have caught that without someone who understood what that department was actually doing during shift transitions.

This is where clinical background earns its keep in health IT PM work. Not because clinicians are automatically good product managers — they're not, any more than being a good nurse makes someone automatically good at anything else. But because the specific failure modes in healthcare software are rooted in clinical workflow, and the only way to anticipate them is to understand what that workflow actually looks like from the inside.

What time does the overnight team start? What does handoff look like on a med-surg unit? What happens to the order queue when the attending is unreachable and the covering physician doesn't know the patient? These aren't edge cases. They're the conditions your software has to work in every night.

A product manager who has spent time in those environments doesn't need those conditions explained. They're already building for them.

The Difficulty Is the Point

Healthcare is not accidentally hard to build for. It is hard to build for because the stakes are real, the users are stressed, the workflows are complex, and the consequences of getting it wrong include patient harm. Those constraints aren't going away. They're not problems to be optimized out of existence.

They're the job.

The difficulty is what makes clinical knowledge genuinely valuable in this field, not as a credential to list on a resume but as an active input into product decisions. It's what separates a PM who can build software and a PM who can build software that works in a hospital at 3am when the system is under load and the charge nurse is dealing with four things at once.

If you're coming from clinical practice into health IT, this is the thing worth holding onto. The environment you came from is the one you're now building for. The complexity you lived through is the complexity you're now responsible for managing in a product.

That's not a small thing. Most people building healthcare software have never set foot on the floor.