The setup

Two numbers define the current state of AI prior authorization.

155 seconds. That’s how long Anterior’s platform takes to approve a cancer care authorization at Geisinger. 99.24% clinical accuracy, validated by KLAS. 50 million lives covered. Staff satisfaction above 90%.

15 to 20 days. That’s how long providers in Washington state are waiting for authorization decisions under the CMS WISeR (Wasteful and Inappropriate Services Reduction) Model, a pilot launched January 1, 2026, across six states. UW Medical System reports nearly 100 patients waiting for epidural steroid injections. Procedures that took two weeks now take four to eight.

The technology category is the same. The outcomes are opposite. In the Pressure Test version, I identified three design variables that explain the gap: incentive structure, workflow ownership, and validation transparency. Here I want to go further into each one, map the full competitive landscape, and build the evaluation framework that should exist before any health system or investor touches this category again.

How the money actually works

This is the section that matters most and gets discussed least, because the incentive mechanics are buried in contract structures that don’t make it into press releases.

Anterior’s model: Anterior charges health plans for platform deployment and adoption. Their revenue is tied to the number of lives covered and the volume of authorizations processed. When a claim is approved in 155 seconds, that’s the system working as designed. Anterior’s compensation does not increase when a claim is denied. The economic incentive and the clinical incentive point in the same direction: process accurately, process fast, keep providers satisfied so they keep using the system.

The WISeR model: Under the WISeR pilot, CMS contracts with third-party administrators to review Medicare Part B services. The contractors are compensated based on what CMS calls a share of “averted expenditures.” In practice, this means the contractor receives a percentage of the dollar value of services that are denied or not performed after review. The more claims that do not proceed, the higher the contractor’s compensation.

This is not an obscure detail. It is the structural core of the program. When a contractor’s revenue model rewards denial, every downstream decision — the AI model’s tuning, the physician reviewer’s incentives, the portal’s workflow design, the transparency of the rationale — is shaped by that economic gravity.

One detail makes this sharper. Under WISeR, the AI can only affirm a request. All non-affirmations are reviewed and decided by a board-certified physician. There is a human in the loop on every denial. And yet the Cantwell report documents 15-20 day delays, denials inconsistent with clinical criteria, and no clear rationale provided to providers. The human review layer did not prevent those outcomes. The incentive architecture was strong enough to produce them anyway.

This is worth sitting with. The argument for human-in-the-loop review in AI-assisted clinical decisions is that the human provides a check on the AI’s errors. But if the human reviewer is operating inside a system where the organization’s revenue increases with denials, the human-in-the-loop argument collapses. The physician is not checking the AI. The physician and the AI are both responding to the same incentive structure. The check is structural, not procedural, and the structure rewards denial.

Cohere Health’s model: For comparison, Cohere Health ($200M raised, $90M Series C led by Temasek in May 2025) processes over 12 million prior authorization requests annually and auto-approves up to 90% of them. Their positioning statement is explicit: the technology is designed to accelerate approvals, not to deny care, and denial decisions always remain with a human clinician. Geisinger Health Plan reported a 63% reduction in PA denials and a 15% reduction in total medical expenses after deploying Cohere. That’s a model where reducing denials is the value proposition, not reducing approvals.

EviCore and Carelon (legacy UM): Traditional utilization management firms have operated on shared savings and per-review fee models for decades. The shared savings variant has the same structural problem as WISeR: the vendor’s compensation is tied to the volume of “avoided” spending. The per-review fee model is neutral on outcomes but creates an incentive to maximize review volume. Neither model is new. What is new is applying AI to accelerate the throughput of a system whose incentive structure already rewards denial. AI doesn’t change the incentive. It scales it.

The pattern: The question for any AI prior authorization program is not “does the AI work?” It’s “what does the money reward?” If the money rewards approval speed and clinical accuracy, the AI gets tuned for approval speed and clinical accuracy. If the money rewards averted expenditures, the AI gets tuned to maximize the volume of cases routed to denial. The technology is agnostic. The incentive is not.

The regulatory landscape nobody is reading together

There are at least five regulatory threads touching AI prior authorization right now, and I have not seen anyone read them as a single picture. They should be.

Thread one: CMS-0057-F, the Interoperability and Prior Authorization Final Rule. Released January 17, 2024, with key compliance dates beginning January 1, 2026 (some delayed to January 2027). This rule requires impacted payers (Medicare Advantage organizations, Medicaid managed care plans, CHIP entities, and QHP issuers on the federal exchanges) to implement FHIR-based Prior Authorization APIs, publicly report prior authorization metrics including approval rates and turnaround times, and respond to standard prior auth requests within seven calendar days and urgent requests within 72 hours.

This is the transparency infrastructure that WISeR conspicuously lacks. CMS-0057-F was designed to make prior authorization decisions visible, auditable, and comparable. WISeR operates outside this framework because it applies to traditional Medicare Part B, not to the payer categories covered by CMS-0057-F. The result is that the newest AI prior authorization program in CMS’s portfolio has less transparency than the regulatory standard CMS itself finalized 18 months earlier.

Thread two: The Texas Gold Card law (HB 3459, 2021, amended by HB 3812, 2025). Texas created a prior authorization exemption for physicians who achieve a 90% or higher approval rate on PA requests for a given service over a 12-month evaluation period. The physician earns a “gold card” — an exemption from prior authorization for that service. The law applies to state-regulated health plans (roughly 20% of the Texas market).

Texas is one of the six WISeR states. That means Texas physicians who have earned gold card exemptions from state-regulated plans are simultaneously subject to new CMS prior authorization requirements for the same procedures under traditional Medicare. The state moved to reduce prior authorization burden. The federal pilot moved to add it. Nobody seems to be tracking this conflict publicly. A health system running innovation in Texas needs to understand that their prior auth environment just became more complicated, not less, and that the two policy directions are structurally opposed.

Thread three: The Improving Seniors’ Timely Access to Care Act. This bipartisan legislation has been reintroduced multiple times and would require Medicare Advantage plans to streamline prior authorization, establish electronic prior authorization processes, and make approval criteria publicly available. It has broad support from provider organizations. It has not passed. But its requirements — transparency, electronic processing, public criteria — describe the exact capabilities that are absent from WISeR.

Thread four: State-level AI regulation in healthcare. At least a dozen states have introduced legislation governing AI use in healthcare decisions, including prior authorization. Colorado’s SB 169 (2024) requires disclosure when AI is used in insurance decisions. California, New York, and Illinois have active legislative proposals. The regulatory environment for AI prior auth is fragmenting at the state level at the same time CMS is rolling out a federal pilot with minimal transparency provisions.

Thread five: WISeR itself, and its political status. The pilot launched January 1, 2026, in six states: Arizona, New Jersey, Ohio, Oklahoma, Texas, and Washington. Senator Cantwell’s April 2026 snapshot report, based on Washington State Hospital Association survey data, documents care delays, administrative burden increases, and denials without clear clinical rationale. The pilot’s future is politically contested. Legislative opposition is building. CMS faces pressure from both supporters who see the pilot as necessary cost containment and critics who see it as an AI-driven barrier to care.

Reading these together: CMS is simultaneously (a) requiring payers to make prior authorization more transparent, faster, and electronically accessible under CMS-0057-F, and (b) running a pilot under WISeR that has no public transparency mechanism, produces 15-20 day delays, and compensates contractors based on denial volume. Whether this contradiction is intentional or a byproduct of different CMS divisions operating on different timelines, it creates a confusing environment for health systems trying to build a coherent AI prior authorization strategy. The systems that track all five threads and design their evaluation frameworks accordingly will be better positioned than the ones that track any single thread in isolation.

One caveat on the evidence base: the most detailed public data on WISeR outcomes comes from Washington state, via the Cantwell report and the Washington State Hospital Association survey. The other five states may show different patterns — different contractors, different procedure mixes, different provider responses. The structural argument (incentive design shapes outcomes regardless of the technology) holds across states because the compensation model is the same. But the specific outcome data — the 15-20 day delays, the 100 patients waiting for epidural injections — is documented in one state so far. As more data surfaces from Arizona, New Jersey, Ohio, Oklahoma, and Texas, the picture will either confirm or complicate what Washington is showing.

The Olive AI parallel

Olive AI raised $902 million and reached a $4 billion valuation selling prior authorization automation to health plans. The product was marketed as AI-powered. In practice, it relied heavily on RPA screen-scraping bots and required more human intervention than the pitch acknowledged. Revenue projections were later exposed as fabricated. The company wound down in October 2023 and sold its prior authorization assets to Humata Health.

Three parallels to WISeR are worth noting.

First, the technology description gap. Olive marketed RPA as AI. WISeR describes a program that uses “AI” but the AI can only affirm — every denial goes through a human physician. In both cases, the label “AI” is doing more work than the technology. The marketed description overstates the role of automation in the actual decision process.

Second, the validation gap. Olive’s accuracy and cost projections were not independently verified until KLAS and Axios investigated. WISeR has no published accuracy metric for its clinical determinations, no third-party validation, and no transparency mechanism for providers to understand the basis for a given decision. In both cases, the claims went unchallenged longer than they should have because the evaluation processes in place did not include independent verification.

Third, the incentive structure. Olive’s shared savings model with health plan clients created pressure to demonstrate cost reduction. WISeR’s averted expenditure model creates pressure to maximize denial volume. Different mechanisms, same structural problem: the vendor’s financial incentive diverges from the patient’s clinical interest.

I advised a company building voice-based prior authorization earlier this year. The technology worked. The design questions that determined whether it would survive enterprise procurement were the same ones visible in both the Olive failure and the WISeR pilot: how does the money flow, who validates the claims, and what happens when the system gets it wrong?

The comparative framework

The prior authorization AI category is not a single market. It is at least five distinct deployment models, each with different incentive structures, transparency mechanisms, and failure modes.

Model 1: Payer-side approval acceleration (Anterior, Cohere Health). The AI is deployed by the health plan to speed up approvals, reduce administrative burden, and improve provider satisfaction. Revenue is tied to deployment and adoption, not to denial volume. Clinical accuracy is validated by third parties (KLAS). Transparency is a competitive advantage because providers need to trust the system to use it.

Model 2: Government-contracted cost containment (WISeR / Virtix Health). The AI is deployed by a CMS contractor to reduce Medicare spending. Revenue is tied to averted expenditures. Transparency is not a competitive requirement because the contractor’s buyer is CMS, not the provider. The provider is the subject of the system, not the customer.

