Product-market fit for a MedTech startup is not the same problem as product-market fit for a SaaS startup. You cannot hand your device to a patient next week and iterate. What you can do — and must do — is verify the market before you commit to the regulatory path. That means proving the clinical problem is real, proving the hospital will pay, proving the doctor will change their workflow, and lining up clinical partners on Day 1. If any of those four is missing, you do not have PMF yet, no matter how good the device is in the lab. Fix the market verification before you spend six figures on MDR, or you will verify the wrong product with the wrong money.

By Felix Lenhard and Tibor Zechmeister. Last updated 10 April 2026.

TL;DR

  • MedTech product-market fit is bounded by a hard rule: you cannot put an uncertified device in front of a patient for commercial use. The regulation that makes this non-negotiable is Regulation (EU) 2017/745.
  • You cannot test the technology with end users until you have evidence, but you can verify the market — the clinical problem, the buying unit, the workflow, and the willingness to pay — before MDR spending starts.
  • The decision-making unit in a hospital is layered: the hospital buys, the doctor uses, the patient benefits. You have to sell to three different people with three different pains, and you do not get PMF until all three say yes.
  • Felix's threshold for MedTech PMF: the device must be 10 to 20 times better for the buyer — measured in minutes saved per case, patients processed per day, or euros saved per procedure — not 10 to 20 percent better.
  • Clinical partners come on board on Day 1, not at launch. They are your friendly first customers, your source of clinical data, and your honesty check when the lab version does not survive contact with the real ward.
  • The business model has to check out before regulatory work starts. Regulatory does not kill a product with good PMF — it kills products that had no PMF to begin with.
  • Intended purpose under Article 2(12) is where market verification and regulation meet. Write it sharp, defend it early, and you save yourself a year of rework.

An EUR 1.8 million device that worked everywhere except the real world

A founder Felix worked with spent EUR 1.8 million building something that was beautiful in a lab. The prototype ran exactly as designed. The measurements were clean. The algorithms behaved. Every demo looked like a finished product.

Then it went into the real world.

Users did not follow the process. They skipped steps. They ran the device in an order nobody had planned for. They put it in settings the lab version had never seen — noisy, interrupted, rushed, between two other procedures, with a nurse helping who had not been trained. The device did not break. The device worked exactly the way it was designed to work. The users did not.

The company burned EUR 1.8 million learning that usability and user experience are paramount in MedTech, and that what works in a controlled lab session is not the same thing as what works when a tired clinician picks it up at 3 in the afternoon in a ward that smells like disinfectant and bad coffee. They had verified the technology. They had not verified the market.

That is the gap this post is about. In SaaS you can verify the market and the technology in the same week — ship a beta, watch the analytics, iterate on Monday. In MedTech you cannot. Article 2(1) of Regulation (EU) 2017/745 defines a medical device by what it claims to do for a patient, and the moment you put one in a patient's hand for clinical use, the full weight of the regulation lands on you. (Regulation (EU) 2017/745, Article 2, paragraph 1.) You cannot iterate the device with users the way a SaaS founder iterates a signup flow. You have to separate market verification from technology validation, run the market verification first, and make sure the regulatory money only starts flowing when you already know what you are building and for whom.

Why MedTech PMF is not the same as SaaS PMF

Most startup founders learned about product-market fit from a SaaS vocabulary — Eric Ries, the lean startup loop, the build-measure-learn cycle, the retention cohort, the forty-percent disappointed survey. The logic is simple: ship a minimum version, get it in front of real users, measure behaviour, adjust, ship again. The cycle runs in days. The cost of a bad hypothesis is a wasted sprint.

That playbook does not translate cleanly to MedTech. Three things break the loop.

First, you cannot put an uncertified device in commercial use with patients. The regulation draws a bright line around what counts as "placing on the market" and "putting into service," and you cross it the moment you let a device do its intended clinical job outside a properly set up clinical investigation. The regulation even defines the path for testing devices that are not yet certified — clinical investigations under Article 62 and following, with the full documentation regime of Annex XV. (Regulation (EU) 2017/745, Articles 62 to 82 and Annex XV.) You can run trials. You cannot run a SaaS-style public beta.

Second, the iteration cycle is months, not days. Every hardware revision has to be re-tested for safety. Every software update that changes intended behaviour on a certified device has to go through a change control path. Every clinical claim you test has to be reflected in the clinical evaluation. You do not iterate a medical device the way you iterate a landing page.

