That’s real progress for the companies that qualify. Jennifer Newberger at the FDA Law Blog did a great breakdown of how narrow the eligibility criteria actually are: roughly 40-60 devices out of 1,246 Breakthrough designations. If you want the regulatory mechanics, start there.

But the celebration on LinkedIn is telling a different story. Founders and VCs are sharing the press release like the reimbursement problem just got solved. It didn’t. And the excitement might be doing more harm than good.

The Problem RAPID Fixes vs. The Problem Most Founders Have

RAPID fixes a calendar problem. FDA clears a device, and then CMS takes a year or more to issue a coverage determination. That gap is real and it hurts. For the narrow group of companies running IDE studies with Medicare patients, RAPID closes that gap.

But the coverage problem I keep seeing in healthtech companies has nothing to do with the calendar. It’s a knowledge problem.

I spent this spring evaluating over 50 healthtech companies across multiple programs. I asked nearly every one of them some version of “who pays for this and how much.” Same answer, over and over.

Founders with working products, FDA pathways mapped, clinical data in hand. And no answer to the payment question.

One founder told me they’d “follow the pathway of companies that recently commercialized in adjacent spaces.” When I asked which billing code, they named a general one. When I asked about the gap between what that code reimburses and what their product costs, they didn’t have an answer.

Another said they planned to “partner with a large company” to handle “the downstream economics.”

These aren’t companies that need CMS to move faster. These are companies that haven’t started thinking about coverage at all. RAPID doesn’t help them. Nothing helps them except sitting down and doing the work.

Whether RAPID Matters to You Depends on One Question

RAPID is a Medicare pathway. It synchronizes FDA authorization with Medicare national coverage determinations. Whether that matters to your company depends on whether Medicare is your gateway payer or just one payer among many.

If you’re building a Class III implantable device or a high-risk therapeutic where Medicare is the dominant payer for your patient population, RAPID matters even if you don’t qualify directly. Commercial payers watch what CMS does. When Medicare covers something, Blue Cross and Aetna often follow. When Medicare doesn’t, commercial payers use that as cover to deny. A faster NCD creates a faster signal to the rest of the market. For you, RAPID could shorten the entire coverage cascade.

But if you’re building a SaMD, a digital health tool, a remote monitoring platform, or a clinical workflow product selling to health systems, your first several contracts probably have nothing to do with Medicare. You’re getting paid through commercial payers, operational budgets, value-based care contracts, or employer wellness programs. Commercial payers make independent coverage decisions for these products all the time. You can bill under existing evaluation and management codes, remote monitoring codes, or negotiate directly with the system.

For those companies, the relevant reimbursement question isn’t “when will CMS issue an NCD.” It’s “which commercial payer will cover this, at what price, with what evidence requirements.” And that question looks nothing like the Medicare NCD process. It’s payer-by-payer, contract-by-contract, and nobody is building a fast-track pathway for it.

One important caveat: CPT codes are maintained by the AMA, not CMS. You don’t need a Medicare NCD to have a billing code. Getting a new Category I or Category III code is a separate process that RAPID doesn’t touch. So the “no billing code” problem and the “no Medicare coverage” problem are related but distinct. If your core coverage challenge is that no code exists for what your product does, RAPID won’t fix that regardless of which camp you’re in.

Know which camp you’re in. If Medicare is your gateway, pay attention to RAPID even from the outside. If it isn’t, your first move is to contact the medical policy team at the two largest commercial payers in your target customer’s region and ask what evidence they need. That conversation will teach you more about your coverage path than any federal announcement will.

This is where I get skeptical: I’ve watched this pattern play out before. Breakthrough Device designation was pitched as offering reimbursement benefits. MCIT would have given automatic Medicare coverage to BDD holders for four years. It was withdrawn. TCET promised expedited coverage. It was capped at five devices per year and has now been paused. Meanwhile, a JAMA Internal Medicine study found that only about 12% of breakthrough-designated devices received FDA authorization at all between 2016 and 2024. For 510(k) devices specifically, breakthrough-designated products actually took slightly longer to clear than comparable non-breakthrough devices.

It’s the same cycle every time: a new pathway gets announced, founders treat it as a signal that the coverage problem is being solved, and then the pathway turns out to be narrower, slower, or shorter-lived than the press release suggested. RAPID could give the companies that don’t qualify a false sense that the system is moving in their direction. It isn’t. Not for them. Not yet.

What Hasn’t Changed As of Last Wednesday

Your regulatory claims determine your coverage options. The clinical claims in your FDA submission determine which billing codes you can bill under. If your submission supports a narrow indication, your billing options are narrow. If you’re building a SaMD and your claims are structured as clinical decision support rather than diagnostic, that affects whether any payer will cover it at all. I’ve seen companies structure their regulatory submission for speed and accidentally close their reimbursement options. The 510(k) you get fastest isn’t always the 510(k) that gets you paid. Your regulatory strategy and your reimbursement strategy need to be connected. For most companies I evaluated this spring, they weren’t.

Nobody is going to figure this out for you. RAPID helps a few companies by bringing CMS into the conversation early. If you don’t qualify for RAPID, you need to bring yourself into the payer conversation early. That means talking to the commercial payers in your target market before you finalize your clinical study design, not after you clear. What evidence do they need? What endpoints matter to them? How do those differ from what FDA needs? These aren’t questions you can answer from your desk.

Coverage planning before clearance sets you apart. The companies I saw that had clean answers to the reimbursement question stood out because almost nobody does. When every other company in your evaluation cohort freezes on the payment question, the one that can walk through their billing code, their payer strategy, and their savings-per-case math gets remembered. That hasn’t changed.

RAPID is a step forward for the small group it serves. For everyone else, the coverage question is the same question it was last week. And the answer is still: this is your problem to solve, and the best time to start solving it is before you clear, not after.

On April 28, the FDA announced two live proof-of-concept trials where safety signals and clinical endpoints stream to FDA reviewers in real time as the trial runs. AstraZeneca’s Phase 2 TRAVERSE trial for mantle cell lymphoma is already operational at MD Anderson and Penn. Amgen is in site selection for a Phase 1b trial in small cell lung cancer.

The technology partner making this work? Paradigm Health. Not Medidata. Not Veeva. Not Oracle.

That detail alone tells you something important about where the FDA thinks the future is.

What Actually Happened

Commissioner Makary opened the press conference with a number that should bother anyone in clinical operations: 45% of the time between a Phase 1 trial starting and the FDA application being filed is dead time. No trial running. Staff doing paperwork, entering data into multiple systems, repackaging the same information across phases. Some of that gap is genuine scientific deliberation: analyzing results between phases, deciding whether to proceed, amending protocols based on what you learned. Not all dead time is waste. But the FDA clearly believes the ratio is off, and the direction of the fix tells you where the pressure lands.

He described one application that was 66 million pages. His proposed fix: “a radical modern concept called the page limit.”

The real-time trial model works differently. Paradigm Health’s platform captures data directly from electronic health records and other structured sources, algorithmically evaluates FDA-defined data points, and transmits only the signals the FDA needs to make regulatory decisions. The FDA doesn’t get raw patient records. It gets aggregated signals: adverse event rates, tumor response percentages, safety thresholds. The data is traceable, auditable, and privacy-preserving.

Jeremy Walsh, the FDA’s Chief AI Officer, was blunt about the philosophy: “Can we make a decision off of less information? Can we make a decision off of signals information?”

To be clear: no regulatory decision has been made based on this model yet. The AstraZeneca trial has transmitted and validated signals through Paradigm Health’s platform, but the FDA hasn’t approved or rejected a drug using real-time data. It’s a proof of concept, not a proven pathway. But the direction it signals matters more than its current status, because it tells you what the FDA is optimizing for next.

That question should be reverberating through every product roadmap meeting at the major eClinical vendors right now.

The Stack That’s Exposed

The eClinical market is projected at roughly $13 billion in 2025, growing to $25 billion by 2030. It’s dominated by a handful of players: Medidata (Dassault Systemes), Veeva Systems, Oracle Health Sciences, IQVIA, and Signant Health. The core revenue driver across all of them is the same workflow: capture clinical data in an EDC system, clean it, manage it through a CDMS, package it, and submit it to the FDA at the end of each trial phase.

That’s the workflow Makary just called tedious, wasteful, and outdated on national television.

Here’s where the specific exposure sits:

EDC (Electronic Data Capture). If trial data increasingly flows from EHRs directly into an FDA-visible cloud dashboard, the standalone EDC’s role as a data capture tool gets compressed. But an EDC isn’t just a data capture tool. It’s a protocol execution engine: it enforces visit schedules, eligibility criteria, edit checks, query management, and adverse event grading per CTCAE criteria. An EHR knows a patient had a fever. An EDC knows that fever was a Grade 2 adverse event that occurred 14 days post-dose and triggered a dose modification per Section 6.2 of the protocol. That protocol enforcement layer still needs to live somewhere. The question is whether it continues to live in a standalone EDC, gets absorbed into the EHR, or moves into the middleware. That’s an architectural question, not a foregone conclusion, and it’s the one that determines how much pricing power EDC vendors retain.

CDMS (Clinical Data Management Systems). The entire value proposition of a CDMS is cleaning, reconciling, and structuring data for submission. If the FDA moves toward signal-based review where it receives pre-agreed data points in real time, a significant portion of the data management workload becomes unnecessary. You don’t need to clean and reconcile 66 million pages if the FDA only wants 12 defined signals.

Submission and regulatory publishing tools. McCary’s press conference was basically a 45-minute argument against the batch submission model. If regulators can see what they need in the cloud while a trial is running, the multi-month packaging and publishing cycle at the end of each phase gets compressed or eliminated. And this pressure isn’t just coming from the FDA side. Accumulus Technologies, spun out from a nonprofit backed by major pharma sponsors in 2025, has built a cloud platform that connects sponsors to 70+ national regulatory authorities for real-time submission, collaboration, and review. Their Accumulus Connector, launched in March 2026, plugs directly into sponsors’ existing systems so submissions flow to regulators without manual reconciliation. The traditional regulatory publishing workflow isn’t just being questioned by the real-time trial model. It’s being replaced by infrastructure that already exists and is already in use.

Safety and pharmacovigilance systems. The FDA also announced it’s consolidating seven internal adverse event reporting systems into one, after finding that 60% of people who started filing an adverse event report gave up before finishing. The incumbents who’ve built integrations into CARES, FAERS, and MAUDE now face a moving target.

What the Incumbents Still Do That Matters

Before anyone reads this as an obituary for Medidata: the incumbent eClinical stack does things that a two-trial proof of concept at US academic medical centers does not replace.

21 CFR Part 11 compliance. CDISC mapping. ICH E6(R2) audit trails. Multi-country regulatory alignment across the EU, Japan, China, and dozens of other jurisdictions. The ability to run a 300-site global Phase 3 trial across Southeast Asia and Latin America where half the sites are still working with paper source documents and fragmented IT infrastructure. That infrastructure took decades to build, and it doesn’t become irrelevant because the FDA stood up a dashboard at two of the best-resourced cancer centers in the country. Though it’s worth noting that even the global regulatory alignment moat is being tested: Accumulus Technologies has already run simultaneous multi-regulator submission pilots across six continents, which is the exact capability the incumbents would point to as their strongest defensive position.

The real-time trial model works at Penn and MD Anderson because those institutions have world-class Epic implementations, mature research IT teams, and decades of experience running complex trials. Most trial sites globally don’t have that. Community oncology practices, rural hospitals, sites in emerging markets where much of the growth in clinical trial activity is happening, these are environments where the existing eClinical stack still solves real problems.

So let’s be precise about the threat. The near-term exposure is concentrated in early-phase oncology trials at large US academic medical centers. That’s a specific wedge, not the whole market. And the infrastructure gap between Penn and a community oncology practice in rural Tennessee took EHR vendors the better part of two decades to close. Nobody should assume real-time trials scale to 300-site global programs in the next three years.

