From TRL to MRL: How Engineering Teams Take an Idea to Production

There is a significant difference between proving that an idea can work and proving that it can become a viable product.

Engineering teams can develop a promising concept, demonstrate its technical feasibility, and build a working prototype… and still have a long way to go. Moving from an early-stage technology to something that can be manufactured reliably requires teams to address not only technical risk, but also manufacturing, cost, people, processes, and the needs of the eventual user.

Technology Readiness Levels (TRLs) and Manufacturing Readiness Levels (MRLs) provide two ways to evaluate that progression. But as medical technology veteran, Doug Leach, discussed with JAKTOOL Founder, Jeff Kinsberg, on a recent episode of JAKTALK, moving an idea forward ultimately requires more than engineering alone.

What Technology Readiness Level Actually Measures

TRL provides a framework for evaluating the maturity of a technology as it progresses from an early concept toward a proven system.

The TRL scale moves from early scientific principles and concepts at the lower levels toward technologies that have been demonstrated and proven in operational environments at the highest levels.

For engineering teams, that progression helps answer an important question: How confident are we that the technology itself works?

Advancing through TRL levels requires increasingly representative development and testing. For example, an idea that works in a controlled laboratory environment has not necessarily demonstrated that it can perform under the conditions it will experience in the real world.

But proving that a technology works is only one part of product development.

Manufacturing Readiness Level Is the Scale Teams Cannot Ignore

A technically mature design is not automatically ready to be manufactured.

MRL considers the maturity of the manufacturing processes needed to produce that technology. As development progresses, teams must begin answering a different set of questions.

Can the product be manufactured consistently? Are the necessary materials and processes available? Are tolerances realistic? Can quality be maintained? What will production cost? Can the process ultimately support the required volume?

This is where the distinction between TRL and MRL becomes important.

TRL helps determine whether the technology works. MRL helps determine whether the organization is prepared to build it.

Development programs need to consider both, otherwise, a team may successfully demonstrate a technology only to discover that transitioning the prototype to production introduces an entirely new set of challenges.

Military TRL Requirements vs. Commercial Product Development

Technology maturity matters across industries, but TRL is particularly familiar within defense and aerospace development, where programs often need to demonstrate increasing levels of technical maturity before moving forward.

The underlying principle applies to commercial product development as well, even when teams do not formally assign a TRL.

A new product development process naturally progresses through similar questions: Does the principle work? Can we demonstrate it? Can we integrate it into a complete product? Will it perform under real-world conditions?

Answering those questions systematically helps teams reduce technical risk before committing significant resources to production.

Prototype to Production: Where the Challenge Changes

Moving from prototype to production is not simply a matter of making more copies of a successful prototype.

The problems change.

During his JAKTALK conversation, Leach argued that in medical technology development, there are often many ways to find a technical solution. The more difficult question is whether that solution corresponds with a meaningful market need and can overcome the practical barriers surrounding commercialization.

A prototype may prove a concept, but production introduces questions surrounding repeatability, manufacturing processes, supply chain, cost, quality, and scale.

Recognizing that distinction early can help prevent teams from treating manufacturing as something to figure out only after the engineering is finished.

Why the Hard Part Is Never Just the Engineering

Engineering problems may be technical, but successful product development depends heavily on people.

Leach saw this firsthand while working with clinicians and researchers at Hospital for Special Surgery. The clinicians understood their problems and areas of expertise deeply, but that did not mean they needed to understand every aspect of engineering and product development.

The strongest teams brought together people with different areas of expertise who could contribute what they knew, listen to others, and recognize when to step back.

That makes engineering team building an important part of technology development.

An effective team might include subject-matter experts, engineers, manufacturers, end users, business stakeholders, and outside engineering consulting services. No individual needs to understand every discipline. What matters is connecting the right expertise at the right stage of development.

That innovation mindset also requires knowing when to stop asking, How can I solve this myself? and start asking, Who is the right person to help solve it?

Curiosity as a Team Discipline

An innovation culture does not necessarily depend on constant breakthrough ideas.

Often, innovation engineering begins with something much smaller: curiosity.

People working closest to a process frequently notice problems others have accepted as normal. An experienced manufacturing employee may develop a workaround that makes a process more efficient. A clinician may improvise because the available medical device does not adequately address a need.

The opportunity is recognizing those moments and asking why.

Why does the problem exist? Why is it solved this way today? Why couldn’t it work differently?

That type of curiosity turns everyday problem solving into a more disciplined approach to engineering and innovation.

Where AI Fits Into the Engineering Process

AI adds another tool to that process, but it does not eliminate the need for experienced people.

Leach’s perspective on AI is intentionally practical: learn how to use it as a tool.

AI can help engineers research, analyze information, generate ideas, and evaluate possibilities. In healthcare, it can similarly help clinicians interpret information and support decision-making.

However, Leach does not see AI replacing the people closest to the problem. Those individuals bring firsthand experience and context that remain essential to recognizing what needs to be solved in the first place.

For engineering teams, the opportunity is to combine new tools with human expertise not treat the tool as the innovator.

Choosing the Right Engineering Partner

As technologies advance, the expertise needed to move them forward often changes.

An early concept may begin with a researcher, clinician, inventor, or internal engineering team. As development progresses, the program may require additional capabilities in design, prototyping, testing, manufacturing process development, or production.

The right engineering partner can help bridge those gaps.

JAKTOOL’s AIM® methodology provides a structured approach to moving complex engineering programs forward while addressing technical and manufacturing risk throughout development. By bringing engineering, prototyping, testing, and manufacturing capabilities together, JAKTOOL develops custom engineering solutions around the specific needs and maturity of each program.

The objective is not simply to reach the next readiness level. It is to understand what needs to be proven next and assemble the people, processes, and capabilities needed to prove it.

From an Idea to Something That Works

TRL and MRL provide useful ways to think about technology and manufacturing maturity, but readiness is ultimately the result of many decisions made throughout development.

Teams have to ask the right questions, understand the end user’s problem, test assumptions, build the right multidisciplinary team, and recognize when additional expertise is needed.

As Leach’s experience demonstrates, there is rarely a single breakthrough moment that makes innovation happen.

More often, progress comes from curiosity, collaboration, and disciplined problem solving, repeated at every stage between an idea and a product that can succeed in the real world.

 

Watch the JAKTALK episode that informed this article: Where Great Ideas Come From: The Process Behind Real Innovation