Model 3: Legacy utilization management (EviCore, Carelon). Human reviewers using rules-based systems and clinical guidelines. Shared savings or per-review fee models. AI is being added incrementally, but the core process remains human-driven. The incentive structure varies by contract but shared savings models have the same structural problem as WISeR at lower throughput.

Model 4: Provider-side exemption (Texas Gold Card, Humana Gold Card program). The approach exempts high-performing providers from PA requirements entirely, based on historical approval rates. No AI is involved in the exemption decision — it’s a performance-based waiver. The incentive structure rewards clinical accuracy over time. The limitation is that it only works for providers with sufficient volume and history, and it only covers state-regulated or MA plans, not traditional Medicare.

Model 5: Platform integration (Epic, Oracle Health). EHR vendors building prior authorization workflow tools directly into the clinical system. The AI component varies. The value proposition is workflow integration, not clinical decision-making. The incentive structure is neutral on outcomes because the EHR vendor is paid for the platform, not for the authorization result.

Each model has a different answer to the three design variables I identified in the Pressure Test piece. The evaluation mistake most health systems make is treating “AI prior authorization” as a single category and evaluating all entrants against the same criteria. The five models above require five different evaluation frameworks.

Where to start depends on where you sit. If your institution is in a WISeR state, the immediate move is twofold: begin Model 4 evaluation (can your high-approval-rate physicians qualify for state-level gold card exemptions that reduce your PA burden on the commercial side?) while simultaneously running Model 1 vendor outreach (who can offer a payer-side alternative that your MA and managed care partners would adopt?). If you are not in a WISeR state, your first move is the criteria definition exercise from the CINO section below, because it applies regardless of which model you eventually evaluate, and having it documented before CMS expands the pilot gives you months of advantage.

The budget math matters here. I wrote in an earlier Pressure Test piece about the Sage Growth data showing that 51% of health system C-suite leaders now require 110% or better ROI within 18 months. That compressed payback window applies to AI prior auth evaluation too. Model 1 vendors (Anterior, Cohere) can demonstrate ROI in that window because reduced PA turnaround time, lower denial rates, and decreased administrative staffing needs all translate to dollar values a CFO recognizes. Model 2 (government-contracted, WISeR-style) is imposed, not purchased, so the ROI question is moot — the health system bears the cost without choosing the vendor. Model 4 (Gold Card exemption) has the fastest payback because the cost is near zero and the savings are immediate, but coverage is limited to state-regulated plans. Model 5 (EHR platform integration) may already be in your existing contract and budgeted, making the incremental cost conversation simpler. Mapping the five models against your CFO’s 18-month threshold before the first vendor call is the difference between running an evaluation and running a budget exercise that happens to involve vendors.

For founders building in this category: the WISeR backlash is creating a positioning window, but it won’t last. The health systems evaluating AI prior auth vendors right now are doing so with WISeR as a negative reference point. The founders who walk into the next enterprise conversation with a pre-built brief — here is our compensation model, here is why it does not reward denial, here is our KLAS-validated accuracy, here is how we compare to each of the five models above — have an advantage this quarter. If you are building in Model 1 and can demonstrate the anti-WISeR case with data, your positioning is stronger right now than it will be in six months when the backlash normalizes and the category comparison becomes routine.

Six diligence questions

These apply whether you are a health system evaluating a vendor, an investor evaluating a company, or a policy team evaluating a program.

1. How is the vendor or contractor compensated, and does the compensation model create an incentive to deny, delay, or affirm?

Map the money flow. If the vendor’s revenue increases when claims are denied or “averted,” the system will produce more denials over time regardless of the technology’s capability. This is not a prediction. It is a description of how incentive structures work.

2. What is the AI’s actual decision authority — can it deny, or only affirm — and what is the human review process for non-affirmations?

The answer “a human reviews every denial” is not sufficient. Ask who the human works for, what their compensation structure rewards, how many cases they review per hour, and what happens when they disagree with the AI’s routing. A human-in-the-loop who is reviewing 40 cases per hour inside an organization compensated for averted expenditures is not providing meaningful clinical oversight.

3. What transparency mechanism exists for providers to understand the rationale behind a given decision?

If the answer is “the provider can call a phone number” or “the provider can log into a portal,” ask what information is available through those channels. A portal that shows the decision but not the rationale is not a transparency mechanism. It is a notification system.

4. What is the average time from submission to final determination, broken out by procedure type, and how does that compare to the pre-program baseline?

Averages conceal distribution. Ask for the median and the 90th percentile. A program that resolves 80% of cases in 24 hours and takes 30 days on the remaining 20% will report a favorable average that conceals a serious access problem.

5. What validation data exists on the accuracy of the program’s clinical determinations, and who conducted the validation?

Self-reported accuracy metrics from the vendor are starting points, not evidence. Ask whether KLAS, an academic institution, or an independent auditor has validated the clinical accuracy claims. If no independent validation exists, ask why and what the timeline is. Anterior and Cohere both submit to KLAS validation. If a vendor in this category does not, that tells you something.

6. What is the appeal process, what is the appeal success rate, and what is the average time to resolution on appeal?

A high appeal success rate is not good news. It means the initial decision process is producing incorrect denials that are only caught when providers invest the time and cost to appeal. The appeal success rate is a measure of the system’s error rate, not its quality.

What this looks like from the CINO seat

If I were running the innovation function at a health system right now, AI prior authorization would be on my board agenda this quarter for three reasons.

First, it’s coming whether you choose it or not. Between CMS-0057-F’s payer requirements, the WISeR pilot, MA plan prior auth automation, and EHR platform features, AI will be involved in your prior authorization workflow within 18 months. The question is whether you define the terms or respond to someone else’s terms.

Second, the WISeR experience is contaminating trust in AI broadly. When clinical staff see AI-assisted prior auth delay pain management for seven weeks, that skepticism doesn’t stay in the prior auth category. It bleeds into every AI evaluation conversation. Your board will ask whether the AI vendor you brought in last year could produce a similar outcome. Having a clear answer — and a clear framework for why your vendors are structurally different from WISeR — is a defensive necessity.

Third, there is a positioning opportunity. The health systems that define their own evaluation criteria, run a competitive process for AI prior auth vendors using the six diligence questions above, and publish their results will set the standard other institutions adopt. That’s a thought leadership position that matters when you’re competing for talent, grant funding, and industry partnerships.

The innovation team that treats this as a compliance exercise will build a committee. The innovation team that treats it as a strategic priority will build an evaluation framework that applies across the entire AI vendor portfolio, not just prior authorization, and will use the framework to earn budget authority from the CFO. Those are different outcomes from the same trigger.

The question underneath

The CMS WISeR pilot, Anterior’s deployment, Cohere’s platform, the Gold Card laws, CMS-0057-F — these are all different answers to the same question: who should decide whether a patient receives a medical service, and what should that decision be based on?

The traditional answer was “a payer, based on medical necessity criteria reviewed by a physician.” The AI-era version of that answer introduces two new variables: the speed of the decision and the incentive structure of the decision-maker.

When the incentive structure rewards denial and the AI scales throughput, you get WISeR. When the incentive structure rewards accuracy and the AI speeds approval, you get Anterior. The technology is not the variable. The design is.

The founders and health system leaders who understand that will shape how this category develops. The ones who treat “AI prior authorization” as a single thing will be shaped by it.

If you’re building in AI prior authorization, evaluating vendors in this category, or running an innovation function at a health system in one of the six WISeR states, I’d be interested in hearing what you’re seeing on the ground. What does your evaluation process actually look like? And for investors: how are you assessing incentive structure risk in companies building in this category? Reply to this email or reach out on LinkedIn.

Sources: Cantwell Senate snapshot report (April 20, 2026), CMS WISeR Model documentation, Virtix Health FAQ, Anterior press releases, Fierce Healthcare, MedCity News, AlleyWatch, CMS-0057-F Final Rule (January 17, 2024), Texas Insurance Code Chapter 4201 Subchapter N (HB 3459, HB 3812), Cohere Health press releases and case studies, KLAS Research, Washington State Hospital Association survey data.

PS: I do product and technical diligence on healthcare AI companies for PE/VC firms, including companies in the prior authorization category. If you’re evaluating a target in this space and want an independent assessment of their incentive structure, validation evidence, and competitive positioning, reach out on LinkedIn or reply here.

Here’s view of what I’ve learned and what I wish someone had told me earlier.

1. If You Don’t Define Decision Rights, You’ll End Up With Shadow Hierarchies

In one organization, I established clear decision rights around regulatory ship decisions early on, documenting them through standard operating procedures. The goal wasn’t just to assign accountability—it was to prevent misalignment before it had a chance to take root.

To make those boundaries visible and easy to navigate, we translated the SOPs into a decision matrix and shared it across product, engineering, compliance, and executive teams. Everyone knew who owned what—from scope and sequencing to implementation tradeoffs and release criteria. We reinforced the model in planning reviews and cross-functional check-ins.

Because we clarified the structure before tensions emerged, we avoided the common pattern of backchannel escalations and second-guessing. Teams moved faster and with more confidence, because the ground rules were clear.

Lesson: You don’t need to “take” power from the founder, you need to make it explicit where their call matters most. Everything else can be delegated with transparency.

2. What Actually Signals a Bad Transition

I've seen a few transitions stall. Here’s what that looked like in practice:

• PMs running interference instead of building alignment

• Founders being asked to "stay out of the weeds" without a clear alternative

• Roadmaps driven by executive escalations instead of strategy

Lesson: Most chaos isn’t about authority, it’s about the absence of shared context.

3. You Can’t Empower a Team That Isn’t Ready

One mistake I’ve seen is trying to implement empowerment structures before the product or team is ready.

If you don’t yet have stable delivery processes, clarity on your core user, or alignment on your value proposition, it’s too early to expect product teams to own outcomes. Prematurely pushing for a “modern product org” can cause more confusion than it solves.

Checklist before distributing authority:

• Stable release processes

• Ability to measure customer outcomes

• A functioning product/eng/UX discovery triad

• Clarity on target users and core value prop

4. Addressing Technical Debt While Evolving Product Strategy

In founder-led orgs, speed is survival. But often, the early decisions that bought speed become anchors during scaling.