But wedges are how disruption works. They don’t stay contained. And the reason this one won’t stay contained is that it’s not a standalone experiment. It’s converging with at least four other shifts happening simultaneously.

This Isn’t Happening in Isolation

The real-time trial announcement doesn’t land in a vacuum. It’s the latest in a sequence of moves that, taken together, point in the same direction, even if they weren’t designed as a single strategy.

December 2025: RWE de-identification. The FDA updated its guidance to allow sponsors to submit real-world evidence without requiring identifiable patient-level data. De-identified data from registries, claims databases, and EHR networks is now acceptable for medical device submissions, and the FDA signaled it intends to extend this to drugs and biologics. This opens the door for massive de-identified datasets to supplement or, in some cases, replace traditional trial data. Only 35 drugs, biologics, or vaccines have incorporated RWE into their applications since 2016. That number is about to change.

September 2024: Finalized DCT guidance. The FDA’s decentralized clinical trial guidance clarified that trial activities can happen at locations other than traditional clinical trial sites, including home-based visits, telehealth, and mobile research units. This pushes data collection closer to the patient and further from the centralized site model that EDC systems were designed for.

PDUFA VIII negotiations (ongoing). The reauthorization talks include an “America First” fee incentive that would reduce application fees for sponsors conducting Phase 1 trials domestically while potentially adding fees for those who don’t. The FDA and industry hit an impasse on this in February, but the direction is clear: the FDA wants more early-phase trials running in the US. McCary said explicitly that more Phase 1 trials are starting in China than in the US. If PDUFA VIII succeeds in pulling trials back onshore, it increases the pressure to make domestic trial execution faster and cheaper, which means less tolerance for the current data management overhead.

System consolidation. Beyond the clinical trial reforms, the FDA is collapsing 40 application intake systems into one and consolidating three safety monitoring systems into one. The agency estimates this saves $120 million annually, which it’s reinvesting in hiring 3,000 scientists. The message: the FDA is simplifying its own infrastructure and expects the industry to keep up.

What I’d Be Doing If I Were Still Inside

I spent years inside clinical trial technology at a 500-person eClinical platform company with a huge footprint across the who’s who of biopharma and a scrappy startup. I know what the data management workflow looks like from inside the machine: the same safety and efficacy data getting entered, cleaned, reconciled, packaged, and resubmitted at the end of every phase because that’s what the regulatory process required. Not because it was the best way to evaluate whether a drug works. Because the filing structure demanded it.

To be fair, the industry has been reforming these workflows for years. Risk-based monitoring, central statistical monitoring, adaptive trial designs. RBQM has been in ICH E6(R2) since 2016. Sophisticated sponsors don’t manage data the way they did a decade ago. But those are incremental improvements to a batch-submission architecture. What the FDA announced this week isn’t incremental. It’s a different model entirely: continuous signal review instead of phase-gated data packages. That’s the gap between optimization and redesign.

Here’s what I’d be telling the product leadership team if I were still in that world:

Stop treating this as a feature request. The instinct at most eClinical companies will be to add a “real-time signals” module to the existing platform and call it innovation. That’s the wrong move. The FDA isn’t asking for a new feature on top of the old workflow. It’s questioning whether the old workflow needs to exist in its current form. Building a real-time dashboard on top of a batch-submission architecture is putting a coat of paint on a structural problem.

The EHR integration question is existential. Paradigm Health’s entire approach is EHR-native. Data flows from Penn and MD Anderson’s health records into the FDA’s view. If that model scales, the EDC is no longer the system of record for clinical data. The EHR is. Every eClinical vendor needs a credible answer to the question: what is our role when the source of truth is the health record, not our platform?

The real competitor isn’t another eClinical company. Paradigm Health isn’t in the Medidata/Veeva/Oracle competitive set. It’s a clinical operations company that built technology for a specific workflow problem the FDA wanted solved. The incumbents are competing against the workflow itself becoming obsolete, not against a rival platform.

The people who installed the stack are leaving to replace it. I recently spoke with a founder who spent years as a Veeva implementation consultant for enterprise pharma accounts, deploying CTMS, eTMF, and SiteConnect across large clinical programs. She then moved to the CRO side and led implementations of Medidata and Oracle for Syneos Health. She saw the stack from both angles, vendor and operator, and left to build a protocol design tool because the workflow she’d been installing for years was still producing the same problems: amendment cycles, design rework, operational delays that cascade downstream. When the people who implement the incumbent platforms start building alternatives to them, that’s a leading indicator worth paying attention to.

Watch the RFI. The FDA is accepting public comments on the real-time clinical trial pilot program until May 29, 2026. This isn’t a theoretical framework. They’re designing the pilot that will run this summer. The FDA is genuinely asking for input from the companies that have managed clinical trial data at scale for decades, because those companies know things about implementation complexity that the agency doesn’t. Any eClinical company that isn’t contributing to that RFI is missing a chance to shape the pilot based on what they know about the operational reality.

The Uncomfortable Zoom-Out

I want to be honest about something. These initiatives, the real-time trials, the RWE guidance, the DCT framework, the PDUFA VIII negotiations, the system consolidation, did not emerge from a single coordinated FDA strategy. The real-time trial is Walsh’s project. The RWE guidance came out of CDRH. The PDUFA VIII talks are being run by CDER and the Office of the Commissioner. They were developed independently by different parts of the agency with different mandates.

But the cumulative effect is the same regardless of whether it was coordinated. When you line up all five moves, the picture that emerges is a fundamental rethinking of how clinical evidence gets generated, transmitted, and reviewed.

The eClinical stack was built for a world where clinical data is captured in proprietary systems, cleaned by specialized teams, packaged into massive submissions, and delivered to the FDA months or years after the trial ends.

The world taking shape is one where data flows from EHRs and real-world sources upstream, gets algorithmically filtered into signals during the trial, and feeds into real-time regulatory collaboration platforms downstream. The batch-submission model that sits in the middle, the part the incumbent eClinical stack was designed to power, is being hollowed out from both ends simultaneously.

Where the Value Migrates

The question the VC community and corporate strategy teams should be asking isn’t just “who loses?” It’s “where does the value go?” These aren’t independent, parallel opportunities. They’re a dependency chain, and the sequencing matters:

First, EHR vendors become the new system of record. Nothing else in this chain works until clinical trial data flows reliably from health records. If trial data increasingly originates in the EHR rather than being double-entered into a standalone EDC, the EHR platform gains leverage. Epic and Oracle Health (via Cerner) are the obvious beneficiaries. Epic’s research module is already being used in pragmatic trials, and Oracle’s 2025 roadmap explicitly includes EHR interoperability and AI-enabled data capture for clinical research. The question is whether they build the clinical trial layer themselves or whether they partner with companies like Paradigm Health to do it. The biggest risk factor for every other layer in this chain is Epic’s posture toward third-party data access. Epic has historically preferred to build rather than partner, and if Epic decides real-time clinical trial data is a feature rather than a partner opportunity, the middleware market described below gets compressed before it forms. Anyone investing in this space needs to have a thesis on what Epic does next.

Then, new middleware companies that sit between EHRs and regulators. Once EHR data flows, someone has to make it regulatory-grade. Paradigm Health is the first visible example, but it won’t be the last. The company that can reliably extract, validate, and transmit regulatory-grade signals from messy EHR data into a format the FDA trusts has a durable business. That’s a hard technical problem, and whoever solves it at scale across multiple EHR systems and site configurations controls a critical chokepoint. One caveat: Paradigm’s path into this market was through a direct FDA collaboration, which is not a go-to-market motion other startups can copy. The next entrants will likely face standard pharma procurement, which means SOC 2 Type II reports, validated environments, and reference clients. The door is open, but the line to walk through it is harder than Paradigm’s experience suggests.

At the submission end, regulatory collaboration platforms are already live. Accumulus Technologies, spun out from a nonprofit backed by major pharma sponsors in 2025, has built a cloud platform connected to 70+ national regulatory authorities that enables real-time submission, collaboration, and simultaneous multi-country review. Their Connector, launched in March 2026, integrates directly with sponsors’ existing systems so data flows to regulators without manual reconciliation. They’ve already run multi-regulator submission pilots across six continents and claim up to 90% reduction in approval timelines. This is the downstream complement to Paradigm’s upstream signal streaming: if Paradigm changes how the FDA sees trial data during the trial, Accumulus changes how sponsors interact with regulators at the submission and review stage. Together, they compress the batch-submission model from both sides. The eClinical vendors who currently own the submission and regulatory publishing workflow should be paying close attention to Accumulus’s adoption curve, because the “should incumbents build an FDA portal” question is already being answered by someone else.

CROs adapt next, and some come out ahead. The large CROs, IQVIA, ICON, PPD (Thermo Fisher), Parexel, currently license eClinical platforms from the incumbents and mark them up. But technology resale is maybe 15% of CRO margin on a given trial. The bulk of their revenue comes from clinical monitoring, site management, medical writing, biostatistics, and project management. If real-time trials reduce the data management workload, the pressure falls on clinical data management headcount inside CROs, which is a meaningful workforce impact. But the CROs themselves may be net beneficiaries if faster trials mean more volume per year. The ones that redeploy data management capacity into higher-value clinical operations gain margin. The ones that build proprietary EHR integration and signal-reporting technology gain even more. The ones that stay as passive resellers of incumbent platform seats are the ones that get squeezed.

RWE analytics companies scale in parallel. The December 2025 guidance accepting de-identified data opens a lane for companies that can curate, clean, and analyze large real-world datasets at regulatory grade. This was a niche business when only 35 products had used RWE in their applications. If that number grows by an order of magnitude over the next five years, the companies that own the analytic infrastructure become essential partners to both sponsors and the FDA.

The incumbents who pivot fastest survive throughout. This isn’t winner-take-all. Medidata, Veeva, and Oracle have deep client relationships, massive data assets, and the compliance infrastructure that the new entrants lack. The ones who use those advantages to build real EHR integration, not just a checkbox feature but a genuine architectural shift, can protect their position at every stage of this transition. The ones who treat this as a marketing problem and rename their existing products will lose share to companies that don’t carry the legacy architecture.

The market may still grow to $25 billion by 2030. But the composition of that market, who captures the value and what they’re selling, is going to look very different from what the current projections assume.

The Strategy Question

The vendors who move fastest won’t be the ones who add AI features to their existing platforms. They’ll be the ones who ask the harder question: which parts of what we do are still necessary, and which parts exist only because the regulatory process used to require them?

That’s not a product question. It’s a strategy question. And the window to answer it is shrinking.

If you’re running product or strategy at an eClinical company, a CRO, or a healthtech startup entering this space and you want to pressure-test where your roadmap sits against these shifts, I’d welcome that conversation. That’s what my practice does.

Arvita Tripati is the founder and managing director of Vahana Labs, a B2B strategy consulting firm that helps healthtech and AI companies move from pilot to enterprise contract. She has 18+ years of VP-level operating experience across regulated AI, clinical trials, and enterprise healthcare technology, including roles at AliveCor, Vineti, and Endpoint Clinical (LabCorp). You can reach her at arvita@vahanalabs.ai.

But nobody in the IC meeting asked what happens when two of those moderate risks sit on top of each other. And nobody from the board seat is asking whether those combinations are getting worse as the company scales.

I work with PE firms and strategic acquirers evaluating health data analytics assets, and I sit in the room after the close when those assets need governance. Population health platforms, clinical decision support tools, risk stratification engines, benchmarking products. I’ve reviewed enough of these to see a pattern that individual risk scoring misses entirely: certain combinations of product-level risks produce failures that are disproportionate to what the individual scores predict. Those combinations don’t resolve after the deal closes. They compound as the company adds customers, data sources, and features.

Four combinations in particular. Each one has a financial signature. Each one has shown up in assets that looked clean on paper.

Narrow validation + no drift detection = surprise churn in year two

