Your product doesn’t have to fail to become part of the problem.
I’ve been thinking about this since I left the clinical documentation company I co-founded earlier this year. We started with real ambition: we wanted to fundamentally change how paperwork moved through a clinic visit starting from a shared belief that the “note” had outlived its purpose. We had ideas about what documentation could look like if you weren’t trained on and attached to traditional practices. We wanted an opportunity to fundamentally rethink how clinicians interact with their patients and their data. Because we were clinicians who’d lived on the receiving end of that mess, we thought we understood the problem well enough to take some genuine swings.
What happened instead was quieter than failure and at least for me, harder to name.
Some of our early users and plenty of potential clients pushed back on our thesis. Not because our approach was wrong, but because it was unfamiliar. The note didn’t look like the note they were used to. The workflow asked them to do something different before they could see why different was better. Our 10 minute phone call about why automatically generated medical problems were better for information scatter was too intangible. So we adjusted. We asked them what features they missed in the platform compared to what they were used to. We (as head of product, I, more specifically) shaped our roadmap around what clinicians asked for rather than listening to their frustration and building a system that solved the root of the problem. Each adjustment made sense on its own.
Then a handful of potential clients told us they wanted a note writer, could we build one? Our technical lead and I felt that it would be a fast add-on, the kind of thing that closes early deals while the longer-term vision matures in the background. So we built it. Then users wanted templates which we added. But, the tone didn’t match the writer’s style so we added settings for verbosity and format. Our product roadmap was absorbed by this one decision and I’m honestly not sure we ever got back on track. A feature built to bring in revenue consumed the capacity we needed for the work that mattered to us.
This is the part I keep coming back to: at the time, we weren’t the system of record. We sat between the visit and the EHR, an intermediate step in someone else’s infrastructure. That dependency meant conforming to each clinic’s existing setup, fitting their workflow rather than offering a better one, and returning a product that could be shared with their record system. The architecture of the ecosystem itself selected for compliance and we avoided ambition in the name of growth.
I don’t think the lesson here is that we made bad decisions. I think the lesson is that the forces pulling a health tech company toward the safe, familiar, incremental choice are structural and relentless. A thousand small concessions can quietly reshape a product until the constraints are a factor in every design decision. And what disappears first isn’t the technology, but the sense of clarity about where you were trying to go.
After I left, I kept having versions of this same conversation with other founders, with operators, with clinicians who’d spent time inside startups. The same pattern kept surfacing; the same drift toward the corner. With relief and with trepidation, I realized it wasn’t just us.
I’m writing about this because I think it matters, and because I don’t see enough people talking about the structural traps in health tech from the inside rather than the outside. Not what AI will do someday, but the lived and uncomfortable reality of building technology that touches patients and clinicians, and the ways good intentions get quietly rerouted. This is where I want to spend my time: in the gap between what we set out to build and what the system tries to shape us into building.