I’ve worked with engineering leaders to implement a dual-track roadmap that makes technical debt visible and actionable without derailing forward progress:

• Track A: User-facing features tied to strategy

• Track B: Structural debt and enablers (e.g., test automation, schema redesign, compliance scaffolding)

Each cycle, engineering flags debt that directly blocks speed, compliance, or reliability. Product treats this as strategic work, not "maintenance."

Lesson: Maintain a “tech debt ledger” in the same system as the product backlog. Assign lifecycle cost to debt where possible (e.g., “adds 3–5 hrs/story to QA effort”).

5. Hiring the Right Team for the Phase You’re In

You can’t scale product if you hire only for the next six months. You also can’t parachute in “big company” talent and expect them to thrive in a startup still finding product-market fit.

Team composition by growth phase

Lesson: In regulated environments, hire PMs who can explain risk classification and validation artifacts—not just write user stories.

6. Cost Visibility Changes the Conversation

Founders are decisive. But in scaling environments, what gets missed isn’t vision, it’s cost transparency.

I’ve found that mapping total cost of delivery to roadmap decisions changes the conversation:

• Build effort (dev + QA)

• Validation overhead (compliance documentation, test protocols)

• Support implications (training, internal tooling, customer ops readiness)

Lesson: Use an annotated roadmap with “cost context” on each feature. It doesn’t have to be precise, but it has to be visible.

7. Exit Pathways: When Founders Need to Step Back

Sometimes founder involvement in product becomes a liability, not a strength.

You can’t force that transition. But you can create structures that make it safe to step back:

• Roadmap input windows: Founder input is welcomed, but upstream, before teams commit

• Playback sessions: Teams present progress not for approval, but to show how it aligns with strategic vision

• Designated founder proxies: A trusted product lead or staff role who has context and can channel founder perspective without daily involvement

In one case, we defined the founder’s “innovation sandbox”: one initiative per quarter where they could go deep, while the core roadmap remained team-led.

Lesson: This isn’t about pushing someone out. It’s about giving them a high-leverage lane where they can thrive without becoming a bottleneck.

8. You Have to Map the Resistance, Or It Will Map You

In every transition I’ve led, there’s resistance. Sometimes explicit, usually quiet. Founders who feel cut out. Engineers who don’t trust product. GTM leaders who think we’re overcomplicating things.

Lesson: Resistance isn’t irrational, it’s design feedback. Name it. Work with it.

9. When to Push Back and How to Measure Progress

Founders are often right. Until they aren’t.

One turning point came when the founder insisted on prioritizing a feature based on anecdotal input. I came back with:

• Usage data from existing cohorts

• Discovery summaries showing unmet needs

• Cost of delay for higher-impact roadmap items

We framed it as a tradeoff conversation, not a challenge to authority. He shelved the feature.

Metrics I track to gauge product maturity:

• % of roadmap items tied to validated problems

• Time from insight to decision

• Decision friction index (how often decisions are escalated, reversed, or relitigated)

Lesson: Healthy orgs aren’t quiet, they’re noisy in the right places, and decisive in the right ones.

Final Thought

You don’t scale product by removing the founder. You scale product by operationalizing the parts of founder vision that work and building the system to pressure-test the parts that don’t.

That’s the real work. And it only happens when there’s trust, structure, and a shared understanding of what success actually looks like.

Estimated effort: one developer, two hours.

What actually happened:

• The backend dev didn’t realize that status value fed into a webhook trigger for the EHR integration.

• The integration broke silently. No error. Just missing data.

• A downstream report used by the nursing director stopped filtering correctly.

• QA had to add two extra days of regression testing because nobody knew what else the change might touch.

Final cost: 14 hours across four people. For one field.

Here’s the part that should worry you if you’re running a pilot: nobody made a mistake. The system worked exactly as it was designed. That design just required every person touching it to hold a complete mental model of every downstream dependency.

When you’re running a pilot with 30 users in one department, that kind of hidden complexity stays invisible. When you try to expand to three departments and a CFO is asking why implementation timelines keep slipping, it becomes the thing that kills your deal.

What This Looks Like in a Pilot

You probably aren’t thinking about architecture right now. You’re thinking about adoption. You’re watching weekly active users and wondering why engagement dipped after week three.

But when I tag the actual friction points in startup conversations, a pattern shows up that has nothing to do with user motivation:

The “I thought someone else was handling that” pattern.

In one call, three different people said some version of that phrase within ten minutes. Not because they were careless. Because the system they were configuring had so many interdependencies that no single person could predict what a small change would break.

That pattern shows up in pilot environments as:

• A workflow that worked in Department A breaks when you clone it for Department B, because a config assumption was hardcoded for the first use case.

• Your clinical champion reports that “it’s glitchy” but can’t articulate what’s wrong. What’s actually happening is a silent integration failure downstream of a config change made two weeks ago.

• Your implementation team spends 40% of their time on rework instead of expansion, and you explain this to your board as “we’re still optimizing.”

You’re not optimizing. You’re paying a complexity tax on every change, and it compounds.

The Question That Changes the Conversation

Most startups respond to this by trying to improve communication. More standups. Better tickets. Cleaner handoff docs.

That won’t fix it. You can’t out-communicate a system that requires omniscience.

The question to ask instead — and this is the one you bring to your next engineering sync:

“How many people need to be in the room for us to safely make a one-field change?”

If the answer is more than one, you have a fragility problem. And that fragility problem is what’s making your pilot feel expensive, slow, and risky to the exact buyer you’re trying to convert.

Three Moves You Can Make This Week

1. Run a fragility audit on your last five config changes.

Go back through your last five changes during the pilot. For each one, write down: what was requested, what actually had to happen, how many people touched it, and whether anything broke silently. You’re building a cost-of-change ledger. You’ll need this when your champion asks “how fast can we roll this out to two more units?” and you need an honest answer.

2. Identify your “no-touch zones.”

Every configurable system has areas where a change will cascade unpredictably. Find them. Mark them. Tell your implementation team: these are locked during pilot expansion. We don’t touch these without a full dependency review. This sounds conservative. It’s actually what lets you move faster, because your team stops losing days to surprise rework.

3. Reframe the conversation with your champion.

If your champion is hearing “we need more time to implement,” they’re translating that as “the product isn’t ready.” That’s a death sentence for your expansion case.

Instead, give them the specific version: “We identified that expanding to your cardiology unit requires changes to three integration touchpoints. We’ve mapped those dependencies and here’s the timeline. We’ve also locked down the parts of the system that are stable so we don’t introduce risk to what’s already working.”

That’s a sentence a champion can repeat to their CNO. “We need more time” is not.

Why This Matters for the Contract Conversation

A CFO evaluating whether to convert your pilot into a paid rollout is doing a mental calculation you may not realize: they’re projecting your implementation cost at scale.

If your pilot took six months and covered one department, and the ask is to cover twelve departments, the CFO is not thinking “12x the value.” They’re thinking “12x the cost and complexity.” And if your pilot was full of rework, timeline slips, and “we’re still optimizing” updates, that projection looks terrible.

The founders who convert pilots are the ones who can show that the cost of change went down over the life of the pilot, not up. That their second department went faster than the first. That they identified and locked down fragile config paths so expansion doesn’t require a full engineering team on-site.

That’s not a product argument. That’s a unit economics argument. And it’s the one the CFO actually cares about.

Your pilot isn’t stalling because clinicians are too busy. It’s stalling because every small change costs ten times what it should, and that cost is showing up as slow timelines, silent breakage, and a champion who’s running out of political capital to defend you.

Find the fragility. Fix the cost of change. That’s what gets you from pilot to contract.

Subscribe now

Four teams. Different tools. No shared decision about what was acceptable, what got documented, or how any of it would hold up if an auditor asked “who authored this section?”

Nobody was hiding anything. Every person using AI thought they were being more efficient. The company just never created the mechanism to agree on what was allowed.

This is the first real AI operating model crisis in healthtech, and it isn’t about AI in the product. Product AI is well-governed through design controls. The crisis is AI inside the regulated workflows surrounding the product: submissions, verification protocols, complaint investigations, risk analyses, DHF documentation. Work where authorship and traceability matter, and where nobody has answered the question “does AI-assisted drafting count, and if so, what do we document?”

Strategy is not the problem

Most healthtech companies I talk to have an AI strategy. “We’ll use AI across the company.” Fine. That’s direction.

The operating model is a different question. It answers: who decides what AI can be used for, who owns the governance, and what gets documented. RA associates can use AI for narrative sections if they log the tool, the prompt, and the human review step in the DHF. Complaint investigators cannot paste PHI into a tool without a BAA, full stop.

That’s the operating model. It’s boring. It’s also the thing that determines whether your next vendor risk questionnaire is a 48-hour turnaround or a three-week scramble.

Subscribe now

Minimum viable governance

Here’s the stage missing from generic AI frameworks, and the one early-stage healthtech companies actually need.

A two-page acceptable use policy. BAAs for two or three tools. AI usage noted in existing compliance documentation. One person owns a Google Doc and a folder of signed BAAs. No AI team. No new department.

It sounds minimal because it is. For a company under 25 people, this is a viable long-term posture, not a stepping stone. It’s the difference between answering six AI-specific questions on a security assessment and losing the deal because you can’t.

Most seed-stage founders skip this because they think governance means governance theater. It doesn’t. It means you can tell a buyer, in writing, which AI tools your team uses, which ones have BAAs, what PHI handling looks like, and who reviews AI-assisted output before it ships. If you can’t answer those four questions today, you aren’t governed. You’re lucky.

What changes as you move up market

MVG works until your buyer changes. Then the operating model has to change with it.

A regional health system signing a $250K pilot will accept your two-page policy and a vendor questionnaire. An IDN signing a multi-year enterprise contract will not. A payer with 20 million covered lives won’t even start the security review. Each buyer tier raises the bar on what governance has to look like, and the operating model is what carries the weight.

Roughly, what each stage buys you:

Centralized control is the natural next move from MVG. One AI team owns tool selection, BAA management, prompt review, and incident response. Tight audit trail, slow turnaround. This is where most Series A healthtech companies land, and where most of them stay too long. It survives mid-market enterprise scrutiny and starts to break under volume.

Center of excellence keeps the central team but shifts its work from gatekeeping to building reusable components: validated prompt libraries, approved model wrappers, standard documentation templates. Product teams consume what the CoE produces. This works until the CoE ships components nobody asked for and product teams quietly route around it.