A health data analytics product gets validated at two academic medical centers in the Northeast. The metrics are strong. The company scales to 30 customers across community hospitals, safety-net clinics, and rural facilities. The patient populations at those sites look nothing like the validation cohort. Payer mix is different. Documentation patterns are different. Social determinants data is either absent or structured in ways the model has never seen.

If the product also has no drift detection infrastructure, it’s running without feedback in every environment outside its original cohort. Performance may be degrading at half the customer base without anyone measuring it.

The research on this is not subtle. A 2022 study in the Journal of Medical Internet Research evaluated clinical risk prediction models across three hospitals and found that cross-hospital deployment reduced average AUROC by 8 percentage points (from 94.2% to 86.3%), even when the hospitals were in the same country treating similar conditions with comparable protocols. A systematic review of 86 deep-learning algorithms in radiology found that 81% showed decreased accuracy on external datasets, with nearly a quarter dropping by 0.10 AUC or more. A 2024 study in Scienceby Chekroud et al. found that clinical prediction models achieved high accuracy within their development datasets but fell to chance-level performance on truly independent samples. Pooling data across multiple trials didn’t fix it.

The most visible example is the Epic Sepsis Model, deployed at hundreds of US hospitals. When Wong et al. externally validated it at the University of Michigan in 2021, it achieved an AUC of 0.63 against Epic’s reported 0.76-0.83. It missed 67% of sepsis cases while generating alerts on 18% of all hospitalized patients.

These are all versions of the same structural problem: the model worked where it was built. It didn’t work where it was sold.

The commercial consequence follows a pattern: year-one renewals look fine. Customers are still in implementation mode, still giving the product the benefit of the doubt. Year two, a cluster of accounts churns. Not one. Five or six. All at once. The company explains it as budget pressure or leadership turnover at the health system level.

When you look at the churned accounts, they share a profile. None of them looked like the original validation population. The model never worked well for them. Nobody knew, because nobody was checking.

If the performance degradation literature is any guide, the gap between internal and external performance is large enough to produce measurable differences in clinical utility across customer sites. That gap is invisible in aggregate renewal data. It only surfaces when you stratify by how closely each customer’s population matches the validation cohort, and most companies don’t.

The diligence question: ask for renewal rates stratified by how closely each customer’s population matches the original validation cohort. If they can’t segment it that way, you’re looking at this combination.

The product is degrading + nobody can explain the outputs = slow death spiral

Health analytics products built on historical data will degrade. Count on it. Coding practices change with annual ICD and CPT updates. Clinical workflows shift when a health system migrates EHRs. Patient populations shift with payer mix dynamics. The signal the model was trained on stops matching the signal it sees in production.

If the product has no mechanism to detect that degradation, the vendor doesn’t know it’s happening. If the product also can’t explain its outputs to end users, the users can’t diagnose the problem either. They just know something feels off. The risk scores don’t match their clinical judgment. The patient lists seem wrong. But they can’t articulate what changed, because the product never explained what drove the outputs in the first place.

What follows is predictable. Clinicians and care managers stop trusting the tool. They work around it. Adoption drops. The vendor reads declining engagement as a training problem. They send onboarding materials. They schedule another QBR. The model keeps degrading. The gap between what the tool recommends and what clinicians observe keeps widening.

The published evidence on CDS adoption supports this pattern. Research consistently shows that a large proportion of clinical decision support alerts are ignored or dismissed, often because clinicians can’t determine whether the recommendation is relevant to their specific patient. A 2025 systematic review in npj Digital Medicine found that clinicians develop workaround strategies within the first year of CDS deployment, and those workarounds persist five years later. The Epic Sepsis Model, again, is instructive: it generated alerts on 18% of all hospitalized patients while missing two-thirds of actual sepsis cases. Clinicians learned to ignore it. The problem was the product, not the training.

I’ve seen this pattern end contracts. The vendor is always surprised when the renewal comes back as a termination. The buyer is never surprised. They’d been working around the tool for months.

The financial signature: adoption metrics (DAU/MAU, action rates on recommendations, override rates) are leading indicators of this combination. If adoption is flat or declining while the company reports stable accuracy metrics, the product may be drifting in ways the vendor’s monitoring doesn’t catch. That gap between the vendor’s internal metrics and the buyer’s actual usage patterns is where this risk hides.

The diligence question: ask for accuracy metrics AND adoption metrics AND override rates, side by side. If accuracy looks stable but adoption is declining, you’ve found the 3+4 combination. The product is degrading in ways the vendor isn’t measuring, and the users can see it even if they can’t name it.

Can’t trace the data + can’t explain the output = institutional risk for the buyer

If a clinical decision support tool recommends a care pathway and the recommendation is questioned, the vendor needs two things: the ability to explain why the model produced that output, and the ability to trace the data that fed it.

If you have one without the other, you can mount a partial defense. You can say “here’s why the model scored this patient this way” even if you can’t trace every input, or you can say “here’s where every data element came from” even if the explanation layer is thin.

If you have neither, the recommendation can’t be defended at any level. Not to the clinician who needs to decide whether to follow it. Not to the buyer’s compliance team. Not to a plaintiff’s attorney asking how a clinical decision was informed by an opaque model running on data of unknown origin.

This combination turns a product-level risk into an institutional risk for the buyer. When the health system’s risk management team gets involved, the question shifts from “should we renew?” to “should we have signed this in the first place?” That’s not a churn conversation. That’s a contract termination with cause, potential legal exposure, and reputational damage for both parties.

For diligence: this combination matters most in products with clinical decision support features, less so in pure reporting or benchmarking tools. If the target sells CDS, ask the team to walk you through a specific recommendation and trace it end to end: what data fed it, where that data came from, and how the output would be explained to a clinician, a compliance officer, and (hypothetically) opposing counsel. If there are gaps at any point in that chain, you’re looking at the 1+4 combination.

Can’t trace the data + lost track of what it’s authorized for = trust event with no remediation path

Data provenance asks: where did this data come from? Consent-use alignment asks: does the current use still fall within the boundaries of how it was originally authorized?

When both fail, you’ve lost both ends of the chain. Origin and permission. The company doesn’t know where a specific data element came from, and it doesn’t know whether the current product feature that uses it is covered by the agreement under which it was shared.

This combination is rare in early-stage companies with one or two data sources and a narrow product. It’s common in growth-stage and scale-stage products that have added data sources, added features, and added revenue models over several years without tracking the cumulative drift between original authorization and current use.

A health system discovers that data shared under a BAA for “quality improvement analytics” is now feeding a product feature that generates benchmarking reports sold to payer clients. The BAA may technically cover it. The health system’s understanding of the relationship does not.

If the vendor can trace the data and show that the BAA language is broad enough, that’s a negotiation. If the vendor can’t trace the data and can’t map the authorization chain, that’s a trust event with no clear remediation. You can’t reconstruct the history well enough to know whether a violation occurred.

In health data, trust events are contract events. One trust event with a large health system buyer can trigger termination, reputational contagion to other customer relationships, and, in a PE portfolio context, contamination of the acquirer’s existing data agreements if the target’s data gets commingled with the platform’s data under incompatible consent frameworks.

For diligence: ask for a map of data sources, authorization bases, and product features that touch each source. If it doesn’t exist, that’s not a documentation gap. That’s the 1+5 combination. The company has been building features on top of data it can’t fully trace or authorize.

What a clean interaction profile looks like

A company doesn’t need perfect scores on every risk. It needs to avoid carrying a critical combination without knowing it.

A clean profile means: if the company has limited validation (Risk 2), it also has drift detection (Risk 3) that will surface performance problems before buyers do. If the company has thin explainability (Risk 4), it at least has strong data provenance (Risk 1) so that challenged outputs can be traced to defensible inputs. If the company has expanded its product features beyond original scope, it has a consent-use alignment map (Risk 5) that tracks authorization basis against current use.

The pattern is complementary coverage. Weakness in one risk is partially mitigated by strength in the risk it compounds with. Perfect scores aren’t the goal. A defensible profile is.

The scoring shorthand

For each of the five risks, rate the company on a four-point maturity scale:

1 = below seed-stage expectations (risk is unacknowledged)

2 = seed-appropriate (risk is acknowledged, addressed manually)

3 = growth-appropriate (risk is addressed with semi-automated infrastructure)

4 = scale-appropriate (risk is addressed with production-grade systems)

Then check the four interaction pairs: 2+3, 3+4, 1+4, 1+5. If both risks in any pair score below 3, flag it. If both score below 2, treat it as a material finding.

A company with 3s across the board and no flagged pairs is a different asset than a company with 3s on three risks and a 1+5 pair scoring 2/1. The average score is almost identical. The risk profile is not.

After the close: what to watch from the board seat

Diligence ends. The deal closes. You take your board seat. And then these same four combinations become the questions you should be asking every quarter, because the risk profile of a health data analytics asset changes as the company grows, adds customers, adds data sources, and adds features.

Validation + drift (2+3). “As we expand into new customer segments, are we tracking performance by how closely each site matches our validation cohort? Where are we weakest, and do we have drift detection covering those sites specifically?” This is the question that catches surprise churn before it shows up in the renewal numbers. If the answer is “we track aggregate performance across all customers,” the board doesn’t have visibility into the segment-level risk.

Drift + opacity (3+4). “What are our adoption and override rates by customer, and are we seeing any divergence between our internal accuracy metrics and how users are actually engaging with the product?” If the CEO reports stable model performance but can’t speak to adoption trends, the death spiral may already be underway. The board should see accuracy and adoption side by side, every quarter. A gap between them is the earliest signal.

Provenance + opacity (1+4). “If a clinician or a compliance officer challenged a specific output tomorrow, could we trace the data that fed it and explain the reasoning behind it, end to end?” This doesn’t need to be asked every quarter. It needs to be asked once, answered honestly, and revisited whenever the product adds a new data source or a clinical decision support feature. If the answer is “not yet,” the board should know the remediation timeline and what’s at stake until it’s closed.

Provenance + consent-use alignment (1+5). “Since the last board meeting, have we added any new data sources, product features, or revenue streams that change how we use existing data? If so, has someone checked whether our authorization basis still covers the current use?” This is the question that prevents the trust event. It’s easy to skip when things are going well. It’s the one that matters most as the product scales and the distance between original data agreements and current product capabilities widens.

These are governance questions, not gotcha questions. They tend not to get asked until something breaks, because board meetings in healthtech are usually focused on growth metrics, pipeline, and regulatory milestones. Product-level risk interactions sit in the gap between what the CEO reports and what the board thinks to ask about.

A note for the CEO in the room

If you’re the operator on the other side of these board questions, the upside of a board that asks them is that you build the muscle to answer them before a customer or a prospect does. Every one of these questions will eventually get asked by someone. A health system’s procurement team during a renewal. A clinical champion who lost confidence in the tool. A prospective buyer’s diligence team. The difference is whether you’ve rehearsed the answer in a board meeting where the stakes are a conversation, or whether you’re hearing it for the first time in a meeting where the stakes are a contract.

The best version of this is a CEO who brings these interaction pairs to the board proactively. Not as a confession, but as a risk register. “Here’s where we have complementary coverage. Here’s where we have a gap. Here’s the plan.” That CEO is easier to back, easier to fund, and easier to acquire than one who hasn’t thought about it and gets surprised when the diligence team shows up with a scoring rubric.

The full framework behind this, including maturity ladders for each risk by company stage and product category, financial signatures for revenue modeling, and the interaction scoring method, is what I use in diligence engagements at Vahana Labs. If you’re evaluating a health data analytics asset and want to pressure-test the product layer before you close, or if you’re sitting on a board and want to build these questions into your governance cadence: arvita@vahanalabs.ai.

For founders reading this: the goal is not to pass this scoring with a perfect 4 on every risk. The goal is to know where you stand and be able to articulate it before your buyer’s diligence team or your board asks. A company that says “we score a 2 on drift detection, here’s our 12-month roadmap to a 3, and here’s what we do manually in the meantime” is in a stronger position than one that has never asked itself the question.

