What Pizza Taught Me About Fixing Healthcare Admin

In 2008 I met a pizzeria owner in Astoria who had been open since 1981. Her shop had survived three recessions, two neighborhood demographic shifts, and the arrival of every major delivery app. She had not survived any of it by running a more efficient back office. She survived it by being the kind of place people thought of as part of the neighborhood's identity.

By the time I joined Tennr, I'd been sitting with a version of the same person for a decade. Different industry, different vocabulary, different regulatory environment. Same fundamental problem. Someone excellent at the work they chose had spent years accumulating administrative burden that had nothing to do with why they were excellent at it.

American physicians now spend roughly two hours on administrative tasks for every hour of patient care. That ratio comes from a 2016 Annals of Internal Medicine study that tracked 57 physicians across four specialties, and subsequent data suggests it has gotten worse, not better, since the widespread EHR adoption that was supposed to fix it. In independent practice, the ratio is often higher because there's no administrative staff to absorb the load.

The pizzeria owner and the physician are not analogous because I find the comparison clever. They are analogous because the same design failure produced both situations.

The Design Failure Has a Name

Clayton Christensen developed the Jobs to Be Done framework to understand why customers buy what they buy. The insight is simple and routinely ignored: people don't buy products. They hire them to do a job. The job is the unit of analysis, not the product category.

The job the pizzeria owner is hiring for is "run a restaurant that becomes part of this neighborhood for the next thirty years." Not "manage delivery platform integrations." Not "respond to reviews at 11pm." Those are administrative artifacts of running the restaurant, not the job itself.

The job the physician is hiring for is "practice medicine in a way that actually helps people and sustains a career worth having." Not "complete prior authorization workflows." Not "document encounters in a system optimized for billing codes rather than clinical memory."

When you get the job definition wrong, you build the wrong product. This is precisely what happened to EHR systems. They were designed to solve the billing and compliance job for hospital administrators and insurance companies. They were then handed to physicians as clinical tools. The job mismatch is why KLAS Research consistently reports physician satisfaction with EHRs below 50 percent, and why EHR usability scores in independent practice are among the lowest in any enterprise software category.

What Atul Gawande Saw That Most Founders Miss

Atul Gawande wrote about this dynamic for the New Yorker in 2018 in a piece called "Why Doctors Hate Their Computers." His observation was precise: the problem wasn't that EHRs were bad software. It was that they were built for a different principal. "The core promise of electronic records," Gawande wrote, "was better care at lower cost. What we have now is close to the opposite." The software optimized for the institution's relationship with regulators and payers. The physician's relationship with the patient became secondary to that optimization.

At Slice, we saw this pattern play out at smaller scale. Our early competitors built restaurant management software for restaurant managers. Restaurant managers care about shift scheduling, inventory turn, and labor cost percentage. Owner-operators care about whether regulars are coming back and whether the neighborhood feels like the restaurant belongs to them. Different jobs. Different products. The operators who felt that distinction most sharply were the ones who churned off the competitors and stayed with us.

Why the Administrative Layer Only Compounds

There is a structural reason this problem doesn't self-correct. Administrative requirements in both industries are set by parties whose incentives aren't aligned with the operator's time.

In healthcare, prior authorization requirements are set by insurers who benefit from friction in the approval process. CMS compliance documentation requirements are set by regulators optimizing for auditability. EHR vendors serve hospital procurement committees, not the physicians who use the systems daily. Every one of these principals adds requirements that seem rational from their vantage point and accumulate as an irrational burden from the physician's.

In local business, the equivalent dynamic plays out through aggregator platforms. DoorDash, Grubhub, and their competitors set terms that favor their own customer relationship over the restaurant's. The operator accepts the terms because the short-term volume justifies it, even as the platform trains their customers to think of the transaction as belonging to DoorDash rather than to the restaurant. Each accommodation makes sense individually. Cumulatively, the operator has outsourced their most valuable asset, the customer relationship, to someone with different interests.

The problem in both cases is the same: the operator made a series of locally rational decisions that collectively produced an irrational outcome. The software that fixes it isn't software that makes those decisions easier to execute. It's software that removes the need to execute them at all.

What the Playbook Actually Is

The version of this I worked on at Slice was primarily a distribution and loyalty problem. The version at Tennr is primarily a workflow automation problem. The tactics differ. The underlying logic is identical. Here's what works:

• Start with the interruption, not the workflow. User research that asks operators to map their workflows produces neat flowcharts. User research that asks what pulled them out of the room they were supposed to be in produces product requirements. At Tennr, the answer was prior authorizations. At Slice, it was delivery platform disputes. Those are the highest-ROI interventions because they're the ones the operator most wants to not think about.
• Measure time-to-value in minutes, not weeks. Independent operators have no implementation budget and no tolerance for onboarding curves. The product has to demonstrate value within the first session or you've already lost them. We tracked "time to first meaningful outcome" as a primary product metric at Slice. If a new shop owner couldn't see a direct order come in through our platform on day one, something was wrong with the onboarding, not with the operator.
• The technology has to be invisible to the end customer. The patient shouldn't know what software the physician uses. The diner shouldn't know what platform the restaurant is on. The moment the technology becomes visible to the end customer, it has failed its job. The operator just needs to notice that the thing they were doing manually isn't taking their time anymore.

What Changes When It Works

When we got the Slice product right, the change wasn't visible in revenue metrics first. It was visible in how operators talked about their businesses. They stopped talking about delivery commissions and platform disputes. They started talking about regulars, new recipes, community events. The actual work came back into view because we had absorbed enough overhead that they could see it again.

That's the product outcome worth building for. Not the software metric. The physician who has time to call a patient back. The restaurateur who is in the dining room at 7pm instead of in the back office disputing a chargeback. The mechanic who actually talks to the person who owns the car instead of documenting the conversation he just had.

Healthcare is harder than restaurants. The regulatory surface is enormous, the liability is high, the incumbents are entrenched and politically connected. But the core problem is simpler: someone excellent at one thing is buried under something else. The opportunity is to bury it for them instead.

That's the company. Everything else is execution.