Hub-and-spoke puts governance in a central hub and execution in product squads. The hub maintains standards, tooling, and the regulatory posture. Squads build locally inside the guardrails. This is where most healthtech organizations end up. It scales to enterprise health system contracts, payer contracts, and Tier 1 pharma when it’s intentional.

The pattern I keep seeing: most companies in hub-and-spoke didn’t choose it. They outgrew centralized control, nobody redesigned the structure, and hub-and-spoke is what emerged. Three tells of the accidental version:

Decision rights are ambiguous. Product teams either ask permission for everything (slow) or ask forgiveness for everything (risky).

RA reviews happen after the fact instead of during design.

The hub team is firefighting governance gaps across every product squad. If your hub team is burned out, you’re probably running the accidental version.

Federated ownership pushes AI decisions into business units, each with its own regulatory competency, inside shared rails. This requires distributed RA expertise that’s expensive and hard to staff. It works at companies with multiple product lines selling into different regulatory regimes. Below that scale, it’s overhead.

AI-native assumes AI in team composition, funding models, and operating cadence. Compliance is automated into deployment. Model drift triggers validation workflows. Few healthtech companies are here today. The ones that are got there through acquisition or by being founded around it.

The progression isn’t a ladder you have to climb. The right stage depends on your buyer, your regulatory exposure, and your size. The mistake is staying at a stage your buyer has outgrown, or jumping to a stage your team can’t actually staff.

What weak governance actually costs

When people say “governance,” they usually mean documentation. The real cost of weak AI governance in healthtech is specific and ugly:

You cannot answer authorship questions on a 510(k) section if three people drafted it with three different tools and nobody logged which.

You cannot defend your validation history if AI-generated V&V language entered the DHF without review traceability.

Your CAPA narrative includes machine authorship you can’t account for.

Your vendor risk response becomes improvisation because you don’t actually know which tools touched PHI last quarter.

“We have an AI policy” prevents none of these. An operating model does.

The diagnostic question

If you had to place your clinical AI team, your engineering org, your regulatory function, and your back-office operations on the same map today, would they all land in the same column?

Probably not. Clinical AI is usually the most governed, because the product is regulated. Back-office is usually the least, because nobody’s watching. Engineering and RA are somewhere in between, often using different tools for adjacent work.

That spread isn’t automatically bad. Sometimes it’s fine. Sometimes it’s the fire you should already be putting out.

The question is whether you know which one it is. Most companies don’t.

Reach out to me at arvita (at) vahanalabs.ai if you are interested in learning more about our offerings.

Share

This is the core question the Pressure Test exists for: when a deployment model works this well, does it scale? Or does it become the thing you can’t afford to keep doing?

Anterior just raised $40M ($64M total) from NEA, Sequoia, FPV, and Kinnevik for their AI prior auth platform. 50M+ lives covered. 99.24% clinical accuracy validated by KLAS. One health plan that used to take weeks to approve cancer treatment now does it in 155 seconds.

The numbers are strong. But the numbers aren’t what makes this interesting. What makes this interesting is a bet Anterior is making about how healthcare AI actually gets adopted, and whether that bet creates a durable business or an expensive habit.

Someone has to close the gap. The question is who.

Every AI product that touches clinical workflows hits the same wall. The product works in the demo. It works in the pilot. Then it hits real operations and something breaks. Not the AI. The workflow around the AI.

Maybe the routing logic doesn’t match how this specific health plan handles out-of-network exceptions. Maybe the approval queue doesn’t align with the nursing team’s shift structure. Maybe there’s a step in the process that nobody documented because everyone just knows how it works.

Anterior’s answer is to put their own clinicians inside the customer’s operations to find and fix these gaps in real time. They call it the “Forward Deployed Clinician” model, borrowing from Palantir’s Forward Deployed Engineer approach.

And the results back it up. One enterprise customer deployed across hundreds of nurses. Clinical review cycles dropped 75%. Staff satisfaction above 90%.

That staff satisfaction number carries more weight than the accuracy number. 99.24% accuracy gets you into production. Staff satisfaction above 90% keeps you there. In healthcare AI, most implementations don’t die because the AI was wrong. They die because the people doing the work found ways to route around it. If the embedded clinicians are the reason satisfaction is that high, then the deployment model isn’t just a go-to-market choice. It might be the product itself.

Where the pressure builds

The margin math.

If 40% of your team is clinicians embedded at customer sites, your cost structure doesn’t look like a typical software company. Clinical talent is expensive, licensure-bound, and harder to recruit than engineers. Every new deployment potentially means more headcount.

This is the tension Palantir navigated for years. In Palantir’s early days, forward deployed engineers outnumbered product engineers, and the company traded at a steep discount to pure SaaS peers because the market couldn’t tell if it was a software business or a services business. Palantir resolved this by building a platform (Foundry) that turned field learnings into reusable product components. Each FDE deployment fed back into the platform, making the next one faster and cheaper. That’s what eventually pushed gross margins above 80%.

The question for Anterior: is embedded clinician work feeding back into the platform the same way? When an embedded clinician discovers that a specific health plan routes oncology prior auths differently than the standard, does that knowledge get encoded into the AI’s configuration, reducing the need for the next clinician at the next site? Or does each site require roughly the same clinical investment because the workflow variations are too specific to generalize?

This is where the Palantir analogy has limits. Engineers abstract client-specific requirements into reusable components. Clinicians don’t abstract the same way. A nurse who learns Geisinger’s specific routing exception produces institutional knowledge, not a software module. The scaling mechanism has to be different: instead of turning field work into platform code, Anterior would need to turn it into training data, workflow templates, or configuration rules.

The single most important signal for whether this model scales: is the average duration of an embedded clinician engagement shrinking with each new customer cohort? If it’s going from 12 months to 6 months to 3 months, the platform is absorbing the clinician’s knowledge. If it’s staying flat, this is a high-touch services model with strong outcomes but compressed margins.

Payer vs. provider: the buyer changes everything.

Anterior sells to payers, not providers. This matters more than it looks.

Payer organizations run on more standardized workflows than health systems. A health plan’s prior auth process varies by plan, but it follows regulatory structures that create meaningful commonality across customers. Compare that to provider-side deployments, where every department in every hospital runs things differently, documentation conventions vary by physician, and the EHR configuration at one site may be unrecognizable at the next.

This means the embedded clinician model likely scales better for payer-facing companies than provider-facing ones. The workflow variation is narrower, so the gap each embedded clinician needs to close is smaller, and the learnings transfer more easily across customers.

The buying committee is different too. Health plans are accustomed to paying for managed services and clinical outsourcing. An embedded clinical team doesn’t feel foreign to a payer the way it might to a hospital CIO who expects to buy software, run it internally, and never see the vendor’s staff in the building.

If you’re building for providers instead of payers, the math changes. Wider workflow variation means longer embedded engagements per site, harder knowledge transfer between sites, and a steeper climb to the point where the platform can absorb what the clinicians learn. That doesn’t mean the model is wrong for provider-facing companies. It means you need to be more deliberate about how you encode what your embedded team discovers, and more realistic about how long that encoding takes.

The moat question: does the knowledge stay when the clinician leaves?

If the deployment model is the product, then the moat is the embedded clinical team’s accumulated institutional knowledge. But institutional knowledge walks out the door when people leave.

What happens when an embedded clinician takes another job? Does the customer relationship degrade? Does the AI retain what the clinician taught it, or does the next clinician restart the learning curve? For any company running this model, the knowledge transfer infrastructure matters as much as the clinical talent. If the insights live only in the clinician’s head, you have a staffing business. If they get encoded into the system, you have a learning platform with a clinical onramp.

The market is moving toward this, not away from it.

Anterior isn’t operating in a vacuum. CMS launched the WISeR pilot in January 2026, introducing AI-assisted prior authorization review for Original Medicare across six states. That’s a direct expansion of the addressable market for exactly what Anterior does. If AI-assisted prior auth becomes standard for government payers, the demand for deployment models that actually work in clinical operations goes up. And the embedded clinician model is one of the few approaches that’s produced measurable results in production.

Other companies are running versions of this, and the pattern is instructive. Cohere Health uses clinical experts in their prior auth workflow and has gained traction with payers partly because clinical staff see the tool as augmenting their judgment rather than replacing it. EviCore (now part of Evernorth) embedded clinical reviewers inside payer operations for years before the AI wave, and when Express Scripts acquired them, the deal was priced closer to a managed services multiple than a software multiple. That’s the valuation risk for any company where the human layer is the product. On the provider side, Olive AI tried to automate clinical workflows without embedded clinical teams and struggled badly with adoption. The technology worked. The problem was that nobody was on site to close the gap between how the product was designed and how the hospital actually operated. Olive’s wind-down had multiple causes (burn rate, product sprawl), but the adoption failure at the workflow layer was a consistent theme in post-mortems.

The pattern across the market is consistent: the companies getting traction in clinical AI are the ones investing in the human layer around the technology. The ones skipping that layer are stalling at pilot.

Share

What holds, what doesn’t, what’s still open

Holds: The core insight that healthcare AI adoption fails at the workflow layer, not the technology layer. Embedding people who understand clinical work inside the customer’s operations directly addresses the most common failure mode. Anterior’s results validate this, and the market pattern across payer-facing companies reinforces it.

What this means for you: If your pilot is stalling and your product works, your deployment model is the first place to look. Not your feature roadmap.

Doesn’t hold (yet): The implicit comparison to Palantir’s scaling path. Palantir solved the economics by building a platform that turned field learnings into product. Whether Anterior’s embedded clinician work feeds back into the platform the same way is the open question that determines if this is a 15x revenue company or a 5x revenue company. Watch the cohort data: if embedded engagement durations aren’t shrinking, the margin compression will become visible at scale.

What this means for you: If you’re using an embedded deployment model, track how long your team stays at each site. If that number isn’t declining over your last 3-4 customers, you have a process problem, not a scaling problem. Figure out where the clinician’s knowledge is going and build a system to capture it.

Still open: Whether the forward deployed clinician is a temporary scaffold or a permanent feature. The best version of this model is one where embedded clinicians work themselves out of a job at each site over 6-12 months as the AI absorbs their workflow adjustments. The worst version is one where pulling the clinician out causes adoption to degrade, making the embedded team a permanent cost line.