The Harder Question is a series about the questions that don’t get asked during pilots, procurement, and diligence in healthtech, but probably should. More at Operating in HealthTech.

The technology might be real. Some of these tools genuinely work. The problem isn’t the vendors.

The problem is that nobody’s helping you figure out the question that comes before the vendor conversation: is this worth it for my organization, and if so, where do I start?

The question you’re actually asking

I published three buyer’s guides recently — one for RHCs, one for CAHs, one for FQHCs and CHCs. They cover what to look for in AI tools, what to ask vendors, what to put in the contract, and how to know if the tool is working.

The response from safety-net organization leaders has been consistent, and it’s not what I expected. The most common reaction wasn’t “now I know how to evaluate vendors.” It was: “this is helpful, but I’m not even at the vendor evaluation stage yet. I’m still trying to figure out whether AI makes sense for us at all.”

That reaction makes sense when you think about the reality these leaders are operating in.

A CAH CEO with a 1% margin and a nursing staff that’s 40% travelers isn’t going to add a $50K technology subscription without a clear picture of where the value comes from and how it shows up in her financial model. “Reduced documentation burden” isn’t a budget line item. She needs to know: does this let my providers see more patients? Does it reduce my traveler dependency? Does it improve my quality scores? Does any of that translate to dollars given my cost-based reimbursement model? And if I put this on my cost report, will my MAC accept it?

An FQHC COO running 12 sites with medical, behavioral health, dental, and enabling services has a different version of the same problem. He’s got competing priorities from every service line director. The CMO wants documentation tools. The quality director wants prospective UDS data capture. The BH director needs measurement-based care support. The dental director needs dental AI that barely exists yet. The CFO wants to know how any of it maps to PPS economics. And he’s supposed to evaluate vendors when his leadership team hasn’t aligned on what to prioritize?

An RHC practice manager in eastern Oregon is simpler and harder at the same time. She doesn’t have competing service lines. She has 3 providers, no IT person, and a list of problems (documentation, prior auth, credentialing, no-shows) that all feel urgent and none feel researched. She’s seen the demos. She doesn’t know how to evaluate whether the $1,500/month subscription is worth it when she can’t quantify the problem it’s solving.

None of these leaders are unsophisticated. They’re under-supported. The AI conversation in healthcare is happening at the enterprise health system level — big platforms, big budgets, innovation teams dedicated to the question. Safety-net organizations are being asked to figure it out between patients, between board meetings, between everything else.

What the guides don’t cover

The buyer’s guides I published address the evaluation and procurement process — what to ask, what to test, what to require. They assume you’ve already decided what to buy (or at least what category of tool to evaluate).

They don’t address the strategic work that comes before that decision:

Which of my operational problems should I solve with AI? Not all of them are good AI use cases. Some are better addressed with workflow redesign, staffing changes, or EHR configuration fixes. The vendor will tell you their product solves your problem. That doesn’t mean AI is the best way to solve it.

What’s the financial model? Not “AI saves 30 minutes per provider per day” — that’s a vendor stat. The financial model is: does the math work in my reimbursement structure? For a CAH on cost-based, how does this interact with my cost report? For an FQHC on PPS, is the value in cost reduction (vulnerable to rebasing) or quality improvement and access expansion (durable)? For an RHC on the all-inclusive rate, does the value come from clean claims and HCC capture or from something else entirely?

How do I sequence across service lines? An FQHC can’t implement AI across medical, BH, dental, and enabling services simultaneously. What goes first? What depends on what? What builds the foundation for the next phase?

How do I get my leadership team aligned? The CMO and the CFO are evaluating AI from different angles. The quality director cares about UDS data integrity. The BH director cares about Part 2 compliance. The dental director cares about CDT coding support. These aren’t conflicting priorities — they’re complementary — but someone needs to put them in a sequence that makes sense for the organization, not just for each individual leader.

How do I fund it? HRSA grant allowability. RHTP funds (if your state received an allocation and the obligation deadline is approaching). Quality incentive capture. Medicaid match possibilities. The funding landscape for safety-net technology investment is more diverse than most leaders realize, but navigating it requires knowing which doors to open and in what order.

What we’re doing about it

We run cohort workshops for small groups of safety-net organizations — RHCs, CAHs, FQHCs, CHCs, tribal health organizations, behavioral health providers — working through the AI strategy question together.

The format: 3-4 organizations share a full-day working session. Each brings their leadership team (the people with operational accountability — CEO, COO, CMO, CFO, quality director, whoever owns the technology question at your org). The group works shared challenges together. Peer learning matters here because the RHC practice manager in one county is facing the same vendor calls and the same resource constraints as the one in the next county, and neither of them has anyone to compare notes with.

Each organization leaves with deliverables specific to their situation:

A prioritized use case map — which operational problems to address with AI, in what order, based on your workflows, your staffing, your financial model, and what’s actually available in the market. Not every problem needs AI. The map tells you which ones do and which ones don’t.

A vendor evaluation framework — built from the buyer’s guides, customized to your EHR platform, your payer mix, and your priorities. You walk out knowing how to evaluate vendors for the use cases you’ve identified, with the questions, the scorecard, and the contract checklist ready to use.

A financial model — connecting the technology investment to your specific reimbursement structure. Cost report implications for CAHs. PPS and quality incentive math for FQHCs. AIR economics for RHCs. Honest about what’s cash and what’s capacity.

A funding narrative — connecting your technology strategy to available funding. If your state received RHTP funds, the narrative maps your plan to RHTP-eligible initiatives. If HRSA grant funds are the path, the narrative addresses allowability and scope of project alignment. The deliverable is a draft you can use in your funding process, not a generic strategy document that sits in a drawer.

Cost is $5,000 per organization. For most safety-net organizations, that’s less than one month of one traveler nurse. For RHTP-eligible organizations, this investment may qualify as reimbursable technical assistance and planning support under the program.

Who this is for

You’re running a safety-net organization. Vendors are calling. Your board is asking about AI. Your providers are burned out and you know technology should help but you don’t have the bandwidth to research it, the analytical infrastructure to model it, or the strategic framework to sequence it.

You don’t need another vendor demo. You need a day in a room with peers and a facilitator who’s spent 18 years inside healthtech, who understands your reimbursement model, your regulatory constraints, and your workforce reality, and who doesn’t have a product to sell you — just a framework for figuring out what’s worth buying.

If that’s you: cal.com/arvita-tripati/let-s-talk?duration=30

Twenty minutes. No pitch. Just a conversation about whether this fits your situation and your timeline.

The guides are still free

The three buyer’s guides — for RHCs, CAHs, and FQHCs/CHCs — are free and ungated on our site. If you’re already at the vendor evaluation stage, they’re everything you need. Use them.

If you’re at the strategy stage — figuring out what to evaluate before you can use the evaluation framework — that’s what the cohort is for.

I’m Arvita, founder of Vahana Labs. I’ve spent 18 years inside healthcare and healthtech companies like LabCorp, AliveCor, and others. Now I work with both the organizations building AI for healthcare and the organizations trying to figure out whether to buy it. The cohort workshops exist because the second group kept telling me that the vendor evaluation framework was useful but they needed help with the step before it. So we built the step before it.

But your actual problem isn’t running pilots. It’s converting them.

The org chart tells you what you’ve been optimizing for

Look at your 12-person team. Count how many people can build the product, deploy it, and support it technically. Now count how many can navigate a procurement committee, build a CFO case, or map a buying committee beyond your clinical champion.

At most seed-stage healthtech companies, the ratio is 10:1 or worse. Almost everyone is oriented around building and delivering the product. The enterprise sales motion, the part that actually converts pilots to revenue, lives in the founder’s calendar between product reviews and investor calls.

That’s not a staffing shortage. That’s an organizational design choice. You built a team that’s excellent at getting pilots live. You didn’t build a team that’s excellent at getting pilots paid.

Why the next hire feels like it should be technical

The pressure to hire another engineer or implementation person is real. The pilots are live. Clinicians are using the product. There are bugs, feature requests, integration issues. The champion is asking when you can add a feature. The technical team is working weekends.

Meanwhile, the pilot that’s been “in evaluation” for four months sits there. The champion says they’re working on it internally. The procurement questionnaire came back three weeks ago and nobody on your team followed up because everyone was heads-down on the other pilot’s integration issues.

The founder checks in with the champion every two weeks. The champion says positive things. Nothing moves.

Sometimes the bottleneck really is technical. The pilot is stuck because the product is missing a feature the champion needs, or the integration is broken, or the system is too slow for clinical workflows. In those cases, hiring another engineer is the right call.

But here’s how to tell the difference. Ask your champion: “If we fixed every technical issue tomorrow, what happens next?” If the answer is “we’d move to procurement” or “I’d need to get budget approval” or “I’d have to get IT Security to sign off,” the bottleneck isn’t technical. It’s everything that comes after the champion says yes. And nobody on your team is working that problem.

At most seed-stage healthtech companies, the conversion work lives in the founder’s calendar between product reviews and investor calls. The skill set it requires, navigating procurement, building CFO cases, mapping buying committees beyond the champion, managing compliance conversations, is fundamentally different from the skill set that builds and deploys the product. And right now, it’s either not happening or happening in fragments when the founder has a free hour.

The hiring decision you’re actually making

When you open your next req, you’re making an organizational design decision whether you frame it that way or not.

If you hire another engineer: The product gets better. The current pilots run smoother. The implementation queue clears. And the pilot that’s been stuck in procurement for four months stays stuck, because nobody new is working that problem.

If you hire someone who can work the enterprise conversion: The procurement conversations get covered. The CFO case gets built. The stakeholder map gets tracked. But the engineering team keeps working weekends, and the product backlog doesn’t shrink. That’s a real cost.

The standard advice at seed stage is “the founder should be doing sales.” And there’s truth in that. The founder understands the product better than anyone, has the most credibility with buyers, and needs to learn the sales motion firsthand before hiring someone to run it. If you haven’t personally navigated a full procurement cycle at a health system, hiring someone to do it for you is premature. You don’t yet know what good looks like.

But there’s a difference between the founder owning the sales relationship and the founder being the only person doing any conversion work at all. At 12 people, you can’t be in the procurement meeting, the IT Security review, the budget conversation, and the champion check-in for three pilots simultaneously while also running the company. The question isn’t whether you should be selling. It’s whether the conversion motion has enough support around you that the work actually gets done between your other obligations.

At most seed-stage healthtech companies, the answer is no. The conversion work falls through the cracks not because the founder doesn’t care, but because there aren’t enough hours in the week, and nobody else on the team is equipped to pick it up.

Why this is harder than it looks

Three things make this decision genuinely difficult.

The identity problem. You built a technical team because you’re a technical founder. The team reflects your strengths. Hiring an enterprise sales or customer success person means admitting that your personal involvement in sales isn’t enough, and that the skills you’re best at aren’t the ones the company needs most right now. That’s an identity shift, not just a headcount decision.

The board conversation. Your investors are tracking product milestones and pilot count. “We hired another engineer and shipped three features” sounds like progress. “We hired someone to work enterprise conversion” sounds premature at seed stage. The way to reframe this for the board: “We have X pilots live. The bottleneck to revenue isn’t product. It’s conversion. Here’s the specific gap in our team, and here’s what closing it does to our timeline to first contract.” That’s a revenue argument, not a headcount argument. Most boards will fund a faster path to revenue if you make the case that way.

The timing problem. The right time to hire for enterprise conversion is before you need it. By the time the pilot has been stuck in procurement for four months, you’ve already lost momentum. But hiring for conversion when you only have two pilots feels like you’re getting ahead of yourself. The window between “too early” and “too late” is about six months, and most founders miss it.

If your bottleneck is regulatory, the same logic applies

If you’re running a SaMD or device company, the version of this question is structurally identical but the quiet bottleneck is different. Your team is built around engineering and regulatory submissions. Product and QMS. That’s the right team for getting cleared. But cleared isn’t the same as commercial.