Third, the buyer and the user and the beneficiary are three different people. In SaaS that is sometimes true and mostly not — the person who signs the contract is often the person who uses the product, and the person using it is often the person being helped. In MedTech that alignment almost never holds. The hospital signs the purchase order. A specific doctor uses the device. A patient is the one whose life gets better, worse, or unchanged. Getting all three to say yes is harder than getting one to say yes, and the PMF signal you think you are seeing is usually coming from only one of the three.

The mistake first-time MedTech founders make is porting the SaaS PMF playbook without those three adjustments. They build a lab prototype, show it at a conference, get a handful of doctors excited, and declare PMF. Then they raise money, start the regulatory project, and discover twelve months later that the doctors who were excited never asked their hospital procurement for a budget, the hospitals they did pitch did not care about the metric the device improves, and the patients who would eventually benefit have no seat at the table. The company has spent runway verifying the wrong signal.

The principle that makes MedTech PMF work: you cannot test the tech, but you can verify the market

Here is the line to tattoo on the inside of your forehead.

You cannot test the technology with end users before you are certified. You can absolutely verify the market before you spend a euro on certification.

Everything in this post hangs off that distinction. Market verification is allowed — even encouraged — before you build. You can talk to hospital procurement. You can interview clinicians. You can shadow a ward. You can watch the actual workflow the device is supposed to enter. You can test the clinical hypothesis in literature, in real-world data, in conversations with heads of department. You can build financial models with real numbers from real buyers. You can get letters of intent. You can line up clinical partners who say yes, with conditions, and will sign when you have a device to investigate.

What you cannot do is put an uncertified device into routine patient care and iterate it the way a SaaS founder iterates a web app. That is the only thing regulation forbids at this stage, and most of the things you actually need to learn do not require that anyway.

The founders who survive and ship treat those two tracks as separate projects running in parallel. Market verification runs on conversations, shadowing, paper prototypes, clinical data, and honest financial models. Technology development runs on engineering, prototyping, and — when the time comes — formal clinical investigation under Articles 62 to 82 and Annex XV of the MDR. (Regulation (EU) 2017/745, Articles 62 to 82 and Annex XV.) The two tracks inform each other, but they never collapse into one.

The EUR 1.8 million lab device failed because the company only ran the technology track. They built something that worked and assumed the market would match. It did not. If they had run the market track in parallel — shadowing real users in real settings — they would have seen the usability gap in week three, not in month thirty, and they could have fixed it before the money was gone.

The decision-making unit in MedTech: hospital buys, doctor uses, patient benefits

The single biggest adjustment a founder has to make when moving from consumer or SaaS thinking into MedTech is understanding the decision-making unit. In a hospital setting the DMU has three roles, and you have to win all three.

The hospital is the buyer. Procurement, finance, the medical director, sometimes a value analysis committee — these are the people who sign the purchase order. They do not care whether your device is elegant. They care whether it saves the hospital time, money, complications, or beds. They think in cost per case, throughput per day, length of stay, readmission rates, reimbursement codes, and insurance contracts. If you cannot translate your device into one of those languages, the hospital will not buy it no matter how much the doctors like it.

The doctor is the user. The specific clinician who picks up your device, inserts it, activates it, reads the result, or operates it during a procedure. Their pain points are different from the hospital's. They care about workflow friction, cognitive load, training time, reliability under pressure, and how the device fits into the fifteen other things they do in a typical shift. A doctor who likes your device can champion it inside the hospital. A doctor who hates it can kill it in a single conversation with procurement, no matter how good the economics look.

The patient is the beneficiary. The person whose outcome the device exists to improve. The patient is almost never the buyer and usually not the user, but they are the reason the device exists and they are the lens the regulator will apply to every claim you make. A device that works for the hospital and the doctor but does not meaningfully help the patient will not survive clinical evaluation, and it should not. A device that helps the patient but ruins the doctor's workflow or blows up the hospital's budget will not get adopted even if it is clinically valid.

PMF in MedTech means all three are aligned. You do not have PMF until you can answer three separate questions with evidence, not hope.

  • What does the hospital gain, measured in euros, hours, or beds?
  • What does the doctor gain, measured in time saved per case or friction removed from their day?
  • What does the patient gain, measured in outcome, safety, or quality of life, in a way a clinician would actually defend in front of peers?

If any one of those answers is weak, your PMF is weak. Felix has watched more than one founder mistake doctor enthusiasm for market traction and walk into a regulatory project that was effectively sold to nobody who could sign a contract.

The 10-20x threshold: why incremental is not enough

Consumer software can win on a 20 percent improvement. A slightly nicer UI, a slightly faster workflow, a slightly cheaper price — enough to peel off users from the incumbent. That math does not work in MedTech.