What this means for you: Design your embedded engagement with an exit plan from day one. Define what “self-serve” looks like at each customer site. Measure whether adoption metrics hold after your team steps back. If they don’t, you’ve learned something important about where your product’s gaps actually are.

What to do with this at your scale

Anterior can embed clinicians because they’ve raised $64M. If you have 15 people, you need the same principle at a different price point.

The $0 version: Pick your stickiest pilot site. Have someone from your team join their operational standup for the next month. Not to present. Not to train. To listen to how they’re actually using your product and where the friction sits. Feed what you hear back into your configuration or workflow design.

The $2-5K/month version: Hire a part-time clinical advisor (nurse, pharmacist, whatever matches your workflow) for your highest-value pilot. Have them spend 5-10 hours a week at the customer site during the first 90 days of deployment. Their job isn’t to support the product. It’s to document every place where the real workflow doesn’t match your assumptions.

The $10K+/month version: Dedicate an implementation clinician to your first enterprise deal. This person reports to your team, not the customer’s. They stay on site through go-live and the first 60 days of production. They own the gap log.

The gap log. This is the single most important artifact your embedded person produces. It’s a running list of every workflow mismatch, workaround, and friction point they observe on site. Not bug reports. Not feature requests. Gaps: places where your product assumes the workflow works one way and the customer’s team actually does it differently. The routing exception that isn’t in your configuration. The handoff step that happens over a sticky note. The approval that technically goes through the system but actually gets decided in a hallway conversation first.

The gap log does two things. First, it becomes your product roadmap for the next quarter. Not the roadmap your sales team wants or your investors are asking about. The roadmap that makes your next deployment faster because you’ve already seen the pattern. Second, it’s the mechanism that turns an embedded engagement into a scaling investment rather than a one-time cost. Every gap you close in the product means one fewer thing the next embedded clinician has to catch manually. That’s how you make the engagement duration shrink across cohorts.

In each case, the question is the same: what do you do with what you learn? If the insights stay in someone’s head, you’ve bought yourself goodwill at one site. If they get encoded into your product (configuration rules, prompt adjustments, workflow templates, training data), you’ve bought yourself a scaling mechanism.

If you’re evaluating a company that runs this model

The budget tiers above are the founder’s version of this question. Here’s the investor’s version: how do you tell whether an embedded deployment model is building toward platform economics or just accumulating services revenue?

Six questions to ask in diligence:

1. What’s the average duration of an embedded engagement per customer? Is it shrinking across cohorts?

2. What percentage of customers have transitioned to self-serve, and what do adoption metrics look like after the embedded team steps back?

3. How do embedded clinician learnings get encoded into the platform? Is there a defined feedback loop, or does it depend on individual initiative?

4. What happens when an embedded clinician turns over? How long does it take to ramp a replacement, and does customer performance dip during the transition?

5. What’s the ratio of embedded clinicians to customers, and how does that ratio trend as ARR grows?

6. What’s the revenue concentration? If embedded deployments require heavy upfront investment per customer, the company likely runs a smaller number of high-value accounts. If the top 3 customers represent 60%+ of revenue, that’s a different risk profile than a broad distribution across dozens of plans.

One more thing to flag: regulatory liability. When your clinicians are embedded inside a customer’s operations reviewing AI outputs on clinical decisions, there are questions about licensure, scope of practice, and who carries liability when something goes wrong. If an embedded clinician overrides an AI denial and the patient has an adverse outcome, does the liability sit with the health plan, the vendor, or both? Most embedded models haven’t been stress-tested on this yet. It’s worth asking where the company’s legal exposure sits before the first adverse event forces the answer.

If the company can answer these crisply, the embedded model is probably building toward platform economics. If they can’t, you’re looking at a services margin profile wrapped in software pricing.

Anterior raised $40M ($64M total) from NEA, Sequoia, FPV, and Kinnevik. CMS launched the WISeR prior auth pilot across six states in January 2026. Sources: Anterior press release, Fierce Healthcare, MedCity News, AlleyWatch.

Every consumer-facing healthtech founder is fundraising into a market where the customer’s existing provider is bleeding satisfaction. Whether you’re building a scheduling tool, a patient engagement platform, a telehealth offering, or wearable, your buyer (whether that’s the end consumer, a health system, or a payer) wakes up to retention problems that are quantifiable and urgent. The McKinsey 2025 Consumer Health Insights Survey of 3,034 US consumers shows the economic weight of this: cost accounts for roughly 10% of brand strength in healthcare, 35% higher than any other factor. This means satisfaction isn’t a nice-to-have luxury metric. It’s the difference between a sustainable business and one that hemorrhages customers.

But here’s the trap most healthtech founders fall into: they’re building distribution strategies for an acquisition-first market that no longer exists. Investors still talk about LTV:CAC ratios and growth-at-all-costs. The actual behavior of retention-first investors and operators tells a different story.

Retention Ate the CAC Ratio

At the Stanford Consumer Health Conference, the VC panel made this explicit. Allison Ryu from Able delivered the blunt assessment: “Retention was overlooked a lot in the last couple of years. There was a lot of growth that overshadowed businesses with high churn.” Kurt Seidmesser from Starshot reinforced it: “A brand cannot go out and simply buy customers. They have to have sticky customers that are loyal and enthusiastic.”

Holly Maloney from General Catalyst quantified what this shift looks like in practice. She moved away from the LTV:CAC ratio entirely, replacing it with a payback period metric: how many months to recover customer acquisition costs. “Anything over 1x is good,” she said. “Payback within a year is terrific.” This isn’t semantic repositioning. It’s the difference between funding a growth marketing team and funding a retention team. It’s the difference between asking “can we acquire cheap” and asking “will this customer stay long enough to justify acquisition costs?”

Allison also highlighted Function Health’s competitive advantage: negative working capital from annual subscriptions. That’s not growth theater. That’s a business model that funds itself through retention. The money from customers who stay longer than a quarter flows directly back into the product and acquisition. Churn kills it immediately.

This shift explains why you’re seeing retention metrics treated as first-order investment criteria, not secondary flavor text on pitch decks. If your buyer’s existing provider is hemorrhaging 18% satisfaction year-over-year, your only distribution advantage is building something sticky enough that acquisition costs recoup faster than attrition speeds up.

What Sticky Actually Looks Like

Community and frequency dominate the actual retention playbooks at scale. Solid Core, a fitness and wellness platform, operates what their team calls “intimacy at scale.” They serve 250,000 unique people per month but train staff to operate as if they’re hosting a dinner party. The metric that tracks retention isn’t DAU or MAU. It’s frequency and the feeling of personal connection at volume.

Hyrox, a hybrid fitness competition, offers another data point. They raised prices by 25% and sold 50,000 tickets in under an hour. That’s not demand inelasticity from marketing. That’s price inelasticity built on community identity. People weren’t evaluating the cost per unit of exercise. They were buying belonging to a specific tribe.

This matters because it inverts the typical healthtech founder’s instinct. Most builders assume the product (the algorithm, the wearable, the clinical outcome) is the stickiness vector. David Burns, creator of the Feeling Great app, described the gap directly: “People don’t believe the results. They think they need a human being.” His app had the best clinical outcomes. It had poor adoption because it couldn’t overcome the belief gap. Clinical superiority without behavior change infrastructure is a feature in a product that people abandon.

Jim from HumanOut framed the actual engineering problem: “Tell people what to do is easy. Behavior change is hard. You need ecosystem, accountability, community, guarantee, fun, human connection.” That’s not marketing philosophy. That’s the list of what actually prevents churn.

What the McKinsey Data Actually Says About Digital

Thirty-two percent of digital health tool users found them unhelpful. That’s the retention problem in its purest form: a feature the buyer tried and discarded. But the second data point matters more: consumers using AI-enabled healthcare tools report higher satisfaction than non-users. The technology itself isn’t the problem. The implementation is. The boundary between “helpful” and “unhelpful” is whether the tool actually changes the user’s experience or just adds friction.

Seventy-five percent of consumers engage with health content weekly. But engagement with content isn’t engagement with your product. The second metric reveals the real conversion: consumers who engage with relevant health content are 46% more likely to schedule an appointment. This isn’t a vanity metric. This is the threshold between education and action. Content is the beachhead to intent. Intent is the beachhead to behavior change.

The data on highly satisfied consumers crystallizes the payoff: they’re 35% less likely to cancel, 3 times more likely to get timely care, and 7 times more likely to return. These aren’t marginal improvements. A 7x lift in retention from satisfaction is the difference between a sustainable unit economics model and negative working capital. It’s the difference between needing to raise Series C to fund customer acquisition and funding growth from retention curves.

Eighteen percent of consumers say their trust in AI-enabled healthcare decreased. That’s real and it matters for your roadmap, but it’s not the crux of the adoption problem. The crux is that 32% found digital tools unhelpful, and that unhelpfulness doesn’t recover through better messaging or more thoughtful positioning. It recovers through re-engineering the tool to create behavior change, not just information access.

Your Beachhead Isn’t Acquisition

The healthtech founder’s instinct right now is to move fast into the satisfaction gap. Health system satisfaction is collapsing. Payer satisfaction is collapsing. Cost expectations are unmet. The market is screaming for solutions.

The distribution mistake is treating this as an acquisition opportunity. It’s a retention opportunity. Your buyer is desperately looking for solutions that stick. Not solutions that are better on paper or cheaper in comparison, but solutions that don’t churn. Solutions that keep patients engaged. Solutions that reduce cancellations and create return customers.

This means your go-to-market strategy should invert three common assumptions:

First, measure payback period, not LTV:CAC. How quickly does an average customer recover their acquisition cost through usage or engagement? For health systems and payers buying on your behalf, this translates to: how quickly does this tool move the satisfaction and retention metrics they’re being held accountable for? You can’t answer this if you’re chasing top-line growth. You have to measure unit-level retention and speed.

Second, engineer for behavior change, not just information. Your product can be superior on every clinical or functional metric and still fail if it doesn’t change user behavior. Digital health tools have a 32% unhelpfulness rate. That’s not because the science is bad. It’s because the tool is another thing the user has to think about, not something that saves them thinking. This is a product problem, not a messaging problem. Your roadmap should treat behavior change (the ecosystem, accountability, frequency, human connection) as first-order product requirements, not marketing overlays.