Your loud problem is the product backlog and the next submission. Your quiet problem is that the CTO is spending 30% of their time managing the ongoing compliance lifecycle, post-market surveillance, CAPA processes, and cybersecurity documentation instead of shipping product. Every hour the CTO spends on compliance is an hour they’re not spending on the roadmap. But because the CTO is “handling it,” nobody frames it as an organizational gap.

The question is the same: is the next hire solving the problem that’s loud (more engineering capacity), or the problem that’s quietly constraining the person you can least afford to lose time from?

The harder question

Your team is a reflection of the problems you’ve already solved. Getting the product built. Getting pilots live. Getting through a submission. Those problems needed the people you have.

The problem you haven’t solved is different. It needs different people. And every month you delay that hire, the gap between “product that works in a pilot” and “product that generates revenue” gets wider.

The harder question isn’t “who should I hire next?” It’s “am I willing to build a team that’s organized around the problem I haven’t solved yet, even if it means the problem I’m comfortable with gets less attention?”

Most founders aren’t. That’s why pilots don’t convert.

Your board is asking the same questions health systems asked. Add this feature. Launch that AI capability. Scale faster. Build bigger. The harder question is different: what’s the actual relationship between where you’re spending and whether people stay?

The Cost-Clarity Axis Is Where Consumers Live

Here’s what the McKinsey data actually says. Cost accounts for roughly 10% of overall brand strength, but it matters more than any other single factor. It’s 35% higher in impact than the next-closest driver. Clarity, trust, and whether the tool actually solves the problem you said it would solve matter more than whether you have the latest technology or the most features.

Most healthtech companies read this and nod. They get it intellectually. Then they build the opposite.

The pattern repeats: founders and boards choose feature roadmaps based on what’s technically possible, what competitors are doing, or what VCs are excited about. The relationship between that roadmap and whether users stick around rarely gets interrogated. Some companies spend aggressively on features that delight their early adopters and repel their long-tail users. Others add so many capabilities that the core value proposition becomes unclear. A wearable company adds 15 biomarkers when clarity around three would change behavior. A triage platform adds workflow integrations that confuse the nurse trying to use it.

McKinsey shows that consumers using AI tools report higher satisfaction than non-users. The catch: it’s not because of how many features you have. It’s because the tool either works or it doesn’t. And when it works, users know why and know what it costs.

The Stanford Shift: Retention Changes Your Spend

Last month’s Stanford Consumer Health Conference revealed something the VC panel didn’t expect to say out loud. Retention is now more interesting than growth. One investor put it bluntly: “Who IS paying matters more than who WILL pay.” Another GP started evaluating companies on payback period instead of LTV:CAC ratio. The question shifted from “how fast can we acquire” to “who sticks around and why.”

This changes capital allocation completely.

In acquisition mode, you invest in reach, features that widen the funnel, and velocity of new users. In retention mode, you invest in depth, clarity around what you solve, and the relationship between what you promise and what you deliver. These are almost opposite investments.

One founder at the conference manages a community-based fitness brand. When investors pushed to scale from 15 to 30 locations, the answer was immediate: short-term revenue bump, long-term erosion. The thing that makes the community special, that keeps people coming back, doesn’t scale the way your unit economics require it to scale. So you make a choice. You can add another location, or you can stay intimate at scale. You cannot do both.

That’s a board conversation.

The “So What” Problem: Data Without Action Is Worthless

Across every panel at Stanford, one problem kept surfacing. Companies were collecting extraordinary amounts of data without any mechanism to convert that data into behavior change. One app showed users 160 biomarkers. The question nobody asked: then what? Another platform had the best clinical outcomes in its category. Users didn’t believe the results. A sleep platform showed users they had terrible sleep. It offered no path to better sleep. As one founder called it: dorky.

This gets to the harder part of retention. Retention isn’t just about users coming back. It’s about users coming back because they changed something. And behavior change is hard in ways that adding features is not.

Jim from HumanOut framed it simply: telling people what to do is easy. Behavior change requires ecosystem support, community, accountability, human connection, and fun. It requires things that don’t scale the way your cap table wants them to scale. It requires relationship. Most healthtech companies can’t afford relationship at their unit economics. So they compensate with features, with more data, with more personalization, with more technology.

This shows up in the data McKinsey published. Demonstrating innovative care and offering the latest technology ranked lower in consumer preference than cost and clarity. Clarity means: you know what this does and why you should use it. Innovative care is nice. Clarity is what drives adoption and retention.

The Feature Scaling Problem: 1+1 Sometimes Equals 0.8

Chris Palmer from Novos cited research showing that 61% of supplement combinations perform worse than the single strongest component. Only 8% show synergistic effects. The implication is ugly: more features do not equal better outcomes. Sometimes they equal worse outcomes.

Alex from Eternal described two separate impossible problems. Problem one is making something people love. Problem two is scaling it. These require different jobs, different people, different capital allocation, different board conversations. Most companies try to solve both simultaneously. They fail at both.

The feature roadmap that makes sense for Problem One (making something people love) looks like focus, clarity, simplicity, and depth. The roadmap for Problem Two (scaling what you’ve built) looks like integration, breadth, automation, and reach. These are genuinely incompatible at the capital and team level.

Your board is asking: which problem are we solving? The answer determines everything: hiring, spend, positioning, how you measure success.

What Your Board Should Actually Ask

The question for your board isn’t “what feature do we add next?” It’s “what’s the relationship between our retention rate and our feature roadmap? Are we spending in the place that correlates with users staying?”

This requires actual analysis. Pull your cohort retention curves. Look at the features your stickiest users adopted in month one vs your churned users. Look at the features you shipped and whether adoption of those features correlates with retention improvement. Most companies find the correlation is weak or negative. They shipped a lot that moved the needle on neither.

Then ask: “Are we built to solve Problem One (making something people love) or Problem Two (scaling it)? Does our team, capital structure, and board composition align with that choice?” You cannot hire and spend for both. Trying to makes you competent at neither.

Finally: “What’s the cost of our investment?” Not just in money. In complexity, in team attention, in clarity. McKinsey shows consumers weight cost 35% higher than any other factor. But cost isn’t just price. It’s the cost of adoption (how hard is it to understand what this does?), the cost of maintenance (how much work is this to keep using?), and the cost of switching (if I leave, how much effort did I invest in learning this?).

The Next Move

Audit your last 12 months of roadmap. For every major feature, identify whether it improved retention (actual cohort-level data, not self-reported satisfaction). For every feature that shipped without retention impact, ask why you built it. For every feature that did move retention, ask whether you could double down and stop doing other things.

Then ask your board: “Are we still building for acquisition or do we need to reorganize for retention?” The answer changes your hiring, your spend, your positioning, and your capital raise strategy. It changes whether your cost structure makes sense.

The healthtech companies that get this right will look radically different from the ones that don’t. Not because they’re smarter. Because they let data about what actually drives retention inform their investment. That’s the harder question. It’s also the one that determines whether you’re still here in three years, and whether you’re profitable when you get there.

The accountability gap that will define the next wave of healthcare AI litigation

A sepsis prediction model gets FDA 510(k) clearance. The vendor claims 85% sensitivity. Hospitals across the country deploy it.

Then a research team at Michigan Medicine does something unusual: they check. They have the infrastructure to do it -- biostatisticians, data scientists, access to their own patient outcome data, and the institutional support to publish findings that contradict a vendor’s claims. Their results, published in JAMA Internal Medicine: actual sensitivity of 33%. Two-thirds of sepsis cases never triggered an alert.

Most hospitals deploying that same tool couldn’t have run that analysis. A 200-bed community hospital doesn’t have a research team validating vendor performance claims against their own patient population. They’re trusting the number on the spec sheet. And the spec sheet said 85%.

Nurses start ignoring the alerts that do fire because most are false positives. A patient deteriorates. The family sues.

Who’s liable?

The vendor who claimed 85% and delivered 33%? The hospital that deployed without independent validation? The CTO who approved the purchase? The CMO who signed off on the clinical workflow? The nurse who ignored the alert because the last forty were wrong? The board that approved the AI budget without asking what governance looked like?

Under current U.S. law, the answer is clear and unsatisfying: the physician. The Federation of State Medical Boards said so explicitly in April 2024. Clinicians, not vendors, bear liability for AI-generated errors. Courts default to the “reasonable physician” standard whether AI was involved or not. No existing federal law assigns liability to AI developers when their tool contributes to patient harm.

That legal reality creates a problem for everyone in the chain, not just clinicians.

The accountability gap is structural

The Epic case wasn’t a one-off. FDA took no enforcement action -- no recall, no updated labeling. The tool remained deployed at hospitals that had no way to run the same analysis Michigan Medicine did.

Here’s the structural problem: healthcare AI involves at least three responsible entities (developers, deployers, and clinicians), but existing law assigns almost all accountability to one of them.

Developers make design choices, select training data, define performance claims, and decide what limitations to disclose. They control whether the model is locked or continuously learning. They write the vendor contracts. Those contracts almost always include indemnification language that pushes liability downstream.

Health systems make procurement decisions, choose how to validate (or not), integrate AI into clinical workflows, decide how much training clinicians get, and set policies on when to override. The CTO, CMIO, and procurement team all touch the decision. The board approves the budget.

Clinicians are the end users. They see the recommendation. They accept it or override it. In the eyes of current law, they are responsible for the outcome regardless of what the algorithm said.

That means the people with the most control over the AI (developers) carry the least legal liability. The people with the least control over the AI (clinicians) carry the most. And the institution in the middle (the health system) is in a gray zone that existing insurance products don’t cleanly cover.

The insurance gap is real

If you’re a health system deploying clinical AI, ask your risk manager this question: which policy responds when our AI contributes to patient harm?

You may not like the answer. Medical malpractice insurance covers clinical judgment. Tech errors and omissions insurance covers technology failures. When an AI-influenced clinical decision causes harm, the claim falls into a gap: too technical for malpractice, too clinical for tech E&O.

Some carriers have started introducing exclusions for unregulated AI applications. Others require AI-specific training for clinicians to maintain coverage. A handful are building specialized products to bridge the gap. But most health systems haven’t asked the question yet, which means they’re deploying AI tools under the assumption that they’re covered when they may not be.

For health system leaders, this isn’t an insurance question. It’s a board-level governance question. If you can’t answer “who is liable and who is insured” for every AI tool in clinical use, you have an exposure your board doesn’t know about.

The double bind for clinicians

Here’s the bind clinicians are walking into. Courts haven’t yet established a clear standard, but the direction is pointing toward a world where physicians can be held liable for following AI recommendations that turn out to be wrong AND for failing to use AI tools that are available.

A 2024 study found that GPT-4 outperformed physicians using GPT-4 in complex diagnostic cases. The human-AI hybrid actually underperformed pure AI in some contexts. If that finding holds up, plaintiff’s attorneys will eventually argue: “You had a tool that would have caught this, and you chose not to use it.”

That puts clinicians in a position where using AI creates liability (if it’s wrong and they don’t catch it) and not using AI creates liability (if it would have been right and they didn’t consult it). This is not a stable arrangement. It will break, either through legislation, case law, or insurers refusing to cover AI-related claims.

For health system leaders and board members, the clinician’s double bind is your problem. If your clinicians don’t trust the AI tools you’ve deployed, they’ll override them defensively. If they trust them too much, they’ll miss errors. Either way, you’re carrying the risk. And if you haven’t trained, documented, and governed the use of these tools, you’ve left your clinicians exposed.

What governance actually looks like (and what it costs to skip it)

The World Health Organization found in November 2025 that legal uncertainty is the leading barrier to AI adoption across Europe, and fewer than one in ten countries have liability standards clarifying responsibility when an AI system errors. The U.S. is in the same position. No coordinated national approach for assigning responsibility exists.

That means the institution has to build its own framework. And if you’re running a system with margin pressure, staffing shortages, and a board that wants AI deployed to reduce costs, the word “framework” probably sounds like something you can’t afford.