MedTech has switching costs that do not exist in software. A hospital that adopts a new device pays in training time, in updated SOPs, in integration with their existing equipment, in procurement review, in infection control sign-off, in IT security review for connected devices, and in the lost learning curve of the old system. The total cost of switching is measured in months and tens of thousands of euros per department. No hospital pays that to save 20 percent.

Felix's working threshold for a MedTech device that actually has PMF is this: the device has to be ten to twenty times better for the buyer, measured in something the buyer counts. Not ten to twenty percent. Not a qualitative "it's really much better." Ten to twenty times.

That sounds extreme until you run the numbers. A device that lets a department process 50 percent more patients per day is roughly 1.5x better on throughput. That is usually not enough to overcome switching cost. A device that cuts the time per procedure from 45 minutes to 4 minutes — that is 11x, and that is the kind of number that reshapes how a department runs and makes procurement return your call on the first try.

The 10-20x threshold is not a quality standard. It is a market entry threshold. It forces you to find a single dimension the buyer cares about — time saved per case, patients processed per day, complications avoided per month, cost per procedure — and to build a device that moves that one number by an order of magnitude. That is PMF that survives the cost of regulation. Anything less is a feature, not a business.

Before you commit to MDR, run this exercise honestly. Pick the single metric your buyer counts. Estimate where the incumbent sits. Estimate where your device could sit. If the ratio is less than 10, either you have the wrong metric, the wrong buyer, or the wrong device. Find the right one before you spend on classification.

Clinical partners on Day 1, not at launch

The fastest, cheapest, most honest way to verify the MedTech market is to get clinical partners involved on Day 1. Not "once we have a prototype we are ready to show," not "after the seed round closes," not "when we have the regulatory plan locked down." Day 1, when the idea is still on paper.

A clinical partner in this context is a hospital department, a specific physician, or a clinical research unit that is willing to sit with you early, tell you where the idea breaks, and — once you have something to investigate — run it in their setting. That relationship plays four roles at once.

They are your market verification. A clinician who is willing to spend time with you on a paper concept is telling you the problem is real. A clinician who is not willing, no matter how polite they are, is telling you it is not — or at least not to them. That is a free PMF signal.

They are your source of clinical evidence. When the time comes to run a formal clinical investigation under Article 62 and following, the sites that have known you from Day 1 are the sites that move fastest. Cold-starting a clinical investigation with hospitals who have never heard of you adds months and euros you do not have. (Regulation (EU) 2017/745, Article 62.)

They are your honesty check. The EUR 1.8 million lab device would never have been built the way it was built if the founder had watched a real user in a real setting in week two. Clinical partners are the antidote to the lab-world bubble, which is the single most expensive bubble in MedTech.

They become your first friendly customers. This is the part founders underrate. The hospitals that participate in your clinical investigation and the clinicians who champion the investigation inside those hospitals are, almost always, the first commercial adopters after certification. You are not just getting clinical data — you are building the first ring of your sales pipeline, paid for with the clinical evaluation budget you were going to spend anyway. By the time the CE mark lands, you have three to five hospitals who already trust the device and have a process for using it. That is a real head start.

The founders who delay this step — who wait to have a polished prototype before they talk to hospitals — always regret it. The founders who start Day 1, even with a drawing on a napkin, build relationships that compound for years.

Business model before regulatory work

Here is the rule that saves more MedTech startups than any single piece of regulatory advice Tibor has ever given: the business model has to check out before you start the regulatory work.

Regulatory is a fixed cost of entering the market. For anything above unmeasured, non-sterile Class I, that cost is six figures minimum, realistically EUR 150,000 to well over EUR 500,000, and twelve to twenty-four months of calendar time before you can sell a single unit. If your business model does not support absorbing that cost and still ending up profitable, no amount of clever regulatory optimisation will save the company. You are not fixing a regulatory problem, you are fixing a business problem.

The discipline is to build the honest financial model before the regulatory project starts.

  • Who buys? (The hospital entity, not the doctor.)
  • How much does a unit sell for? (Based on real conversations with procurement, not aspirational pricing.)
  • How many units per year, per site, per geography? (Based on clinical need, not TAM slides.)
  • What does it cost to deliver? (Development, production, certification, PMS, PRRC, Notified Body fees, cybersecurity, usability engineering — all in.)
  • What does it cost to acquire the customer? (Conferences, clinical champions, distributor margins, reimbursement support.)
  • What is the gross margin per unit at steady state?
  • How many units does it take to break even on the regulatory investment?
  • How many years does that take?

If those numbers do not work, you do not start the regulatory project. You either pivot the product, pivot the buyer, pivot the geography, or stop. Starting a regulatory project with a broken business model is not bravery. It is expensive denial.