Third, build community and frequency into your core unit. The stickiest healthtech at scale isn’t the tool with the most sophisticated algorithm. It’s the tool that creates identity and recurrence. Solid Core serves a quarter million people monthly with dinner-party intimacy. Hyrox raised prices 25% and sold 50K tickets in an hour because people identify with the community. This doesn’t require you to own the entire ecosystem. It requires you to understand that frequency metrics and community strength are your actual retention levers.

The Runway Question

Most healthtech founders have 24-36 months of runway. In that timeframe, acquisition cost recovery matters more than long-term LTV. If your payback period is 18+ months and you’re burning capital to acquire customers who churn before payback, you’re playing a game you can’t win. The market window (the satisfaction collapse) won’t stay open forever. Health systems and payers will stabilize. Consumers will find equilibrium with some set of tools. Your distribution advantage is time-limited.

Build for retention now, not growth later. The investors who understand that the VC thesis has shifted from growth at all costs to retention as primary investment vector are the ones funding the next tranche. The founders who understand that their buyer has a retention problem, not just a feature problem, are the ones building defensible unit economics.

The satisfaction cliff is your beachhead. Your retention product is your moat.

MCP, or Model Context Protocol, is Anthropic’s open standard for connecting AI models to external data sources and tools. It lets an AI agent call structured functions against a data source instead of just generating text from what it already knows. For healthcare, this means an AI agent can query a patient’s medication list, pull lab results, or check allergy records from an EMR in real time, through a standardized interface rather than a custom integration.

The idea is sound. The execution is about to get very crowded.

The landscape as of right now

I’ve counted at least seven open-source FHIR MCP server projects on GitHub, most launched in the past six months:

Momentum’s FHIR MCP Server (Python). Built by a healthcare dev shop. LOINC code validation, a RAG pipeline for unstructured clinical documents, semantic search. Good documentation. Active development.

AgentCare by Kartha/Integranium (Node.js). FHIR integration plus PubMed and clinical trials database access. Positions itself as the bridge between EMR data and medical research. Setup instructions for Claude Desktop and Cursor.

WSO2’s FHIR MCP Server (Python). WSO2 is an established enterprise middleware company with existing healthcare customers. Their server does what you’d expect: expose any FHIR server as an MCP server, with OAuth2 support and Docker deployment.

Flexpa’s mcp-fhir (TypeScript). Flexpa is a health data company with an existing commercial product. Their MCP server is lightweight, focused on read operations, built by a team that already has FHIR production experience.

AWS HealthLake MCP (Python). Amazon’s entry. 11 FHIR tools, read-only mode for production safety, SigV4 authentication, 235 tests with 96% coverage. This is what it looks like when a cloud platform decides to support a standard.

health-record-mcp (TypeScript). Built by Josh Mandel, who co-created SMART on FHIR. When the person who helped design the protocol for connecting apps to health data builds an MCP server, developers notice.

And there are newer entrants building FHIR R6-native implementations, agent-first architectures with human-in-the-loop write guardrails, and clinical-skills-focused platforms that ship with 40+ pre-built clinical workflow templates.

Every single one of these projects does roughly the same core thing: FHIR CRUD operations, OAuth2 authentication, and MCP protocol support. Every one of them lets an AI agent read patient data from an EMR through a standardized interface.

Why this happened so fast

Three forces converged.

MCP became the default. Anthropic open-sourced the protocol. Claude Desktop, Cursor, VS Code, and other developer tools added native MCP support. Suddenly there was a standard way for AI agents to call external tools, and every developer building healthcare AI looked at the same problem: “I need to connect this to an EMR.”

FHIR finally works. A decade of regulation (21st Century Cures Act, ONC interoperability rules, CMS mandates) forced Epic, Cerner, and other major EMRs to expose FHIR APIs. The data access problem that plagued healthcare AI for years is, for reading at least, mostly solved at the API level. The “last mile” is making that access useful to an AI agent, which is exactly what MCP servers do.

The code isn’t hard. A basic FHIR MCP server that reads patient resources and returns them to an AI agent is a weekend project for a competent developer. The FHIR spec is well-documented. The MCP protocol is straightforward. The hard part was never the plumbing.

Which brings us to the actual question.

Subscribe now

If the plumbing isn’t the moat, what is?

Every FHIR MCP server on GitHub does the same basic thing. Search patients. Read observations. Pull medication lists. Return structured data to an AI agent. If that’s all your product does, you’re competing on README quality and GitHub stars.

The projects that will actually matter will differentiate on one of three things.

Clinical intelligence on top of the data. Raw FHIR resources are structured but not interpreted. A medication list is a list. An AI agent looking at a medication list still needs to know: are there drug interactions? Is the patient adherent? Does this regimen match current guidelines for their conditions? The FHIR MCP server that ships with clinical reasoning layers, guideline-mapped workflow templates, drug interaction logic, lab result interpretation, doesn’t just return data. It returns data with context. That’s a different product from a FHIR pipe.

One new entrant ships with 40+ pre-built clinical workflow templates covering medication management, preventive care screening, chronic disease monitoring, and lab interpretation, each mapped to specific clinical guidelines (USPSTF, ADA, ACC/AHA). No other FHIR MCP server does this at scale. Whether these templates hold up in production is an open question, but the thesis is right: the value is in the clinical layer, not the data layer.

Trust infrastructure for production deployment. A developer can install any of these servers against a public FHIR sandbox in 10 minutes. Connecting to a production Epic instance at an actual hospital is a different problem entirely. That requires: validated OAuth2/SMART on FHIR authentication against specific EMR configurations, a signed Business Associate Agreement, audit logging that meets organizational compliance requirements, a security posture that passes a health system’s vendor assessment, and someone on the other end of a phone when something breaks at 2am.

Most of the projects on GitHub are developer tools, not enterprise products. The ones backed by companies with existing healthcare relationships (WSO2, Flexpa, AWS) have an advantage here, not because their code is better, but because they can sign a BAA and show up for a vendor security review.

Workflow integration, not just data access. Reading from an EMR is step one. The real value is in what happens next: proposing a clinical action, creating a care plan, generating a referral, drafting a prior authorization. These are write operations, and write operations in healthcare require approval workflows, audit trails, and liability frameworks that don’t exist in any current FHIR MCP server.

The R6-native project I mentioned earlier is the only one I’ve seen that implements human-in-the-loop write guardrails at the protocol level, with propose-then-commit semantics and step-up authorization tokens. It’s a proof of concept, not a product, but it’s pointing at the right problem: AI agents that can read patient data are useful. AI agents that can safely act on patient data are valuable.

What the teams that survive will figure out first

If you’re building in this space right now, the FHIR integration is done. Congratulations. That’s table stakes. Here’s what actually determines whether you’re still here in 18 months.

Put your faces on the site. Several projects in this space have no team information, no company page, no visible healthcare credentials. If you’re asking a health system to connect your software to their patient data, “we’re anonymous but trust us on HIPAA” is not going to survive a vendor security review. The teams with visible healthcare backgrounds (clinical informatics experience, prior EMR integration work, named advisors with health system relationships) start with a trust advantage that code quality can’t replicate. If you have that background, show it. If you don’t, go get advisors who do and make them visible.

Get one production deployment and talk about it. Every project in this space demos against the SMART Health IT public sandbox. That’s fine for development. But the gap between “works against a test server with synthetic data” and “connected to a production Epic instance at a 500-bed hospital” is where most developer tools in healthcare go to die. The first team that publishes a credible case study with a named health system will own the category’s trust narrative. Everyone else will be chasing that proof point.

Answer the business model question before you need the revenue. Open-source is a distribution strategy, not a business model. If your project is MIT-licensed with no visible commercial path, you’re building a community, not a company. If your commercial page says “Contact Sales” with no pricing signal, you’re losing every Series A startup that needs managed infrastructure but won’t sit through an enterprise sales cycle. Figure out who pays, for what, and at what price point. A $500-2,000/month self-serve tier captures revenue that “Contact Us for custom pricing” lets walk away.

Acknowledge that you have competitors. None of the newer projects mention alternatives on their sites. They position as if they’re creating a category when they’re entering one. Your buyer will find 7+ options on GitHub before they find you. If your site doesn’t answer “why this one and not those?” the buyer will decide based on GitHub stars and whichever README they understand first. Name the alternatives. Be honest about what they do well. Explain what you do differently. That’s not weakness. That’s commercial maturity, and it’s the signal that tells a buyer you’ve actually thought about the market you’re in.

The pattern I keep seeing

This is a recurring dynamic in healthcare AI: a protocol or standard gets adopted, a dozen teams build infrastructure around it simultaneously, and within 12-18 months the space consolidates around 2-3 winners.

It happened with FHIR app platforms (Redox and Health Gorilla won, a dozen others didn’t). It happened with clinical NLP APIs (a few large players absorbed the startups). It’s happening now with FHIR MCP servers.

The teams that win these consolidation races are rarely the ones with the best initial code. They’re the ones that solve the trust problem first: named humans with healthcare credentials, production deployments at real institutions, signed BAAs, completed security assessments, and a business model that doesn’t depend on GitHub stars converting to enterprise contracts through sheer hope.

The FHIR plumbing is free. The clinical intelligence, the production trust infrastructure, and the workflow integration on top of it are where the actual business lives.

Seven teams are building the same pipe. The ones that survive will be the ones that figure out what goes through it.

Forward wasn’t the first.

HealthSpot raised $50M, signed Mayo Clinic, Cleveland Clinic, and Rite-Aid, built nearly 200 kiosks, and filed Chapter 7 in 2016. In France, H4D pioneered the telehealth booth in 2009, raised €15M, and declared bankruptcy in September 2024. Babylon Health invested $30M in Higi’s 10,000 pharmacy kiosks, then Babylon itself collapsed.

Combined: roughly $750M in venture capital poured into telehealth kiosks. Zero surviving US winners at scale.

And new entrants keep showing up. I’ve seen at least three in the past six months.

So either every founder in this space is delusional, or there’s something real underneath the wreckage that nobody has built correctly yet. I think it’s the second one. But to see it, you have to understand why the first wave died.

The pattern that killed them all

Every failed kiosk company died the same way. The technology worked. The business model didn’t.

Forward tried to replace the doctor’s office with a $1M autonomous pod in a mall. Patients didn’t want a self-service healthcare experience in the same building as a Cinnabon. Former employees told Business Insider about malfunctioning blood draws and patients getting stuck inside the pods. The company planned to deploy 3,200 CarePods in 2024. They deployed five.

