Three Assumptions That Kill MedTech Companies in the NHS

Most MedTech companies don't fail in the NHS because their product is bad. They fail because they built it on assumptions that don't survive contact with reality.

These are the three I see most often.

It seems logical. Give clinicians more information (home-monitored vital signs, real-time alerts, continuous glucose readings) and outcomes will improve.

But more data creates a liability problem before it creates a clinical benefit.

If a patient's heart rate spikes at 2am and nobody acts on it, who is responsible? The GP who never signed up to monitor overnight telemetry? The hospital that commissioned the platform but didn't staff a response team?

Clinicians will not accept accountability they cannot operationally meet. And without clear ownership, your "more data" becomes a risk nobody wants to carry.

Before you build, ask: who exactly will look at this data, when, and what are they expected to do about it?

If you can't answer that precisely, you don't have a product. You have a problem.

This is the most common mistake, and the most fatal.

Every founder believes their product justifies a little extra friction. A few more clicks. One additional screen. A brief training module.

The answer is still no.

NHS clinicians are not working at capacity. They are working beyond it. The system has no slack. Every additional step, no matter how small, is competing against a workforce that is already triaging what they can and cannot do in a day.

Products that get adopted do one of two things: they remove steps from existing workflows, or they slot in so seamlessly that clinicians barely notice they're doing something different.

If your product demo includes the phrase "and then the clinician just needs to..." you have already lost.

From the outside, the NHS looks like a goldmine. Decades of patient records. Millions of interactions. Surely, with the right permissions, you could build something transformative.

The reality: NHS data is fragmented across dozens of systems that don't talk to each other. It's inconsistent in format, incomplete in coverage, and siloed by trust, by department, sometimes by individual consultant.

The gap between "data exists somewhere" and "data is usable for what we want to build" is measured in years, not months.

Companies that assume clean, integrated, analysis-ready data will burn through their runway discovering it doesn't exist. At least not in the form they imagined.

Before you build a data-dependent product, talk to someone who has actually tried to extract and link NHS data. Then adjust your timeline accordingly.

All three assumptions share the same root cause: building from the outside in.

These companies started with what the technology could do, not with how the system actually operates. They designed for a version of the NHS that exists in strategy documents, not in understaffed wards and fragmented IT systems.

The companies that succeed do it differently. They start in the mess. They understand the workflow before they try to change it. They ask who will own the data, who will act on it, and what happens when something goes wrong.

If you're building for the NHS and haven't pressure-tested these assumptions, now is the time.

Before the pilot fails and you're left wondering why.