Here’s what you can’t afford: the first AI-related malpractice verdict against a health system that had no governance in place. No one knows what that number will be yet, but the comparables are instructive. Traditional malpractice verdicts involving diagnostic errors routinely run $2M to $10M. Add a vendor who claimed 85% sensitivity and delivered 33%, a health system that never independently validated, and a discoverable email chain showing the board approved the AI budget without asking about governance, and the damages multiply. Punitive damages become plausible. And every other health system deploying the same tool becomes the next target.

The cost of minimum viable governance is a fraction of one settlement. Here’s how to scale it:

First 30 days: inventory and insurance

One person, half their time.

Week 1-2: Inventory every AI tool in clinical use. Not IT’s list. The actual tools clinicians are interacting with. Include anything making recommendations, flagging risks, or generating documentation that enters the medical record. You’ll probably find tools nobody centrally approved.

Week 3: Call your risk manager. Ask: “Which policy responds when AI contributes to patient harm?” Get the specific language. If there’s an exclusion, ambiguity, or silence, escalate to the board.

Week 4: For each tool, answer one question: did we validate this on our patient population, or did we rely on the vendor’s numbers? If you’re an academic medical center with research infrastructure, you may be able to run your own validation. Most systems can’t. That’s not a failure -- it’s a reality that makes your contract terms and vendor selection criteria more important, not less. List the gaps.

You now have an inventory, an insurance assessment, and a validation gap analysis. That’s enough to brief the board and request resources for the next phase.

Months 2-6: contracts, classification, and override audit

Risk classify every tool on the inventory. Tier 1: influences clinical decisions (diagnostic AI, clinical decision support). Tier 2: touches clinical workflows but doesn’t recommend (scheduling, documentation). Tier 3: administrative (billing, coding). Match oversight intensity to tier.

Renegotiate contracts for Tier 1 tools. Your vendor agreement needs to specify subgroup performance disclosure (how does the model perform on your patient population, not theirs), change notification (when the model updates, you know), audit logging (every recommendation is traceable), and incident reporting obligations. If your contract doesn’t address these, it’s not a contract. It’s a hope.

Audit override design. How your clinicians interact with AI recommendations is a liability input. If accepting takes one click and overriding requires extra documentation, supervisory flags, and 5x the time, you haven’t built oversight. You’ve built friction designed to suppress disagreement. In a malpractice case, a plaintiff’s attorney will ask whether the clinician was truly able to override. If the system architecture made acceptance the path of least resistance, the vendor’s defense (”the clinician should have caught it”) weakens considerably. Check your acceptance rates. If they’re above 95%, that’s not proof the AI is accurate. It’s evidence the human may have stopped reviewing. And that metric, if you’re tracking it, becomes a discoverable document.

This pattern is already playing out outside healthcare. In December 2025, Amazon’s AI coding assistant Kiro autonomously deleted and recreated a production environment, triggering a 13-hour AWS outage. The tool bypassed standard two-person approval because it inherited an engineer’s elevated permissions. Amazon’s response: “user error, not AI error.” The human didn’t configure the guardrails properly, so the human is responsible. That’s the same defense healthcare AI vendors will use when a clinical tool harms a patient: the clinician should have caught it. But if the system is designed to give AI agents the authority to act autonomously, calling it human error when they act autonomously is a framing choice, not an analysis.

(For a deeper look at how oversight becomes theater, see my earlier piece: “You’re Measuring the Wrong Thing.”)

Months 6-12: monitoring, incident response, and documentation

Drift monitoring. AI models degrade over time as patient populations, workflows, and data patterns shift. Someone has to be watching performance metrics continuously, not annually. Define revalidation triggers: any material change to the software, the workflow, the hardware it runs on, or the population it serves.

Incident response. When (not if) the AI fails, who diagnoses it? Who has the authority to pause the tool? How fast can you revert to the non-AI workflow? If you can’t answer these questions, you’re running a clinical AI deployment without a safety net. Run a tabletop exercise. Simulate a Tier 1 tool failure and see how long it takes your team to detect, pause, and revert.

Documentation. Every AI-influenced clinical decision needs an audit trail. Not because regulators are asking for it today, but because plaintiff’s attorneys will ask for it tomorrow. “What did the AI recommend? What did the clinician do? Was there a documented rationale for the override or acceptance?” If you don’t have that trail, discovery is going to be painful.

One note on what you’re building here: governance frameworks, once documented, become discoverable in litigation. That’s not a reason to avoid building them. It’s the opposite. A health system with a documented governance framework that followed it has a defensible position. A health system with a documented framework that ignored it has a worse position than one that never built it. And a health system with no framework at all is the easiest target. The act of governing is the protection. The document is the evidence you did.

Mass General Brigham runs dozens of AI models in production with a structured governance process. Mayo Clinic has a dedicated AI governance structure. You don’t need to replicate their scale. But the fact that peer institutions have established standards means “we didn’t have a framework” is increasingly hard to defend.

What this means for healthtech companies

If you’re selling AI into health systems, the accountability gap is your problem too, even if the law doesn’t currently assign you liability.

Your customers are waking up to this. The sophisticated ones are already asking for subgroup performance data, external validation results, model update notifications, and contractual commitments on incident response. The unsophisticated ones will start asking after the first high-profile malpractice verdict.

The companies that get ahead of this will build governance into the product, not as a feature to sell but as infrastructure that makes adoption possible. Audit logging, drift alerts, performance dashboards segmented by your customer’s patient population, clear documentation of what the model does and doesn’t do. That’s not compliance overhead. That’s what gets you past procurement.

The companies that don’t will find that the liability vacuum eventually fills, and when it does, the vendor agreements that pushed all risk downstream won’t hold up the way your legal team hoped.

What this means for investors

If you’re doing diligence on healthcare AI companies, the liability shift changes the math.

The current state benefits vendors. Right now, all liability sits with clinicians and health systems. That means your portfolio companies carry minimal legal risk from AI errors. Vendor contracts push risk downstream. Insurance is the health system’s problem. This is why most healthcare AI companies look clean in diligence: the risk is real but it’s sitting on someone else’s balance sheet.

That’s going to change. The EU AI Act already assigns obligations to developers of high-risk AI. U.S. state legislatures are drafting vendor-side requirements. Product liability theories (tested in the Raine and Garcia cases, currently against consumer AI companies) will eventually reach clinical AI vendors. When a vendor claims 85% sensitivity and delivers 33%, the product defect argument writes itself.

When shared liability arrives, here’s what shifts:

Margins. Governance infrastructure (audit logging, drift monitoring, incident response, performance reporting per customer population) costs money to build and maintain. Companies that haven’t built it will need to, compressing margins. Companies that already have it will carry a cost advantage because they amortized the investment across earlier customers.

Insurance costs. If vendors carry liability, they’ll need coverage. Healthcare AI-specific insurance products are nascent and pricing is uncertain. Budget for this as a line item, not as zero.

Sales cycles. Buyers will demand governance capabilities as procurement requirements. Companies without them will lose deals to companies with them. This is already happening at the most sophisticated health systems. It will become standard.

Contract risk. The indemnification clauses in your portfolio companies’ vendor agreements were written in a liability vacuum. When that vacuum fills, those clauses will be tested. Review them now. If the contract pushes all risk to the buyer and the product fails, a court may find that clause unconscionable, especially if the vendor controlled the design, the training data, and the performance claims.

Diligence questions to add:

Beyond “does this company have audit logging,” ask:

1. What’s the acceptance rate across deployed customers? If it’s 95%+, the human oversight the company relies on in its risk narrative may not be functioning.

2. Has any customer independently validated performance on their population? What were the results vs. the vendor’s claims? If the answer is “no customer has validated independently,” ask why. Most can’t -- they lack the research infrastructure. That means the vendor’s performance claims are untested in production, and the company’s entire clinical narrative rests on internal data.

3. What happens when the model is updated? Are customers notified? Do they have the ability to test before the update goes live?

4. What’s the incident response plan when the AI is wrong in a clinical context? Has it ever been triggered?

5. Does the company carry AI-specific liability insurance, or is it relying entirely on downstream indemnification?

The companies that can answer these questions cleanly are the ones that will survive the liability shift. The ones that can’t are carrying risk they haven’t priced.

The board conversation

If you’re on a board or advising one, here are the questions to ask at the next meeting:

1. How many AI tools are currently deployed in clinical workflows, and who approved each one?

If the answer is “we’re not sure,” that’s the problem.

2. For each tool, do we have external validation data on our patient population?

Not the vendor’s validation. Yours.

3. What happens when one of these tools is wrong? Who catches it, who pauses it, and who decides when to restart?

If the answer involves the word “manual” more than twice, your incident response plan is a person, not a process.

4. Does our insurance cover AI-influenced clinical decisions?

Ask the risk manager to show you the specific policy language. If there’s an AI exclusion or ambiguity, the board needs to know before a claim arrives.

5. Who owns AI governance at this organization?

Not “who uses AI tools.” Who owns the governance function? If the answer is “it’s shared across IT, clinical, legal, and compliance,” it’s owned by nobody.

Where this is heading

The current legal vacuum won’t last. The EU AI Act classifies most clinical AI as high-risk, requiring rigorous oversight. State legislatures in the U.S. are drafting AI-specific statutes. Malpractice insurers are rewriting policies. Plaintiff’s attorneys are building the template for the first wave of AI-related malpractice claims.

When aviation automated cockpits, it took crashes and decades of litigation before fault was distributed across pilots, systems, and manufacturers. Healthcare doesn’t have to repeat that timeline. The precedents exist. The frameworks are published. The WHO, the EU, and a growing number of legal scholars have described what shared accountability looks like. The question is whether health systems and vendors build it voluntarily or wait for a verdict to build it for them.

The organizations that build governance now will be positioned for whatever framework emerges. The ones that don’t will be the case studies the framework is built around.

The question isn’t whether your AI will be wrong. It’s whether you’ll know who’s responsible when it is.

AI automation frees up workforce capacity. Leaders face a choice:

Option A: Reduce — Capture efficiency gains through headcount reduction

Option B: Reinvest — Redeploy freed capacity into higher-value work, including AI oversight

Most companies default to Option A because the savings are immediate and quantifiable, the costs of Option B are upfront and uncertain, and “fiduciary duty” is invoked as if it mandates cost-cutting.

But this math is wrong. Companies are dramatically underestimating the total cost of ownership of AI systems and cutting the very people they’ll need to keep those systems working.

The Hidden Cost: AI Isn’t “Set and Forget”

When companies model AI ROI, they calculate licensing/compute costs, implementation costs, and training costs.

What they don’t calculate:

Drift monitoring → Detecting when model performance degrades over time. Requires data scientists and domain experts.

Retraining cycles → Updating models as data patterns change. Requires ML engineers and SMEs for validation.

Edge case handling → Managing the 5-15% of cases AI gets wrong. Requires domain experts and experienced staff.

Output QA → Reviewing AI outputs for errors, bias, hallucinations. Requires people who know what “good” looks like.

Feedback loops → Capturing corrections to improve the model. Requires end users and process owners.

Compliance/audit → Documenting AI decisions for regulatory review. Requires compliance, legal, and domain experts.

Incident response → Handling AI failures when they occur. Requires people who understand the process end-to-end.

Here’s the catch: The people best positioned to do this work are often the same people whose “routine” tasks got automated.

The paralegal who reviewed documents for 500 hours knows what a good review looks like. The imaging tech who read thousands of scans knows what the AI is likely to miss. The underwriter who processed loans for a decade knows which edge cases matter.

When you cut them, you lose your AI oversight capacity.

The Total Cost of Ownership Gap

What Companies Model

Software licensing: $XXX,XXX/year Implementation: $XXX,XXX one-time Initial training: $XX,XXX → Total Year 1: $X.XM

Savings from headcount reduction: 10 FTEs × $80K = $800K/year → Net savings: $XXX,XXX/year ✓

What Companies Miss

Software licensing: $XXX,XXX/year

Implementation: $XXX,XXX one-time

Initial training: $XX,XXX