HealthSpot required patients to schedule appointments at the kiosk, which defeated the entire convenience pitch. They spent years on academic validation of the kiosk’s clinical functionality instead of testing whether the business model worked in the market.

H4D built the category in France starting in 2009 and deployed about 140 booths. Then Medadom and Tessan entered with devices that cost roughly a tenth as much. H4D couldn’t compete on price and went into judicial liquidation.

Higi placed 10,000 health screening kiosks in Walgreens and Sam’s Club locations. Free blood pressure and BMI checks. No care pathway attached. Observers routinely noted the kiosks sitting in dusty corners with “Out of Order” signs. Screening without a next step doesn’t create return visits.

Four companies, four variations of the same root cause: high hardware costs + low utilization + no clear reimbursement pathway + slow patient behavior change = cash burn that outpaces revenue.

The kiosk worked. The visit didn’t pay for itself.

Why the idea keeps coming back

The thesis behind telehealth kiosks isn’t wrong. It’s one of the few digital health concepts that directly addresses physical access to care, not just virtual access.

There are roughly 80 million Americans living in primary care shortage areas. Rural communities are losing hospitals and clinics. Physician shortages are projected to worsen through the 2030s. And while virtual visits via phone or laptop have scaled massively since COVID, a significant portion of clinical encounters still require some form of physical assessment: vitals, auscultation, point-of-care testing, visual inspection.

A kiosk with connected devices and a live provider on screen bridges that gap in a way that a Zoom call can’t.

The problem has never been the concept. It’s been the execution model.

Every prior entrant treated the kiosk as a consumer healthcare destination. Build the hardware, place it somewhere with foot traffic, and wait for patients to show up. That model requires generating demand from scratch, which is expensive and slow in healthcare.

What’s structurally different now

Three things have changed since the first wave of kiosk failures.

Post-COVID telehealth permanence. Before 2020, telehealth reimbursement was limited and state-dependent. The pandemic forced permanent expansions in most states. Patients who had never done a video visit now consider it normal. The behavioral barrier that plagued HealthSpot and early H4D deployments is materially lower.

Expanded pharmacist scope of practice. This is the big one, and almost nobody in the kiosk space is talking about it.

California, Oregon, Colorado, and a growing list of states have passed legislation allowing pharmacists to prescribe for conditions like UTIs, birth control, PrEP, smoking cessation, and travel medications. Some states allow pharmacists to order and interpret point-of-care lab tests. The scope keeps expanding.

The constraint: most pharmacies, especially independents, don’t have the physical infrastructure to deliver these services. No private consultation space. No connected diagnostic devices. No documentation system that supports billing for clinical encounters. The pharmacist has the authority but not the setup.

Hardware costs have collapsed. H4D’s booths were expensive enough that Medadom and Tessan could undercut them 10x and still build a viable business. The component cost of connected diagnostic devices (BP cuffs, pulse oximeters, glucometers, even portable EKGs) has dropped substantially. A functional telehealth station in 2026 doesn’t need to cost $1M or even $100K.

Share

What a viable model might look like

If I were doing diligence on a telehealth kiosk company today, I’d be looking for a model that inverts the assumptions that killed the first wave.

Capture existing demand instead of creating new demand. The first-wave model was: put a kiosk in a high-traffic location and hope patients discover it. A viable model would put the kiosk where patients are already seeking care, in a setting where a provider already exists. Pharmacies are the obvious fit. The pharmacist is there. The patient walked in with a need. The kiosk provides the infrastructure for a clinical encounter that both parties already want to have.

Make the provider the pharmacist, not a remote physician. Building a telehealth provider network from scratch is expensive and creates utilization risk. You’re paying doctors to be available for patients who may not show up. If the pharmacist is the primary provider for the encounters they’re now licensed to handle, remote physician backup becomes the exception, not the default. That changes the cost structure entirely.

Sell to the pharmacy, not the patient. The first wave treated the kiosk as a consumer product. A viable model would treat it as practice infrastructure. The pharmacy pays for the booth because it enables clinical services they can now bill for. The ROI is measurable: before the booth, the pharmacy filled prescriptions. After the booth, the pharmacy also provides billable clinical encounters for UTIs, birth control consults, hypertension management, diabetes screening, and immunizations with vitals documentation.

Scope the hardware to specific clinical programs. Forward tried to replicate a full urgent care visit autonomously. That required expensive, complex hardware and created FDA classification questions. A smarter approach: equip the booth for the 5-7 clinical scenarios that pharmacists are specifically authorized to manage. Blood pressure monitoring, point-of-care A1C, rapid strep and UTI testing. Fewer devices, lower cost per unit, clearer regulatory pathway, tighter reimbursement codes.

Use AI for clinical decision support, not patient-facing triage. Forward’s pitch was “AI doctor in a box.” The market rejected it. Patients want human providers. A more defensible use of AI: help the pharmacist determine which patients qualify for pharmacist-prescribed treatments vs. which need a physician referral, flag drug interactions against the patient’s medication history, and auto-generate documentation for billing. That’s a tool that makes the pharmacist faster and more confident, not a replacement that makes patients uncomfortable.

The diligence questions I’d ask

For any new entrant in this space, whether I’m evaluating them for a fund or advising the founders directly, five questions determine viability:

What’s the unit economics story at a single location? Before anything about scale, show me that one pharmacy generates enough billable encounters to cover the hardware cost, the connectivity, and whatever revenue share or subscription the kiosk company charges. If the math doesn’t work at one site, it won’t work at a hundred.

Who pays and through what mechanism? Patient self-pay? Insurance reimbursement for telehealth visits? Pharmacist clinical services billing codes? Employer wellness programs? The answer determines everything about pricing, sales cycle, and cash flow timing. Most of the dead companies never had a clean answer to this.

What’s the regulatory posture of the diagnostic devices and any AI components? Are the devices FDA-cleared for self-administered use? Is the AI classified as clinical decision support (exempt from FDA oversight under certain conditions) or as a diagnostic tool (requires clearance)? Getting this wrong is expensive and slow.

Does the company know its competitive history? Not just current competitors, but the graveyard. A founding team that can articulate specifically why Forward, HealthSpot, and H4D failed, and specifically how their model avoids each of those failure modes, has done the work. A team that handwaves at “we’re different because AI” hasn’t.

What’s the pharmacy partner pipeline? Letters of intent from pharmacy chains or buying groups are the leading indicator. Not foot traffic projections or TAM calculations. Signed partners with deployment dates.

The bottom line

The telehealth kiosk category has absorbed $750M in venture capital and produced zero scaled winners in the US. The concept is sound. The first-wave execution model was not.

The structural shifts since then (telehealth reimbursement permanence, expanded pharmacist scope of practice, collapsed hardware costs) create conditions for a viable model that didn’t exist when Forward or HealthSpot were building. But that model looks different from what the first wave attempted. It looks less like “AI doctor in a box” and more like “clinical infrastructure for pharmacy-based care delivery.”

The founders who figure this out probably won’t raise $650M. They’ll build something smaller, more targeted, and more likely to survive.

That’s usually how it works in healthcare.

Arvita Tripati is the founder of Vahana Labs, where she does technical diligence for healthcare PE/VC and helps healthtech founders figure out why enterprise deals stall. She spent 18 years building products at companies like AliveCor, Vineti, and Korio that had to survive enterprise procurement in regulated markets.

They spent weeks rebuilding the auth module themselves. The deliverable met the spec. The spec just had nothing to do with how the product actually needed to behave.

The dev shop wasn’t the problem. The handoff was. The team building the module never got the context they needed to build the right thing.

This pattern shows up everywhere a product changes hands. Engineers who built a feature but never saw it used. CS teams deploying a product they’ve only seen in demos. Implementation leads training customers on workflows they’ve never run themselves. Clinical champions teaching colleagues during shift change with a two-page quick start guide.

Every handoff loses context. The founder or Product Lead sees the full picture. Everyone else sees their slice. And the gap between “works as specified” and “works for users” is yours to close.

Two gaps show up over and over. Both are fixable before they cost you a customer.

1. You validated the component. You never validated the product.

A company redesigned a surgical implant. R&D tested the new design. It performed well in controlled settings. Then it hit the operating room and added an extra step. The old version let surgeons do everything with one instrument. The new one required two. Within weeks, the highest-volume surgeon in the region had switched away to protect case time. The rep who flagged it texted her manager, logged it in Salesforce, emailed marketing. None of it reached the product team until returns started showing up.

The product wasn’t broken. The assembled experience was. Nobody validated the full workflow under real conditions.

Last week, the FDA flagged Abbott for the same structural problem with the FreeStyle Libre. Abbott tested individual sensor components for accuracy before assembly but never tested the finished, sterilized, packaged device as a unit. The FDA’s position: component-level testing doesn’t tell you whether the finished product works when it reaches the user.

The software version is quieter but the mechanics are identical. Your feature works in staging. It works in the demo environment. It works when your head of product clicks through it. Then it meets a 12-hour nursing shift, an EHR that’s two versions behind, and a Wi-Fi connection that drops in the east wing. The assembled experience fails in ways the component testing never caught.

What to do about it:

Before you hand off a build, write product behavior specs alongside technical specs.

The difference:

• Technical spec: “Auth module supports OAuth 2.0, SAML integration, handles session tokens, returns 401 on invalid credentials, complies with HIPAA timeout requirements.”

• Product behavior spec: “Nurse authenticates once at application launch. All modules share her session in a single browser window. Badge tap after timeout returns her to the exact screen and field she left within 2 seconds.”

The first one, someone can build without understanding your product. The second one requires knowing how a nurse actually uses the tool and how all the pieces fit together. That’s the document that prevents the two-browser-tab problem.

Before you accept a build, run a hostile conditions validation. Not the staging environment. Your worst-case production scenario. The oldest hardware your customer uses. The slowest network connection. The user with the least training. The shift where everything is already behind schedule.

If the assembled product survives that, you have something you can put in front of a pilot site. If it doesn’t, you found the problem before your users did.

2. The people deploying your product don’t know what “working” looks like.

Your product team knows which usage patterns signal success and which signal trouble. They know the difference between “user opened the app” and “user completed the full workflow without reverting to the old process.”

Does your CS lead know that? Does your implementation person? Does your clinical champion when she’s teaching her team during shift change?