Felix has one sentence he says to founders at this stage. "I can do this, you can do this, but we need to do it right." Doing it right means making sure the business model checks out before the regulatory invoice shows up.

The connection between PMF and intended purpose

This is the part of the post where market verification and MDR regulation meet. It is also the part most founders miss.

Under Article 2(12), intended purpose is defined as "the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use, or in promotional or sales materials or statements, and as specified by the manufacturer in the clinical evaluation." (Regulation (EU) 2017/745, Article 2, paragraph 12.) That one sentence is the bridge between what you sell and what the regulation considers you to be selling.

The intended purpose is where your PMF hypothesis becomes a legal claim. You say, in one paragraph, what the device does, for whom, in what clinical context, with what benefit. That paragraph drives classification, clinical evaluation, labelling, and every claim you will ever be allowed to make. Change it later and large parts of the file have to change with it.

Here is what that means practically. If your market verification is sloppy — if you are still unsure who the buyer is, which clinical setting the device lives in, or what benefit you are actually promising — your intended purpose will be equally sloppy. And a sloppy intended purpose is the single most expensive mistake a first-time founder can make. It leads to the wrong classification under Annex VIII, the wrong conformity assessment route, the wrong Notified Body scope, and eventually to a rework that can add a year to the project and blow up the clinical evaluation.

The fix is counterintuitive. Do the market work early — clinical partners, hospital buyers, doctor workflow, patient benefit — and write your intended purpose as the final output of that work, not as an early guess you adjust later. The intended purpose should be the sentence your clinical partners would sign.

Regulatory does not kill good PMF — it kills products with no PMF to begin with

Founders like to blame MDR when their company fails. The regulation is heavy, the costs are real, the timelines are long, and it is tempting to point at the 180 pages of legal text and say, this is what killed us.

It is almost never what killed them.

Felix has watched enough failures to name the real pattern. The companies that die in the regulatory phase did not have PMF before they started. The regulation is not what finishes them — it is what exposes what was never there. When you have product-market fit, the regulatory work is slow and expensive but tractable, and the business on the other side makes it worth it. When you do not, the regulation is the gravity that reveals you were flying on hope.

One founder Felix worked with illustrates this exactly. Felix begged him to go out to customers and test. For eighteen months the founder did nothing — no customer conversations, no letters of intent, no revenue, no clinical partners, nothing to show investors. The company dissolved. It was not the regulation that killed it. It was the absence of a single conversation with a buyer during the year and a half the founder had to have them. Felix can name at least four other founders with the same pattern. None of them failed because MDR was too hard. They failed because they ran out of money before they verified that anyone wanted what they were building.

Contrast that with the EUR 50,000 first quarter an education-space founder pulled off in a completely different domain. He built a landing page, had conversations with customers, and actually built the product after people purchased. Zero marketing spend. People were begging him to give them the onboarding because he had answered the one question everyone had. The model translates directly to MedTech, with the difference that you cannot sell the device before certification. What you can do is sell the future device to hospital buyers who sign letters of intent, to clinicians who commit as clinical partners, and to distributors who commit to territories — all before you start the regulatory project. Same discipline, different currency.

The companies that survive MDR are the ones that did the market work early. The companies that die in MDR are the ones who thought the regulation was the hard part. The regulation is not the hard part. The market is.

The Subtract to Ship angle

Every activity in a MedTech startup should trace back to either the MDR — a specific article, annex, or standard — or to the business model. If an activity cannot trace back to one of those two, it is drag.

Subtract to Ship applied to PMF in MedTech is a short list.

  • Every feature on the prototype has to earn its place by moving the 10-20x metric your buyer counts. If it does not move that number, it is pulling the device away from PMF and toward complexity.
  • Every conversation you have in phase one should be with one of the three DMU roles — hospital buyer, clinician user, or patient beneficiary. Conversations with investors, advisors, and other founders are not market verification. They feel productive. They are not.
  • Every piece of clinical evidence you plan should be gathered with a clinical partner who is a real Day 1 relationship, not a cold site found at month twelve.
  • Every line of the financial model should have a source — a real number from a real buyer — or be marked as an assumption you have to test before the regulatory budget is committed.
  • Every sentence of the intended purpose should be defensible in front of both a clinician and a Notified Body auditor. If it is not, it needs another round before you move.

The subtraction is ruthless. Anything that does not earn its place gets cut. That is what makes it possible to run MedTech PMF work on a startup budget without waste. Read the Subtract to Ship framework for MDR for the full methodology across the whole certification project.

Reality Check — Where do you stand?