Drift monitoring: $XX,XXX/year (WHO?)

Retraining cycles: $XX,XXX/year (WHO?)

Edge case handling: $XXX,XXX/year (WHO?)

Output QA: $XX,XXX/year (WHO?)

Feedback loops: $XX,XXX/year (WHO?)

Compliance/audit: $XX,XXX/year (WHO?)

Incident response: ???? (WHO?)

Model failure costs: ???? (unmodeled) → Total Year 1: $?.?M

Savings from headcount reduction: 10 FTEs × $80K = $800K/year

Minus rehiring for AI ops: 3 FTEs × $120K = -$360K/year

Minus recruiting costs: -$90K

Minus ramp time (6mo to productivity): -$180K

Minus knowledge loss: -???? → Net savings: Much less than you thought

The Expertise Paradox

Here’s what leaders miss:

The work you’re automating built the expertise you need to oversee the automation.

Document review is “tedious” — but it’s also how paralegals develop judgment about what matters in a case.

Reading scans is “repetitive” — but it’s how imaging techs learn to spot the subtle anomalies.

Processing claims is “routine” — but it’s how adjusters develop intuition for fraud patterns.

When you automate the “routine” work and cut the people who did it, you lose the expertise to QA the AI’s output. You lose the institutional knowledge of edge cases. You lose the pattern recognition that catches AI errors. You lose the feedback loop that improves the model.

Then you try to hire “AI oversight specialists” who don’t have domain expertise. And you wonder why your AI quality degrades.

The Framework: Six Lenses

Lens 1: Capacity Analysis

Question: What exactly did automation free up?

10-30% of many people’s time → Natural reinvestment into AI oversight + higher-value work

50%+ of some people’s jobs → Role redesign needed. New job is part AI oversight, part elevated work

100% of a role → Rare if you’re honest about AI ops needs. You’re likely underestimating oversight requirements

Diagnostic questions:

• How many FTE-equivalents did automation free up?

• What’s our realistic estimate of AI oversight needs (drift monitoring, QA, edge cases)?

• Does freed capacity exceed or fall short of oversight needs?

Lens 2: AI Operations Requirements

Question: What does this AI actually need to function well over time?

Document processing → Medium drift risk. Quarterly retraining. 5-10% edge case volume. High QA intensity.

Image/diagnostic AI → High drift risk. Monthly retraining. 10-15% edge case volume. Very high QA intensity.

Predictive/scoring AI → High drift risk. Monthly retraining. 5-10% edge case volume. High QA intensity.

Conversational/GenAI → Very high drift risk. Continuous retraining. 15-25% edge case volume. Very high QA intensity.

Workflow automation → Low drift risk. Annual retraining. 2-5% edge case volume. Medium QA intensity.

Diagnostic questions:

• What’s the expected drift rate for this AI?

• What’s our retraining plan and who executes it?

• What percentage of outputs will need human review or handling?

• Who validates that the AI is still performing as intended?

• What’s our incident response plan when (not if) the AI fails?

Output: AI Operations staffing requirement estimate

Lens 3: Skills Adjacency for AI Roles

Question: How close are affected workers to the AI oversight roles you’ll need?

Data entry clerk → Can become: AI output QA specialist. Skills gap: Learn AI tools, QA protocols. Reskill time: 4-6 weeks.

Paralegal → Can become: AI output reviewer, edge case handler. Skills gap: Learn AI interface, escalation criteria. Reskill time: 4-8 weeks.

Claims processor → Can become: Exception handler, model feedback analyst. Skills gap: Learn AI interface, escalation criteria. Reskill time: 4-6 weeks.

Imaging tech → Can become: AI QA specialist, drift monitor. Skills gap: Learn AI metrics, review protocols. Reskill time: 6-10 weeks.

Junior analyst → Can become: Model performance analyst, retraining coordinator. Skills gap: Learn ML basics, monitoring dashboards. Reskill time: 8-12 weeks.

Key insight: Domain expertise is the hard part. AI tools can be taught. The person who’s done 10,000 document reviews can learn to QA AI outputs in weeks. The AI specialist who’s never done document review takes months to develop judgment.

Diagnostic questions:

• Which affected roles have domain expertise that transfers to AI oversight?

• What’s the reskilling investment to bridge the gap?

• Is it faster/cheaper to reskill existing staff or hire AI specialists without domain knowledge?

Lens 4: Institutional Knowledge Valuation

Question: What do these people know that the AI needs to succeed?

Relational knowledge → Client relationships, internal networks, trust. Loss cost: High — takes years to rebuild.

Procedural knowledge → How things actually get done (vs. how they’re supposed to). Loss cost: Medium — can be documented but rarely is.

Contextual knowledge → Why decisions were made, historical failures, tribal knowledge. Loss cost: High — often invisible until it’s gone.

Cultural knowledge → How to navigate the organization, unwritten rules. Loss cost: Medium — affects new hire productivity.

Diagnostic questions:

• If this person left tomorrow, what would we lose that isn’t documented?

• How long would it take a new hire to reach equivalent effectiveness?

• Are there client relationships that would be damaged or lost?

• Is this person a “go-to” that others rely on informally?

Lens 5: Full-Cost Economics (AI-Adjusted)

Question: What’s the true 3-year cost comparison, including AI operations?

Reduce Now

Year 1: Severance + AI licensing + (no AI ops hires yet)

Year 2: AI licensing + hire AI ops specialists (no domain expertise) + recruiting costs + ramp time + AI quality degradation begins

Year 3: AI licensing + continued AI ops salaries + compliance/audit findings + customer impact from AI errors + possibly rehiring domain experts at premium

Reinvest Now

Year 1: Reskilling program + productivity dip during transition + AI licensing + retained salary (AI ops roles)

Year 2: AI licensing + AI ops salaries + AI quality maintained

Year 3:AI licensing + AI ops salaries + knowledge retained + no recruiting costs

The question most companies don’t ask:

“What’s the cost of AI errors over 3 years if we don’t have domain experts in the oversight loop?”

Lens 6: Failure Scenario Planning

Question: What happens when the AI fails — and who fixes it?

AI systems fail. Not if, when. Common failure modes:

Drift → Model accuracy degrades 15% over 6 months. Response requires: Detection capability + retraining capacity.

Edge case explosion → New scenario AI wasn’t trained on. Response requires: Domain experts who recognize it.

Hallucination/error → AI produces confidently wrong output. Response requires: QA that catches it before customer impact.

Adversarial input → Bad actors learn to game the system. Response requires: People who understand the domain well enough to spot manipulation.

Cascading failure → AI error feeds into downstream systems. Response requires: End-to-end process knowledge.

Diagnostic questions:

• What’s our detection plan for each failure type?

• Who has the expertise to diagnose and fix each failure type?

• What’s the cost of delayed response (hours? days?) to each failure type?

• If we cut domain experts, who handles failures?

The Decision Matrix

After working through the six lenses, plot each affected role/group:

High domain expertise + High skills adjacency to AI ops → REINVEST. Clear case — these are your ideal AI ops candidates.

High domain expertise + Low skills adjacency → REINVEST. Worth the reskilling investment because domain knowledge is hard to replace.

Low domain expertise + High skills adjacency → EVALUATE. May not need deep domain knowledge for this AI ops function.

Low domain expertise + Low skills adjacency → REDUCE. This is the clearest case for reduction, if AI ops needs are truly low.

The AI Workforce Transition Model

Instead of: Automate → Cut headcount → Pocket savings

Consider: Automate → Redesign roles → Redeploy to AI ops + higher-value work

Before Automation: 10 FTEs doing routine work

After Automation:

• 0 FTEs doing routine work (AI does it)

• 3 FTEs doing AI oversight (QA, edge cases, drift monitoring)

• 4 FTEs doing higher-value work (client strategy, complex cases, growth)

• 3 FTEs reduced (natural attrition, voluntary transition)

Net result: AI handles routine work. Quality maintained through expert oversight. Capacity freed for growth. Headcount reduced modestly through attrition. Institutional knowledge retained. AI ops capability built.

The Reinvestment Playbook: AI-Specific

1. Map the AI Operations Roles

Before deciding who to keep, define what AI oversight actually requires:

AI Output Reviewer → QA samples, flag errors, handle escalations

Edge Case Handler → Process exceptions AI can’t handle

Model Performance Monitor → Track drift, accuracy, trigger retraining

Feedback Loop Operator → Capture corrections, improve training data

Incident Responder → Diagnose and fix AI failures

Compliance Documenter → Maintain audit trail, regulatory reporting

2. Assess Individual Readiness

Not everyone will make the transition. Assess aptitude for new skills, willingness to change, and learning velocity.

Plan for 10-20% attrition during transition — some will self-select out.

3. Design the Reskilling Program

Weeks 1-2: AI fundamentals — how the model works, what it does/doesn’t do well

Weeks 3-4: QA protocols — how to review outputs, what to look for, escalation criteria

Weeks 5-6: Tools training — monitoring dashboards, feedback interfaces, documentation

Weeks 7-8: Shadowing — work alongside experienced AI ops staff (or pilot carefully)

Week 9+: Independent work with supervision

4. Create Transition Milestones

Don’t make it open-ended. Define clear checkpoints:

Week 4: Completed foundational training Week 8: Shadowing complete, first independent work Week 12: Carrying partial load in new role Week 24: Fully productive in new role

5. Communicate the “Why”

Employees need to understand why the change is happening, why reinvestment was chosen over reduction, what’s expected of them, what support is available, and what happens if the transition doesn’t work.

Key Messages for Leadership

1. AI has a Total Cost of Ownership that most companies underestimate.

Licensing and implementation are the visible costs. Drift monitoring, retraining, QA, edge case handling, and incident response are the hidden costs. If you don’t staff for them, you pay in AI quality degradation instead.

2. The people you’re about to cut are your future AI ops team.

Domain expertise is the hard part. AI tools can be taught in weeks. Judgment about what “good” looks like takes years to develop. The paralegal who reviewed 10,000 documents is your best AI output reviewer.

3. “Fiduciary duty” doesn’t mean “cut costs.” It means “create long-term value.”

Cutting domain experts to capture short-term savings, then watching AI quality degrade, then hiring AI specialists at a premium, then realizing they don’t have domain knowledge, then having compliance findings and customer complaints — that’s not fiduciary duty. That’s short-term thinking masquerading as discipline.

4. The right model is Redesign, not Reduce.

Automate the routine work. Redeploy the people to AI oversight + higher-value work. Reduce headcount modestly through attrition. Retain institutional knowledge. Build AI ops capability. That’s how you capture automation value sustainably.

What This Framework Doesn’t Do

This framework doesn’t make the decision for you — it structures the analysis; judgment is still required.

It doesn’t guarantee reskilling will work — some transitions fail. Plan for that.

It doesn’t apply to all situations — severe financial distress may require cuts regardless.

It doesn’t address policy-level solutions — UBI, social safety nets, and industry-level transitions are beyond scope.

How to Use This

For a single team/function: Work through all six lenses. Plot on decision matrix. Make recommendation with supporting analysis.

For an organization-wide AI transformation: Apply framework to each affected function. Aggregate into workforce transition plan. Identify where reinvestment makes sense vs. where reduction is appropriate. Build reskilling infrastructure for reinvestment cases.

For board/leadership presentation: Use key messages. Show that both paths were analyzed rigorously. Explain the choice with full-cost economics, not just immediate savings.

The Bigger Point

This framework exists because “fiduciary duty” has been misused as an excuse for reflexive cost-cutting.

Fiduciary duty means creating long-term value. Sometimes that means cutting costs. Sometimes that means investing in people.

The question isn’t whether you can reduce headcount after automation. You can.

The question is whether you should — given the full costs, the strategic context, and the kind of company you want to be.

This framework helps you answer that question honestly.

The VA didn’t have bad AI. They had an incomplete cost model. They budgeted for the tool, not for the oversight infrastructure the tool required.

That same gap is sitting in most health system board presentations right now. Here are three questions that close it.

