Scoping a healthcare operations platform down to a shippable wedge

A healthcare operations founder came in with a platform ambition: an AI layer across the entire practice operation. Front office work, scheduling, intake, patient access. Back office work, claims, prior authorization, denials. Two customer profiles in the same breath, multi-site group practices and mid-market hospital systems.

Read as a product, that is four or five separate products sharing a name. Each one has a different buyer, a different data substrate, and a different tolerance for being wrong.

The brief was strong on ambition and thin on sequence. My job was to find the sequence.

I ran the founder session and turned it into a written product brief. I then mapped every use case in that brief against our internal build library, the set of AI frameworks and components we had already built and could redeploy, and sorted the matches into three tiers by how directly they applied.

I did not own engineering estimates or integration architecture. Those came from the engineering lead once scope was settled.

The mapping produced four candidate products, each backed by components we already had.

1. Ambulatory operations intelligence. Scheduling and visit flow, no-show patterns, referral leakage. Anchored in the group-practice buyer with a path upward into hospitals.
2. Revenue cycle and denial intelligence. Charge-to-payment cycle time, claims normalisation, denial reason extraction from remittance narratives, prior authorization bottlenecks. The cash-flow lever.
3. Hospital operational data foundation. Clinical notes, standardised lab coding, admission event streams, patient record unification. The substrate everything else sits on.
4. Care pathway insights. Quality improvement evidence synthesis, staffing benchmarks, pathway optimisation.

Underneath those sat a cross-cutting compliance and integration spine, which mattered because the regulatory surface here is not optional and the EHR integration work is the same regardless of which product ships first.

The obvious recommendation was the third one, the data foundation. It is the substrate, everything else depends on it, and building it first is the architecturally clean answer.

I recommended against it.

A data foundation has no visible output. A design partner who funds six months of substrate work sees nothing they can show their own board, and the engagement dies of boredom before the products that justify it exist.

Sequencing correctly for the architecture sequences wrongly for the relationship.

What I recommended instead was a fifth option that was not in the original four: pair the front-desk flow mining with the back-office denial intelligence and ship them as a single combined wedge.

The reasoning:

• One buyer. Both halves sell to the same operations lead at the same practice. Two products with two buyers is two sales motions, and an early-stage partner cannot run two.
• One data substrate. The ingestion plumbing is shared, so the second half is materially cheaper once the first exists. The foundation still gets built, just as a byproduct of shipping something visible.
• Insights first, no patient-facing AI on day one. In healthcare, a patient-facing mistake is a different category of problem than an internal one. Landing on an insights surface meant the accuracy and compliance questions could be answered before anything touched a patient.
• It proves the platform story. The partner’s differentiation claim was end-to-end coverage of the patient journey rather than one slice of it. Front plus back is the smallest thing that demonstrates that claim. Either half alone contradicts it.

The cost was a longer first build than a single-product wedge would have been. I took that trade, because a first build that does not support the positioning is a wasted first build.

The combined wedge qualified into a build. It is now live with design partners: small healthcare organizations running it against their own operational data.

The part I would point to is not that the analysis was thorough, but that the sequencing argument held up.

The partners who signed on had something to look at inside the first release, which is the whole reason I argued against building the substrate first.

I built it as an automation problem.

The goal I set at the start was end to end: take the manual operational flow, map it, automate it, remove the human steps. That is a reasonable thing to optimise for and it is not the thing that matters most here.

Automating a flow makes an existing process faster. It does not tell a practice manager that next Tuesday is going to break.

The lever in healthcare operations is prediction. Two staff out in the same week. A denial rate creeping up before anyone has noticed the pattern. Appointment load stacked past what the doctors on shift can absorb. All of that is visible in precedent data before it becomes a problem, and none of it surfaces from a faster version of the same flow. The system already knows how many appointments a given doctor can take before the schedule collapses. It should say so before the bookings happen, not process them more efficiently once they have.

If I scoped this again I would design for proactive recommendation first and automation second.

Automation is the delivery mechanism. The recommendation is the product, and I had those the wrong way round.

There is a second thing in that, which I own: my own brief argued for an insights-first landing, and then I built automation-first. The scoping was right and the execution drifted from it.