The gap between a working prototype in the lab and a product generating revenue in the market is wider than most founders expect. It is also rarely closed by better science. The technical risk is usually the part a strong team has already de-risked. What stops most health-tech products is everything that surrounds the science: the regulatory decisions made too late, the evidence designed for the wrong audience, the workflow nobody validated, the reimbursement path nobody mapped.
Between us we have taken AI biomarkers through CE marking in Europe and FDA clearance in the US, implemented digital biomarkers across nine clinical trials, and built the commercial and operational machinery that turns a cleared product into first revenue. The lessons below are the ones we keep returning to. None of them are about the algorithm.
1. Decide your regulatory pathway before you finish the product, not after
Founders tend to treat regulatory approval as a gate at the end of development: build the product, then work out how to clear it. This is the most expensive sequencing error in health-tech.
Your regulatory pathway is a product decision. Whether your software is a medical device at all, what risk class it falls into, whether you are pursuing a 510(k), a De Novo, or a PMA in the US, and how MDR or IVDR classifies you in Europe, all of this dictates what you have to build and what evidence you have to gather. A claim you make casually in a pitch deck can move you into a higher risk class and add a year to your timeline. A predicate device you identify early can remove one.
When we cleared MRCP+ with both the FDA and a CE mark, the pathway was not something we reverse-engineered at the end. It shaped the intended-use statement, the evidence plan, and the product roadmap from the start. Map your pathway before you lock the product, and let it constrain your design rather than ambush it.
2. Treat clinical evidence as a commercial asset, not a compliance cost
There is a habit of thinking about clinical evidence as the tax you pay to get cleared: generate the minimum data the regulator demands, then move on. This wastes the single most valuable thing you will produce.
Your evidence has at least three audiences, and they are not the same. The regulator wants safety and performance against an intended use. The clinician wants to know it changes a decision they actually make. The payer wants to know it changes an outcome or a cost they actually carry. A study designed only for the first audience leaves you with a cleared product that nobody is convinced to adopt or pay for.
The discipline is to design one evidence programme that serves all three where possible, and to be deliberate about endpoint selection, comparator choice, and patient enrichment from the outset. When we implemented digital biomarkers across nine clinical trials, the data did double duty: it supported regulatory submissions and it built the commercial case at the same time. Evidence is expensive. Generate it once, and make it work harder than the regulator requires.
3. The lab proves it works. The market asks whether it fits.
A product can be analytically flawless and commercially dead. The lab answers the question “does it work?” The market asks a harder one: “does it fit into what people already do?”
Clinical utility is not the same as analytical validity, and adoption is not the same as either. A diagnostic that is more accurate but adds three steps to a clinician’s workflow will lose to a worse tool that slots into the existing one. We have written before about why UX is a regulatory risk in medtech; it is also a commercial one. The interface, the workflow integration, and the way results are delivered are not cosmetic. They determine whether a cleared product is ever used.
Test fit early, with the people who will actually use the product, in the setting where they will actually use it. The most useful question in a pilot is not “is this accurate?” but “what did you stop doing to use this, and would you do it again next week?“
4. A cleared product with no reimbursement path is still a science project
This is the lesson founders resist most, because it feels like someone else’s problem. It is not. In health-tech, the buyer and the user are frequently not the payer, and a product nobody can get paid for does not generate revenue no matter how well it works.
Reimbursement and market access are slow, structural, and largely outside your control, which is exactly why they have to be planned early. Coding, coverage, and the health-economic argument that justifies payment take longer to establish than the clearance itself. The companies that reach revenue fastest are the ones that started building the reimbursement case in parallel with the clinical one, not after launch.
When we designed the market-access and reimbursement strategy alongside the regulatory pathway for a digital health product, first commercial revenue followed within twelve months of the project starting. That timeline was not an accident of the technology. It was the result of treating access as a launch workstream from day one rather than a problem to solve once the product was cleared.
5. You are launching an operation, not a device
The final lesson is the one that is easiest to underestimate. A product launch is not a thing you ship. It is a coordinated effort across engineering, regulatory, clinical, quality, commercial, and operations, and it succeeds or fails on whether those functions move together.
When we led the launch of an AI imaging tool, the work involved managing a cross-functional team of twenty spanning product development, engineering, compliance, regulatory, sales, and marketing. The hard part was not any single discipline. It was the interfaces between them: the handoffs, the dependencies, and the decisions that needed three functions in the room at once. A regulatory delay stalls the commercial team. A commercial claim creates a regulatory obligation. A quality issue halts everything.
Founders who treat launch as a sequence of separate departmental tasks discover the interfaces the hard way. Build the operating model before you need it. Decide who owns each decision, how the functions report against shared milestones, and where the single points of failure are. You are not launching a device into a market. You are running an organisation that has to ship.
The pattern underneath
The five lessons share a structure. In each case, the work that determines whether a health-tech product reaches the market sits outside the science, and it has to start earlier than instinct suggests. Regulatory strategy, evidence design, workflow fit, reimbursement, and operational coordination are not the final stages of a launch. They are decisions that should shape the product from the beginning.
The good news is that none of this requires better science than you already have. It requires the science to be matched by commercial and operational discipline of the same standard. That is the gap between a strong prototype and a product on the market, and it is a gap that can be planned for.
If you are taking a health-tech product from the lab toward launch and want a clear-eyed view of where the real risks sit, that is exactly the kind of conversation we have every week.