Three Questions for Your Next Board Agenda

1. “For each AI tool we’ve deployed, can management present the full 3-year total cost of ownership, not just the vendor proposal?”

2. “Before we approve any AI-related headcount reduction, can management present a 12-month comparison of cutting vs. redeploying freed capacity, with break-even timelines for both?”

3. “Who is monitoring our AI systems for drift, and what’s our plan when a model needs retraining and the people who understood the underlying process are gone?”

If your management team can answer all three with specifics, you have a governance-ready AI strategy. If they can’t, keep reading.

The Environment These Decisions Are Being Made In

Private equity investment in healthcare grew from $5 billion in 2000 to $104 billion in 2024. Many health system boards now include investor directors operating under explicit EBITDA mandates with 3-7 year exit timelines. Median hospital operating margin was 4.9% in 2024, but 40% of hospitals are still running at a loss. The One Big Beautiful Bill Act cuts roughly $1 trillion in federal healthcare spending over the next decade, primarily from Medicaid. Hospitals are already responding with layoffs: Vanderbilt (650 positions), UC San Diego (230), Yale New Haven (150).

In this environment, when a CFO presents an AI tool that automates 70% of a task and suggests reducing headcount by a corresponding amount, the math looks clean and the board approves.

The conclusion might be right. Sometimes headcount reduction is the right call. But the data behind the decision is almost always incomplete.

The Governance Gap

Fiduciary duty of care is a process standard, not an outcome standard. The AHA’s governance guidance and the NACD’s director oversight principles both frame it the same way: boards satisfy their duty through informed, deliberative decision-making based on adequate information. A board that reviews full cost data, considers alternatives, and decides to reduce headcount has met that standard. A board that approves cuts based on a vendor’s pricing proposal and a labor savings projection has not, regardless of whether the cuts turn out to be the right move.

The distinction matters because most AI cost projections presented to boards cover less than half the actual spend. The vendor proposal shows licensing and initial integration. It doesn’t show what appears in month 6 and never stops: model drift monitoring, retraining cycles, re-validation after each retrain, the human oversight layer, integration maintenance every time an EHR vendor pushes an update, and compliance costs that add 20-30% to baseline operational budgets.

McKinsey’s research on AI adoption puts net savings at 5-10% of total costs when implementation goes well. Their surveys also show that 68% of organizations underestimate data preparation and retraining costs, and that change management costs regularly exceed technical investment by a 3:1 ratio.

When you add these layers together, the “savings” from cutting 10 FTEs look different. You haven’t eliminated cost. You’ve traded labor costs you can see and predict for AI maintenance costs you can’t, and you’ve removed the people who were catching errors along the way.

The full cost model, broken out by layer with ranges and vendor questions, is in part 3 of this series.

Overstaffed or Mis-deployed?

Before approving cuts, boards should require management to distinguish between two different situations.

Overstaffed: The function has more people than the work requires, even after AI. Freed capacity doesn’t map to revenue-generating work. Skills don’t transfer to higher-value activities. Reduction is appropriate.

Mis-deployed: The people are doing work below their capability because the organization never had the capacity to redeploy them. Nurses spending 25% of shifts on documentation. Revenue cycle analysts working individual denials instead of analyzing denial patterns upstream. Supply chain staff doing manual inventory instead of negotiating vendor rates. HR coordinators processing credentialing paperwork instead of building retention programs.

When AI frees capacity in mis-deployed roles, the question is whether that capacity can redirect toward work that generates revenue or reduces risk. In most cases it can, and the payback hits within the fiscal year, not 18 months later.

The cut vs. redeploy comparison framework, including which role transitions have strong evidence and which don’t, is in the TCO toolkit. Boards should ask management to present both scenarios side by side before approving either one.

The Downside That Doesn’t Show Up in the Savings Projection

A 2025 JAMA study found PE-owned hospitals showed a 13.4% increase in emergency department deaths and a 25% increase in hospital-acquired conditions after acquisition. Seven of the eight largest healthcare bankruptcies in 2024 were PE-backed.

The EBITDA mandate is real. So is the downside of pursuing it through staffing cuts alone. Cutting headcount on incomplete cost data while Medicaid revenue is falling is a governance risk and a financial risk at the same time: you lose the institutional knowledge, absorb the hidden AI costs you didn’t budget for, and face the revenue pressure with a thinner team.

A board that asks the three questions at the top of this piece and still decides to reduce headcount has exercised its duty of care. A board that skips those questions has a governance gap that no vendor savings projection can close.

If you're a VP of Product, CPO, or Head of Product, you're not just navigating a new set of tools, you’re navigating a fundamental shift in how product strategy is formed, how decisions are made, and how your leadership is felt.

That said, this shift isn’t uniform. For some organizations, AI means a handful of copilots and smarter search. For others, it’s redefining the core product and operating model. Regardless of where you are on the spectrum, one thing is clear: the ground beneath the product executive’s feet is moving.

Here’s my take on what that looks like and how to lead through it.

1. From Decision-Maker to Decision-Orchestrator

The classic picture of a product executive is someone with strong judgment, someone who can synthesize ambiguous input, weigh tradeoffs, and make the call. That hasn’t gone away. But with AI systems making or mediating more decisions, the role is evolving from deciding well to designing the system that decides well.

The job is to:

• Determine which decisions should be human, machine-assisted, or automated

• Build in escalation paths and override logic

• Audit for blind spots and edge cases

This isn’t abdication. It’s orchestration. And while that’s always been part of the job for good leaders, AI raises the stakes and complexity of getting it right.

2. The AI Strategy Is The Product Strategy

AI isn’t a feature layer. It’s a strategic foundation: for differentiation, defensibility, operational scale, and customer experience.

Product leaders are increasingly responsible for:

• Deciding whether to fine-tune, prompt, or partner

• Understanding model risk, especially in regulated industries

• Framing what “good” looks like when outputs are probabilistic

• Partnering with legal and compliance on IP, explainability, and governance

These aren’t net-new skills for most execs. They’re extensions of familiar responsibilities (product-market fit, reliability, ethical decision-making) now applied to a more complex, opaque, and high-leverage medium.

And critically, this isn’t about AI for AI’s sake. It’s about customer value:

Is this feature helping someone make a better decision? Accomplish a task faster? Gain trust in a system they used to be skeptical of?

If you can’t tie the AI back to the user outcome, you’re not leading product, you’re chasing novelty.

3. Product Scope Now Includes the Operating Model

AI is not just changing what gets shipped, it’s changing how the company works.

Internal systems that used to be out of scope for product now represent strategic leverage:

• Support agents using LLMs to triage cases

• Ops teams generating documentation on the fly

• Clinical reviewers co-piloted by AI classifiers

• Test engineers using agents to create QA scripts

These aren't just "efficiency plays." They’re part of the customer experience—because they affect turnaround time, trust, compliance, and scale.

And here’s the shift: the most impactful product work may be happening internally, in invisible systems that never show up on a roadmap.

If you’re not involved, you’re leaving impact (and risk) on the table.

4. You’ll Need to Invent New Metrics

AI systems don’t fail the way traditional software does. There’s no “404.” Instead, they:

• Hallucinate

• Generalize poorly

• Reinforce bias

• Offer plausible but wrong suggestions

Traditional metrics like activation rate or NPS won’t tell you when things are going sideways.

You’ll need to champion new metrics:

• Confidence-weighted accuracy: Not just whether the model was right, but whether it knew it. High-confidence errors are far more dangerous.

• Time to trust: how long it takes users to feel comfortable letting AI drive

• Override rate: how often users correct or ignore model output

• Bias detection spread: performance gaps across demographics

• Compliance throughput: how many features require re-review due to AI behavior

You’ll also need to translate these to your CFO and board. That’s the real work.

5. You’ll Build a Very Different Kind of Team

As AI reshapes what gets built, it also reshapes who builds it and how.

You’ll need to grow your team with new capabilities:

• Data product managers who know how to manage training sets and feedback loops

• AI behavior designers who understand interface and interaction with non-deterministic systems

• Compliance-product hybrids who can navigate the grey area between legal safety and product usability

But you also need to grow your current team. That’s where leadership comes in.

Some of your best people will feel destabilized. Others will want to chase shiny AI projects without grounding in user value. You’ll need to:

• Help them develop AI fluency

• Reframe career paths to include behind-the-scenes impact

• Protect the trust work that doesn’t “ship” but still matters

Leadership here isn’t disappearing, it’s evolving. You’re still coaching. You’re just coaching in a more dynamic, less familiar environment.

6. Intuition Stops Working at Scale

Executives often lead with pattern recognition: you’ve seen enough go-to-markets, customer behaviors, stakeholder dynamics that you can spot the signal in the noise.

But that pattern breaks when the product behavior is:

• Partially emergent

• Opaque by design

• Shaped by stochastic outputs

Your instincts might tell you “this use case will land.” But the model might behave differently under production load, or introduce risks your gut doesn’t detect.

Leading AI products requires a shift from intuition to iteration. You’ll need:

• Simulated users to red team your agents

• Probabilistic sandbox environments

• Evaluation frameworks with behavioral criteria, not just functional ones

You can’t rely on your gut. But you can build infrastructure that makes failure visible early, when it’s still cheap to fix.

7. Customer Discovery Gets Harder, Not Easier

We’re used to user interviews being the gold standard for discovery.

But when users interact with a system that behaves unpredictably, or whose logic they can’t trace, what they say and what they do often diverge.

They may love the feature until it makes a decision they don’t understand. Or they may resist it entirely, then quietly adopt it once trust is earned.

You need new tools:

• Behavioral logs, not just feedback forms

• Shadow modes and post-decision audits

• Task completion + override metrics

• Comparative evals between human and AI-generated outcomes

This is a shift from “listening” to observing, and from “validating” to stress-testing.

8. Your Best PMs Might Not Ship a Thing

In traditional product orgs, the highest-performing PMs are prolific: they ship, they iterate, they drive adoption.

In AI orgs, your most strategic PM might:

• Kill 3 features before launch due to safety concerns

• Redesign a feedback loop to avoid long-term bias drift

• Intervene on a dataset that would’ve compromised your license agreement

Their impact is often what didn’t happen.

If your culture only celebrates shipping velocity, you’ll burn out the exact people keeping your company safe, compliant, and trusted.

You need to make this work visible and reward it like it matters. Because it does.

9. You’ll Need to Say “No” More Than Ever

Every company is racing to build AI features. Many of them won’t work. Some of them will harm users.

You’ll be under pressure to match what competitors are doing. To hit quarterly goals. To wow the board.

But some of your most strategic moments will come when you say:

“This feature isn’t explainable.”
“This model doesn’t meet our equity bar.”
“We can’t safely support this in Europe.”

These aren’t signs of fear. They’re signs of leadership.

You’re not just managing risk. You’re preserving optionality. You’re saying: we’ll be around in two years when the others are cleaning up messes.

10. Your Culture Will Be Encoded, Literally

You used to influence culture through values, communication, and hiring.

Now, your culture shows up in:

• Which datasets you use to train

• How you define success for an agent

• What exceptions you allow

• What decisions get audited

If you don’t actively shape these elements, your product will reflect the assumptions, blind spots, and biases of your infrastructure.

In AI orgs, culture doesn’t live in a slide deck. It lives in the code.

That’s the part no one tells you.

So What’s the Job Now?

If you’re still treating your role like it’s 2018, here’s what you’re missing:

You’re no longer managing backlogs or aligning stakeholders.

You’re:

• Designing systems that scale good judgment

• Owning the tradeoffs between speed, trust, and risk

• Hiring for new disciplines that didn’t exist five years ago

• Building internal tooling that moves the business

• Driving the company's values into infrastructure

• Creating a culture where not shipping is sometimes the best thing you can do

This is the future of work for product executives. And most of us weren’t trained for it.

But we can adapt.

Because the core of the job hasn’t changed: make better decisions, faster. The difference is how we define “better” and who, or what, we entrust with that responsibility.