Why your product satisfied the committee and failed the user... and why that was decided before design started
The patient was in her third trimester and couldn't sleep. Komal Bajaj had just finished training in evidence-based sleep interventions. She worked through the recommendations... everything the clinical literature had prepared her to offer. The patient let her finish. Then said something that stopped everything.
"I don't have a bed."
Every recommendation assumed the patient had one. The training was correct. The conditions it assumed weren't present. And there was nothing in the system that could surface that gap before Komal had worked through all of it.
Komal Bajaj is a physician and health system innovator. She told this story at a Health2047 webinar on women's health this past June, and she framed it as a lesson in clinical humility — the importance of asking before you prescribe. That framing is right. But I kept coming back to something else.
The material reality the protocol couldn't see — a patient whose life didn't match the conditions the system assumed — is the same category of gap that gets built into healthcare technology before it's ever deployed. Not because product teams don't care. Because the people who write the requirements are not the people who know what those patients' lives actually look like. The gap doesn't start at the point of care. It starts earlier, in the specification of the products clinicians like Komal use every day — built by people who never thought to ask whether the patient had a bed.
The literature prepared her for a different patient.
Here's what makes that harder than it sounds. The questions you'd need to ask aren't universal. A safety-net hospital in South Chicago is serving a different patient reality than a community hospital in rural Montana. The material conditions that shape whether a recommendation is actually usable... they change depending on where the institution is, who it serves, what the surrounding community looks like. The right questions are different in each of those contexts.
The specification process doesn't just fail to ask about beds. It doesn't ask the questions that would vary by location, by population, by the actual composition of who walks through that particular door. It builds one set of assumptions and deploys them everywhere.
The people who approved it will never have to use it.
What I find interesting about this pattern is how structural it is. It isn't really about empathy, or research, or even intent.
In regulated B2B industries, the person who signs the contract is almost never the person who uses what it buys. A health system purchases a patient engagement platform. The committee that approves it — finance, IT, legal, clinical leadership — evaluates integration requirements, compliance documentation, reporting, total cost of ownership. All legitimate criteria. All completely disconnected from what it feels like to use the product on a Tuesday night when a patient is frightened and doesn't know what button to press.
Think about what actually happens in that room. Someone runs the dashboard demo. The clinical informaticist asks about HL7 integration. Legal reviews the BAA language. IT wants to know where the data lives. Finance wants to understand whether it hits opex or capex. These are exactly the right questions for the people asking them. Not one of them is: what does a patient with limited English proficiency do when the portal asks her to upload a document she doesn't have? What happens when someone without reliable internet tries to complete the intake flow on a phone with 2% battery? Nobody asked. It wasn't on the evaluation rubric.
They were not imagining patients. They were imagining a system that handled patients.
The people who will use it every day... the scheduling coordinator, the triage nurse, the patient on a cracked phone at 11pm... weren't in the room where the specification was written. They may have appeared in a focus group. They were not the design target. The product was built for the conditions the buyer could imagine.
This isn't careless. It's structural. The committee has budget authority. The committee has approval authority. And so the product gets built for the committee.
The person with the highest stakes in the outcome is almost always the person consulted last, if at all.
I came to this from outside healthtech. Many years in financial services and agriculture, watching the same failure mode from different angles. That distance is actually useful here. Few people inside a vertical are well-positioned to say: I've seen this movie before, I've watched the same failure mode play out in two other regulated industries. I am. And the warning signs I know to look for first are already showing up.
It passed every review. Three quarters of users abandoned it.
In 2016, Capital One's small business banking enrollment flow had a 26% completion rate. Twenty-six percent. Nearly three quarters of the people who started the application didn't finish it.
The flow was defensible. Every field that needed to be there was there. Reviewed and approved by everyone whose approval it required. It satisfied the compliance function's requirements completely.
It was not built for a small business owner at a kitchen table at night, possibly on a phone, probably managing three other things, trying to figure out what "beneficial owner" means and whether they have the document it's asking for. It's easy with B2B software to forget that the software you're making or service you're providing is only one or two percent of the activities that the business owner is doing in a day. It's also really easy to forget that they started their business to provide a service, not to sit in business software.
When we redesigned it around who was actually filling it out and under what conditions, completion rose to 92% qualified applications — a different measure than completion rate, but one that reflected the same underlying shift. The purpose didn't change. The legal requirements didn't change. What changed was whose reality the design was built around.
The buyer had different requirements than the user. The product satisfied the buyer. It failed the user. And nobody asked the user much until the completion rate told the story the specification had missed.
That gap has a name. It isn't bad design. It isn't insufficient research. It's a structural condition — created at the specification stage, before a designer sits down. You can't research your way out of a specification written for the wrong person. In regulated industries, the stage gate doesn't move. Missing it isn't a design problem — it's a funding problem, a trust problem, a market problem. The deadline is the metronome everything else runs against.
When patients say it lacks empathy, they mean it was built for someone else.
A recent PolyAI survey of 1,000 patients found that 23% cited lack of empathy as their top concern about voice AI in healthcare. That number usually gets read as a comment on AI's emotional range. A maturity gap. Something that will improve.
I don't think that's what patients are describing.
When patients say a product lacks empathy, they aren't asking for a warmer voice or a longer pause before the next prompt. They're describing the experience of a product that was clearly built for someone else — one that doesn't know where they are, what they're afraid of, or what kind of moment they're actually in. It assumes they have time, bandwidth, and a stable environment in which to complete a transaction. The product was optimized for metrics measured in a controlled test — not for the human on the other end of it at a moment that actually matters.
Twenty-three percent of patients are telling us the product didn't feel like it was designed for their actual moment... the fear, the urgency, the particular disorientation of navigating a healthcare system while also managing a health problem. The AI doesn't sound like it knows what it is to be that person, right now, with those stakes.
A product built around that moment would have been specified differently from the start. The empathy concern isn't a technology problem. It's a specification problem. And the specification process did not include that patient in any meaningful way before the product was built.
This is what Komal's story points toward, even though she was describing a clinical encounter. The system that trained her had no mechanism for knowing this patient didn't have a bed. Not because the training was wrong. Because the people who built it imagined a patient, and that patient had a bed — and that bed was the same bed, in the same imagined home, regardless of which hospital Komal was working in or who was sitting across from her.
Change management becomes a convenient deflection when nobody wants to reopen the specification.
The standard response to all of this is to call it a change management problem. Product is sound. What's needed is better training, cleaner communication, stronger stakeholder alignment. Get everyone on board and adoption will follow.
This is the misdiagnosis. And it's remarkably persistent.
Training doesn't close the gap between what a procurement committee imagined and what a patient at home actually needs. Communication doesn't retroactively put the scheduling coordinator's reality into a specification that locked before she was consulted. Stakeholder engagement at rollout can't touch the structural problem — which was created months or years earlier, when the product was being defined and the wrong people were in the room.
Closing this gap requires something more uncomfortable than a better implementation plan. It means asking the specification questions earlier, and asking them to different people depending on where the product is going. A patient engagement platform going into a safety-net hospital needs to be specified against the reality of patients at that institution — not patients in general, not patients who showed up to a focus group in a conference room, and not the patient someone on the product team imagined while writing requirements. It means the questions themselves have to change by context. And it means building that into the process before anyone opens a design tool.
Two regulated verticals have already run this experiment. Financial services has the completion rate data. Agriculture has the adoption curves from precision farming platforms that saw early enthusiasm from agronomists and investors, then hit steep drop-offs when the technology had to fit the actual rhythm of a farm operation — the seasons, the equipment, the decision windows that nobody had mapped, because nobody had asked the farmer.
The pattern is the same: a product built to satisfy the buyer's evaluation criteria, failing the people who were never represented in that evaluation.
Healthcare is running it now. The patient survey data is one early reading. The clinical stories are another. The question isn't whether the pattern will repeat. It's whether anyone reads the evidence from the other verticals before the adoption numbers say what they always say.
Comments