Ayush Sharma · Product & Operations Lead, Medoc Health IT
I wrote a short post about this a while back: If everything is P0, nothing is P0. It's a simple line, but it took a real stretch of pain at Medoc to actually believe it.
Here's the honest version of what happened. We were scaling: more hospitals, more staff, more requests coming in every day. It felt like momentum. It wasn't. Every hospital that came on board had its own list of changes it wanted, and because each one felt urgent to the client asking for it, we treated almost all of it as urgent to us too. The team got pulled left and right between clients, patching one hospital's billing complaint, then a different hospital's training issue, then a third one's dashboard request, all in the same week. Nobody was tracking whether any of it moved a number that mattered. We simply didn't think about metrics at all during that period. Busy felt like the same thing as progress, and for a long stretch we didn't have anything that could tell us it wasn't.
The actual cost showed up later: support tickets stacked up, engineering was stretched across a dozen half finished threads instead of a few finished ones, and none of us could say with a straight face which of the last twenty requests had actually moved adoption, revenue, or client trust. We had shipped constantly and grown slowly, at the same time.
What I learned from it, stated plainly: prioritization isn't a skill you apply after you have metrics, it's the thing that forces you to get metrics in the first place. If you can't measure whether a request matters, you have no honest way to say no to it, so everything defaults to yes, and everything defaults to urgent. "Everything is P0" isn't really a prioritization failure. It's a measurement failure wearing a prioritization costume.
The second mistake is a quieter one, and it took longer to notice. Medoc's early build culture, like a lot of engineering-led teams, treated functionality as the whole job: does the feature technically do what it's supposed to do. Whether it was easy or painful to actually use during a busy shift wasn't part of how anyone judged "done." A feature that technically worked was a finished feature, full stop.
That mindset came back to bite us directly. A lot of what looked like a wave of bug reports and feature complaints from hospital staff, especially in billing and pharmacy, wasn't really about broken functionality at all. It was about friction: too many steps to edit a bill line, three separate boxes for IPD, OPD, and Pharmacy instead of one coherent flow, a dashboard that buried the three numbers a billing clerk actually needed under an order ID nobody cared about. None of that was a bug. All of it built up into staff working around the system instead of through it, which is a much harder problem to notice than a crash, because nothing throws an error. People just quietly stop trusting the tool and go back to the old way.
Changing how the tech team saw this took more than telling them UX mattered. What actually moved it: showing the support ticket volume next to the specific screens generating it, so the cost of "it technically works" was visible in a number engineers already respected. Getting a couple of engineers to sit next to a billing clerk during a real shift, not a demo, so they saw the friction happen in real time instead of reading about it secondhand. And changing what "done" meant for a ticket, so a feature wasn't closed just because it passed a functional test, it had to also survive someone doing their actual job with it under real time pressure.
The reframe that stuck: UX isn't the opposite of functionality, it's the part of functionality that only shows up under real use. A billing edit that takes eleven clicks technically works. It also fails the job the moment a patient is standing there waiting.