Usually, no. The definition of “working” lives in the product team’s head or in a PRD nobody outside engineering has read. Everyone else is running on instinct.

Abbott’s contract manufacturers, the teams doing final assembly and packaging of the Libre sensors, were never given the accuracy performance requirements for the finished device. They didn’t know what “good” meant for the product they were physically building. The FDA called this out explicitly: you can’t hold people accountable to standards they’ve never seen.

The startup version: your CS person sees adoption drop at week 3 and doesn’t know whether that’s normal learning-curve friction or a sign the workflow doesn’t fit. Your champion’s nurses hit a confusing screen and work around it instead of flagging it. Nobody told them what to watch for.

What to do about it:

Two documents. One for whoever builds the product, one for whoever deploys it.

For the build: a product context brief. One page. Not the requirements doc. The doc that sits next to it.

Three questions:

• Who is using this and when? “Nurses during 12-hour shifts with an average of 90 seconds between patient interactions. They won’t read a tooltip. They won’t watch a training video twice. If this feature adds a step, they will work around it.”

• What does success look like from the user’s perspective? “The user never notices this feature exists. It runs in the background. If they’re aware of it, something is wrong.”

• What are the failure modes we care about? “User gets locked out mid-shift. User has to re-enter credentials after a timeout. User sees an error screen they don’t know how to resolve without calling IT.”

This isn’t a spec. It’s the context that makes the spec make sense.

For the deployment: a pilot health spec. Also one page. This goes to your CS team, your implementation lead, and your champion’s team.

Three sections:

• Week 1 / Week 3 / Week 6 benchmarks. “Week 1: 60%+ of assigned users complete at least one full workflow without reverting to the old process. Week 3: Support tickets per user declining, not flat. Week 6: 3+ workflows per user per shift with no manual workarounds.”

• Yellow flags. “Usage spikes Monday, drops by Wednesday. Users log in but don’t complete workflows. Champion stops attending check-ins.”

• Red flags. “Fewer than 40% of assigned users active by week 3. Users creating manual workarounds alongside the tool. Champion’s team citing ‘too busy’ more than twice in a check-in.”

Distribute both documents before the handoff happens. The context brief goes to your build team before they write code. The pilot health spec goes to everyone touching deployment before the first user logs in.

If your champion’s nurses can’t tell whether the pilot is healthy, they can’t flag problems early. And if your build team doesn’t know who’s using the product or under what conditions, they’ll keep delivering technically correct features that fail in context.

The common thread

The founder sees the full product. Everyone else sees a handoff.

Your engineers see the feature they’re building. Your CS team sees the deployment they’re running. Your champion sees the tool she’s asking her team to use. None of them have your context unless you give it to them.

The fix is cheap. A context brief. A pilot health spec. A hostile conditions validation before you call something ready. The cost of not doing it is a pilot that dies at week 3 and a champion who stops returning your emails.

Build the context into the handoff. Validate the assembled product, not just the parts. Make sure everyone touching your product knows what good looks like.

The work isn’t hard. The discipline of doing it before you need to is.

She described the tension between idealized design processes and the real-world constraints of time, risk, and unclear ownership. Her framing resonated deeply, especially the parts about doing invisible but critical design work that never makes it into Jira tickets, sprint retros, or regulatory documentation.

This post distills some of those takeaways and offers a tactical toolkit for anyone working in high-risk environments where design isn’t just about UX polish, but about traceability, risk reduction, and product credibility.

Design-as-Deliverable vs. Design-as-Strategy

Most regulated companies know how to operationalize engineering. Design, on the other hand, often gets defined by its outputs: screens, prototypes, mockups. But the strategic inputs and reasoning behind those artifacts? Rarely captured.

As Melissa put it:

"Clients and companies… their expectation is a design deliverable is high fidelity product mock-ups… not the upstream framing, risk triage, or synthesis that makes those mockups useful."

If your product will be evaluated by the FDA, a hospital procurement team, or a payer contract review, design decisions need to be legible—not just beautiful. That means documenting the real work: the risk calls, the user proxies, the triage, the alignment.

What Gets Missed When Design Work Is Invisible

"Design is a very ambiguous, messy process. Engineering… is a very concrete, known, and understood process. You can measure it. Design? Not so much."

Here’s what typically doesn’t show up in a roadmap or project brief, but fundamentally shapes product success:

• Competitive teardown to inform guardrails.

• Support ticket mining as proxy for user feedback.

• Mapping assumptions across stakeholders.

• Manual risk triage when timelines prohibit research.

• Decisions made not to test based on downstream impact and real-world constraints.

In a regulated context, these are not optional extras. They’re your design governance. And if they’re undocumented, they can’t be audited, shared, or defended.

Design Governance: Making the Invisible Legible

The solution isn't to evangelize design harder. It's to make your strategic work readable in the languages of compliance, product, and engineering.

Below is a simple toolkit I use to surface invisible design strategy.

1. The Shadow Process Ledger

Use a living artifact (Figma board, Notion page, Google Doc, or Confluence entry) to log the thinking behind the deliverables.

Sections to include:

• Key assumptions and unknowns.

• Risks flagged (e.g. workflow mismatch, privacy edge cases).

• Backchannel insights (Zendesk, call notes, internal feedback).

• Options considered and rationale for rejection.

• Provisional success criteria ("20% decrease in task abandonment").

Tip: Share with PMs, compliance, and QA, not just other designers.

3. Visual Risk Breadcrumbs in Figma or Whimsical

Don't hide ambiguity behind polish. Embed micro-signals that reveal uncertainty or design reasoning:

• Annotations like: "Assumes site coordinators complete this step in under 2 minutes."

• Labels: "Pending clinical input" or "RISK-CHECKPOINT."

• Links to synthesis docs or Slack threads that informed decisions.

This shows you're not ignoring complexity, rather you're surfacing it so others can participate in the trade-offs.

Operating Framework: The Designer as Strategic Risk Partner

Reframe the Role: Designers are not stylists. In regulated products, they are risk translators. They surface ambiguity, clarify user intent, and prevent silent failures.

From To "Where’s the mockup?" "What risks did this design de-risk?" "Just make it pretty" "What assumptions are we embedding?" "Will it pass heuristics?" "Will it hold up in an FDA audit?"

Behavior Shift:

• Start roadmap discussions with what you don’t know.

• Embed strategy into visual artifacts.

• Document design decisions with the same discipline as technical architecture.

"We’ve accepted that engineers have Jira. Designers need their own audit trail if they want a seat at the regulatory table."

Strategic design isn’t about being the loudest voice in the room. It’s about embedding traceability, decision quality, and user advocacy into environments that demand rigor. That starts by making your invisible work legible.

This isn’t about being agile or iterative. Those are good things. This is about pushing critical structural decisions downstream—decisions around governance, data use, go-to-market, and monetization—because they’re hard or uncomfortable.

Let us be very clear:
Product discovery is about reducing risk before you scale, not after.

The Financial Cost of Kicking the Can

Companies that defer foundational decisions usually pay for it 2–3x over later, in capital, in lost deals, and in discounted valuations.

One of the clearest examples of governance debt becoming fatal was uBiome. The company raised over $100M to scale its at-home microbiome testing platform. But it neglected critical guardrails around billing, medical necessity, and patient consent.

What followed? Federal investigations, a highly publicized FBI raid, and bankruptcy. Capital that should have fueled product and growth was instead consumed by legal exposure and compliance cleanup.

It’s an extreme case, but it reflects a common pattern: capital meant for acceleration gets reallocated to repairs when key risks go unaddressed in the early stages.

This isn’t rare.

Take the now-infamous example of DeepMind and the UK’s NHS. They built a promising app, Streams, for early detection of kidney failure was trained on real patient data. But they skipped a few critical governance steps: the data use agreement didn’t meet legal consent requirements, and patients weren’t informed.

They didn’t just get a wrist slap.
They got a public inquiry, reputational fallout, and a product eventually shut down. The cost wasn’t just compliance: it was momentum, partnerships, and trust.

Hope Is Not a Strategy

They build without mapping their assumptions.
They launch without understanding the regulatory landscape.
They scale without identifying their riskiest go-to-market or monetization bets—let alone testing them.
They assume those details can be solved “later,” when in reality, they’re the very questions that determine whether the business is fundable, scalable, or even viable.

This isn’t product development—it’s just hope, dressed up as velocity.

Valuation Hits from Governance Gaps

Here’s what I see in diligence rooms and hear about from founders:

• Valuation discounts of 15–30% when governance and compliance gaps are discovered

• Enterprise deals delayed by 3–6+ months due to unclear data handling or security posture

• Team churn when internal systems are rebuilt under pressure rather than by design

Investors aren’t just penalizing the fix cost. They’re pricing in the execution risk.

And when you need the money most, these gaps don’t look like scrappiness, they look like liabilities.

How Boards Should Measure Governance Risk

Good governance at early stages isn’t about bureaucracy. It’s about buying down risk efficiently. Here’s how board members can track it:

1. Tech debt ratio – Target ≤20:80 tech debt to new feature work at early stages

2. Delayed deals – Track how many enterprise opportunities are slowed by security, pricing, or compliance

3. Sales cycle length – Use it as a leading indicator of buyer trust friction

4. Pivot cost accounting – Include legal, operational, and opportunity cost of late-stage fixes

What to Ask Founders

In my coaching sessions, I often ask:
“What are your top 3 ‘we’ll figure it out later’ risks?”
If the answer is, “We haven’t really thought about that yet,” I worry more than if they said they had no competition.

Because these aren’t details. These are compounding risks.

The strongest founders I know don’t wait for certainty. They map their assumptions, build lightweight scaffolding, and pressure-test the unknowns before they become existential.

Minimum Viable Governance: What It Actually Looks Like

1. Map your risk landscape. Regulatory, pricing, data use, scalability & prioritize by impact × likelihood.

2. Invest 5–8% of early eng time in governance tooling, tracking, and infrastructure & build with auditability in mind.

3. Start expert conversations early. The highest-ROI seed investments I’ve seen aren’t in tools, they’re in 2-hour calls with security, pricing, and regulatory advisors.

Final Thought

Good product work isn’t just about building the right features.
It’s about building the right company.

And the companies that win aren’t the ones with perfect plans.
They’re the ones that pressure-tested their riskiest assumptions early and created systems to absorb the surprises that always come.