Most medical-device projects don't die frombad science. They struggle in the handoff between Research and Development whena technology isn’t mature enough for full product commercialization. Handoff too soon, and engineering teams burn critical timeline and budget solving issues while under leadership scrutiny and pressure for a faster launch timeline.
At Engenious we work with many of the top100 medical device companies, and we see benefits from applying NASA's1 Technology Readiness Level (TRL) thinking. In this article I’ll describe how we see successful groups make the right technology investments up front and realize major development timeline acceleration in overall project execution, avoiding expensive rework along theway.
Here is the case for using TRL thinking, and how to employ it on your projects.
In the 1970s, NASA had a problem every R&D leader will recognize. Engineers across the agency kept describing the same technology in different words. One team's "ready" was another team's "still a science experiment." Ambiguity gets expensive when you are trying to fly to Jupiter.
Stan Sadin at NASA Headquarters proposed afix in 1974: a simple numbered scale for how mature a technology is, from a basic principle observed in a lab to a system proven in operation.2 Ray Chase used it to assess a proposed Jupiter Orbiter design. It worked. By the 1990s, NASA had formalized the nine-level scale,3 and the Departmentof Defense, the Department of Energy, ESA, and the European Commission had all adopted it.
What made it stick is what makes it useful in medical device design. R&D is a naturally gray process. TRL does notpretend otherwise. It draws nine lines through the murk and gives everyone the same words for technological maturity, four of which we see as most important:
TRL 1 is a basic principle observed
TRL 4 is validation in the lab
TRL 6 is a prototype proven in a relevant environment
TRL 9 is proven in operational use.
The scale does not remove the uncertainty. The scale names the uncertainty, so people can talk about it with a shared understanding.
A medical device program is a relay race run by teams, each with their own definition of done.
The baton pass between research and product development is where projects stall or die. The risk of failure is real:research puts it at roughly 75% of medical-device ventures that fail or never reach market .4
The named causes are telling. A 2024 reviewin the World Journal of Advanced Research and Reviews5 points to the following reasons device programs fail:
Note that "the science didn't work" is not in the list. Most are coordination failures. The technology was fine; the handoff was not. And the thing being handed off keeps getting harder to judge by eye: since 2014, software issues have overtaken hardware design as the leading cause of FDA device recalls .6
Underneath most of those coordination failures sits one question nobody answered out loud. Where does the R in R&D stop and real commercialization begin?
When research hands off a design at what it considers "done," product development often finds a design that is nowhere near ready to verify, validate, or manufacture. Well-intended research teams thought they were passing a mature technology. Product development received a science project. Both teams were right by their own definition, which is exactly the problem. Without a shared scale, "ready" is subjective, and the two groups are arguing about a number neither of them has written down.
We have seen this play out. A benchtop prototype clears its technical review and is transferred to product developmentas "ready." Weeks in, the receiving team finds a critical, use-related requirement had never been captured, because the concept had only ever been handled by the engineers who built it, not by the caregivers who would actually use it. This is technology debt that requires a major rework. The program stalls to re-run the formative human-factors study, adjust the design and re-prototype. Months of schedule, gone, on a design some had already called finished.
The later a missed requirement surfaces,the more expensive it is to fix, because the fix now has to unwind every downstream decision built on top of it. The device industry has measured this. Drawing on the classic GTE, TRW, and IBM studies, Medical Device and Diagnostic Industry reports that catching an error while requirements are still being defined costs 5 to 10 times less than catching it once the design is being built out, and roughly 20 times less than after the product reaches the field.7
A requirement caught in a shared review is cheap. The same requirement caught after design transfer is not.
Medical-device development already runs on a staged process, whether the FDA pathway is a 510(k), a De Novo, or a full PMA. Concept, feasibility, design inputs, design outputs, verification, validation, design transfer, and post-market. Design controls under ISO:13485 and risk management under ISO: 14971 drive everything.
Lay the FDA process next to the TRL scale and they rhyme.
They are not identical, and they should not be forced to be. TRL measures technical maturity. The FDA pathway governs regulatory and quality process. But they run in parallel, and that is the point. TRL gives you a language for readiness that sits alongside your design controls without replacing them.
Put the two on one axis. Keep your existing design-control stage-gates. Add a TRL tag to each, so every gate carries both a process milestone and an agreed maturity level. The diagram below shows one way to draw it, with NASA's TRL definition on top, a device-development phase name below, and the handoff points marked.
The value is not the picture. It is the conversation the picture forces. When research and product development both point at the same scale, "is this ready?" stops being an opinion and becomes a question with a defined answer. R&D Leaders can set an explicit rule: nothing transfers below TRL 6. Leaders can see the gap between where research hands off today and where product development needs to receive. Teams can put a number on the rework that gap creates.
One thing to watch as you map the two together: some FDA milestones pin cleanly to a TRL number, and some don't. That is not a flaw in either system. It tells you where the overlay is precise and where it needs judgment.
Design validation is the clean fit. Under 21 CFR 820.30, validation must be run on production units or their equivalents, which means it cannot honestly happen until the design is essentially frozen and built the way it will ship. That lands squarely at TRL 8, and there is little room to argue it earlier. When an FDA requirement dictates the artifact, the TRL is fixed with it.
Design verification is looser. Verification, confirming outputs meet inputs, happens progressively across builds rather than at a single moment, so it tracks across TRL 5 through 7 depending on which requirements you are checking and on what hardware. Tagging it to one number oversimplifies it; the honest mapping is a band, not a point.
A first-in-human or clinical study is the one that resists a tidy tag entirely. The regulatory trigger (an IDE under 21CFR 812) is a hard gate, and design controls must be in place before the study starts. But the technical maturity going into that study varies by device andrisk class, so where the clinical milestone sits on the TRL scale, roughly TRL7, is a range you set deliberately with your quality and regulatory teams, not a number the scale hands you.
The lesson is not to force every FDA milestone onto a single TRL. It is to know which ones the regulation nails down for you and which ones you have to place by agreement, and to make that callout loud rather than by default.
You can run this on a live program this week. The point is not the chart itself; it is the conversation the chart forces between research and product development. Four tactics:
The worksheet below is the whole method on one page. Fill in your own phases, the TRL each gate demands, and the evidence you'll require to sign off. Bring it to your next handoff meeting.