Answer these honestly. If more than two answers are weak, you are not ready to start the regulatory project.

  1. Can you name the single metric your hospital buyer counts — time per case, patients per day, euros per procedure, complications per month — and state your device's improvement on that metric as a real number?
  2. Is your device's improvement on that metric at least 10x, or are you in the 1.5-3x zone where switching cost will eat you?
  3. Can you name three specific clinicians — with names, departments, and hospitals — who would spend an hour with you this month to walk you through their workflow?
  4. Do you have at least one clinical partner who has verbally committed to participating in a clinical investigation when you have a device ready?
  5. Have you written a one-paragraph intended purpose that a clinician would sign off as accurate and a Notified Body would accept as specific enough to classify?
  6. Is your financial model built on numbers you got from a real buyer conversation, or on numbers you took from a slide deck?
  7. Have you identified the gap between what works in a lab environment and what will have to survive a real ward, and do you have a plan to close it before you spend on certification?
  8. Have you calculated the break-even point in units after the full regulatory investment, and does the clinical need in your geography support selling that many units?
  9. Can you articulate the benefit to the patient in language a clinician would defend in front of peers, or is your patient benefit currently a marketing sentence?
  10. If you were told tomorrow that the regulatory project will cost double and take a year longer, would your business model still work? If not, what is your plan for finding that out before you commit?

Frequently Asked Questions

How is product-market fit for a MedTech startup different from a SaaS startup? In SaaS you verify the market and the technology in the same loop — ship, measure, iterate, sometimes in the same week. In MedTech you cannot put an uncertified device into routine patient use, so you have to separate market verification from technology validation and run them in parallel. Market verification uses conversations, shadowing, clinical partners, and financial modelling. Technology validation ultimately uses formal clinical investigation under Articles 62 to 82 and Annex XV of the MDR. Both are real PMF work, but they use different tools.

Can I really verify the MedTech market before I have a prototype? Yes, and it is usually the cheapest and most honest verification you will do. Hospital buyers, clinicians, and department heads will talk to you about the problem space long before you have hardware. The right questions are about their current workflow, their current costs, and their willingness to change — not about your device specifically. A prototype can come later. The market conversation has to come first.

Who is the "customer" in MedTech — the doctor, the hospital, or the patient? All three, and the painful truth is you have to win all three. The hospital signs the contract and thinks in euros, throughput, and reimbursement. The doctor uses the device and thinks in workflow, friction, and reliability. The patient is the beneficiary and the reason the regulator exists. A device that wins the doctor but not the hospital does not get purchased. A device that wins the hospital but not the doctor gets purchased and never used. A device that wins both but does not help the patient will not pass clinical evaluation. PMF means all three.

What is a reasonable PMF threshold for a MedTech device? Felix's working threshold is 10 to 20 times better for the buyer, measured on a metric the buyer already counts — minutes per case, patients per day, cost per procedure, complications per month. Anything under that is usually not enough to overcome the switching cost of adopting a new device in a hospital setting. Incremental improvements win in consumer software. They almost never win in MedTech.

When should I start MDR work — before or after PMF is proven? Light phase-one regulatory thinking — intended purpose, classification hypothesis, clinical evaluation plan — can start early because it helps you avoid locking in a bad regulatory path. Full regulatory project spending should wait until the business model checks out and market verification is in place. See when to start MDR regulatory work for the detail on the sequencing.

Do I need clinical partners before I have a prototype? You need them before you have a regulatory budget, which usually means you need them before the serious prototype. Early clinical partner relationships cost nothing except time and pay back on four axes — market verification, clinical evidence, honesty check, and first commercial customers. See clinical partners from Day 1 for how to build the relationship without being needy.

Can I ship a wellness product first and add medical device claims later? Sometimes, for a narrow set of product categories. It is a legitimate phase-one strategy for some digital health concepts, and a catastrophic shortcut for others. The decision hinges on whether your wellness claims are defensible as non-medical and whether the pivot path to a medical device later is actually viable. See wellness first, medical device later for a proper treatment of the trade-off.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, consolidated text. Articles cited: Article 2(1) definition of medical device; Article 2(12) intended purpose; Articles 62 to 82 clinical investigations; Annex XV documentation requirements for clinical investigations. Official Journal L 117, 5.5.2017.
  2. Regulation (EU) 2023/607 of the European Parliament and of the Council of 15 March 2023 amending Regulations (EU) 2017/745 and (EU) 2017/746 as regards the transitional provisions for certain medical devices and in vitro diagnostic medical devices. Official Journal L 80, 20.3.2023.

This post is the hub for MedTech Startup Strategy & PMF in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Read it first, then work outward through the linked posts in the order that matches where you are in your project. Market verification before regulatory spending — every time.