Founder-Market Fit in Surgical AI: Why Who Builds the Tool Determines Whether Surgeons Use It
Healthcare AI has produced an unusual pattern. Enormous companies with world-class engineering talent and effectively unlimited capital have built tools that clinicians did not adopt. Meanwhile, smaller companies founded by practicing physicians have built tools that spread through hospitals without heavy sales pressure.
The difference is not talent or funding. It is founder-market fit — whether the people building the tool have personally lived the problem it addresses. In surgical AI, that distinction determines whether a product reaches the operating room or stalls at a demo.
Two Patterns in Healthcare AI
Consider three of the most heavily funded efforts in the field.
Olive AI raised $902 million and reached a peak valuation of $4 billion, making it one of the most heavily funded healthcare AI companies in history [1]. It was founded by Sean Lane, a former Air Force intelligence officer with a cybersecurity background. The company pivoted 27 times by its CEO's own account, expanded into prior authorization, population health, and surgical analytics simultaneously, and never delivered measurable return at hospital scale. By 2022, customers were describing the product as robotic process automation marketed as artificial intelligence. Olive shut down its core operations in October 2023 and sold its remaining assets in pieces.
Google Health assembled roughly 700 people inside one of the most technically capable companies in the world. In 2021, Google dissolved the division and distributed its teams across other business units [2]. The stated reason was strategic reorganization rather than failure, but the outcome was the same: no unified clinical product emerged.
Babylon Health applied a consumer-technology playbook to primary-care triage. It filed for Chapter 7 bankruptcy in 2023 [3].
Now consider a different set of companies. Viz.ai was co-founded by Chris Mansi, a neurosurgeon who built stroke-triage software around a workflow he had personally worked inside. It is now deployed across hundreds of hospitals. Cleerly was founded by James Min, a cardiologist who spent his career studying coronary imaging and built the analysis tool around a question he had been asking clinically for years. Osso VR was founded by Justin Barad, an orthopedic surgeon who built surgical training software for a gap he had experienced during his own training.
An important caveat belongs here. Clinical leadership is not sufficient on its own. Many physician-founded companies still fail, and the reasons are usually the ordinary ones: poor economics, weak execution, bad timing. The claim is narrower and more defensible. It is difficult to build a good solution to a problem you have never personally carried.
What Clinical Practice Contributes to Product Design
Clinical experience contributes four things to the design of a clinical tool. Each is difficult to acquire any other way.
Problem selection. The problems visible from outside a clinical setting are not the problems that most constrain practice. Documentation burden and scheduling inefficiency are visible to any observer. The uncertainties that actually govern clinical decisions are not, because clinicians rarely articulate them explicitly. A founder who has practiced selects problems from the second category.
Constraint recognition. Clinical workflows impose constraints that are invisible in a requirements document: the time available before a decision, the cognitive load already present, the number of systems a clinician is already required to maintain. A tool that ignores these constraints fails at deployment regardless of its accuracy.
Trust requirements. Clinicians act on information they can verify and defend. A recommendation without visible reasoning cannot be checked against the patient in front of them, cannot be questioned, and cannot be defended in peer review or in a deposition. A founder who has been the person responsible for a decision designs for this by default.
Failure mode recognition. Practicing clinicians have watched clinical tools fail. They have abandoned systems that added friction, disregarded alerts that fired too often, and stopped consulting outputs they could not verify. That accumulated experience is a form of design knowledge, and it is available only to people who have been on the receiving end of poorly designed clinical software.
These contributions are available to any company willing to embed with clinicians over a sustained period. The advantage of clinical founders is not exclusivity of access but default orientation: these constraints govern design decisions from the beginning rather than being discovered after a product has already been built.
The Clinical Trust Ladder
The reason this matters is that adoption in medicine follows a specific sequence. A tool has to climb four rungs, and most healthcare AI never gets past the first.
Rung one is regulatory clearance. The tool is legally permitted to be used. This is necessary and difficult, and it is where a great deal of healthcare AI investment concentrates. It also says nothing about whether a clinician will actually use the tool.
Rung two is workflow fit. The tool has to fit how clinicians actually work — no separate system to maintain, no additional clicks, no parallel process. A tool that adds friction gets abandoned regardless of its accuracy.
Rung three is clinical trust. The clinician has to be able to see why the tool produced its output and weigh it against the patient in front of them. Without visible reasoning, the tool cannot be verified, questioned, or defended.
Rung four is routine use. The tool gets used on ordinary cases, not just showcase ones. Peers ask about it without prompting. Adoption spreads without incentives. This is the only rung that indicates a tool has actually changed practice.
Founders who have practiced medicine have climbed rungs two through four as users rather than as vendors. That experience governs design decisions from the beginning, before a product reaches a hospital and before the constraints become expensive to correct.
How This Shapes SDI
Surgeon Decision Intelligence was founded by practicing spine surgeons. The consequence is visible in the problem the platform was built to address.
The problem is not documentation, scheduling, or image annotation. It is this: a surgeon can perform a technically sound operation and still produce a poor outcome. The screws are placed correctly. The decompression is adequate. The alignment is restored. Two years later the construct has failed and a revision is being scheduled.
When surgical outcomes fail early, the failures are frequently biological rather than technical. The bone did not consolidate. The soft-tissue envelope could not support the construct. The vascular supply to the fusion bed was compromised in a manner that no element of the standard preoperative workup measured. The patient's tissue biology was not suited to the operation performed, and that fact was present before the incision.
This produces a specific asymmetry in surgical practice. Technique is discussed publicly; biology is discussed quietly. A surgeon presenting a failed case has a developed vocabulary for describing operative technique and almost no shared vocabulary for describing why a well-executed operation failed for reasons determined beforehand. Surgeons consequently carry reputational and psychological weight for outcomes that may have been biologically inevitable.
The design principle that follows is that feasibility is not equivalent to suitability. A surgeon can technically perform an operation on nearly any patient. Whether that patient's biology will support the result is a separate question, and it is the question that determines durability. SDI exists to make that question answerable before the operation rather than after it.
The remaining design decisions follow the same logic. The platform quantifies tissue biology preoperatively — muscle quality, disc health, vertebral bone quality, vascular calcification, endplate changes — because those are the variables that determine whether a construct holds. The platform does not issue directives, because surgeons who have been instructed by software understand how rapidly that erodes trust. Every output is explainable, because a surgeon who cannot see the reasoning cannot defend the decision. The platform is implant-agnostic, because a tool with a commercial interest in the answer is not a decision aid. And the models are trained on real surgical cases with longitudinal outcomes rather than on hypothetical ones.
These are design consequences rather than marketing positions. Uncertainty in surgery is a condition of the work, not a deficiency in the surgeon. A platform built by people who have carried that uncertainty is designed to reduce it, not to obscure it.
Capital and engineering capability are not the binding constraints in surgical AI. Problem understanding is. The companies that succeed in this field will be those whose builders have made irreversible decisions under biological uncertainty, and who designed accordingly.
References
[1] Health AI startup Olive to shut down. Healthcare Dive. October 2023. Olive raised approximately $902 million across its funding history, reaching a $4 billion valuation in 2021; core operations ceased October 2023 with assets sold to Waystar and Humata Health.
[2] Google disbands health unit as chief departs for Cerner. Healthcare Dive / MedTech Dive. August 2021. Approximately 130 staff reassigned; division split across other Google units.
[3] Jennings K. Digital Health Company Babylon Files For Bankruptcy In U.S., Will Liquidate. Forbes. August 15, 2023. Chapter 7 filing dated August 9, 2023.