The biggest barrier to MedTech innovation is not always the technology

Most MedTech development programs do not start with a shortage of expertise.

They start with plenty of it.

Engineering understands the technology. Clinical teams understand the unmet need. Regulatory understands the pathway. Human factors understands the user. Manufacturing understands how it might be made. Commercial understands what the market might buy.

Yet bringing all of those perspectives together into one coherent development program is considerably harder.

That is where projects begin to slow down.

Requirements change. Decisions are revisited. Prototypes answer the wrong questions. Regulatory considerations emerge too late. Manufacturing constraints force redesign. User research challenges assumptions after significant engineering work has already been completed.

The problem is rarely a lack of activity. It is a lack of alignment.

For MedTech leaders, building a high-performing development team is therefore not simply about recruiting the best specialists. It is about creating a team capable of making good decisions together, early enough for those decisions to matter.

MedTech development is a system, not a relay race

Traditional product development can become sequential.

Clinical identifies the need. Marketing develops the proposition. Design creates the concept. Engineering makes it work. Regulatory assesses compliance. Human factors tests it. Manufacturing works out how to produce it.

The problem is that medical devices do not develop neatly in this way.

Every significant decision affects something else.

Changing the intended user can affect usability requirements. Changing the use environment can affect risk. Changing a material can affect manufacturing, biocompatibility, and cost. Changing the user interface can affect human factors validation. Changing a product claim can affect the evidence and regulatory pathway required.

The FDA explicitly recognises this interdependence. Its design control requirements call for development plans that define responsibilities and identify the interfaces between the different groups contributing to product development. (⁠U.S. Food and Drug Administration)

The implication for leadership is important.

Cross-functional development should not mean bringing specialists into the project when their particular stage arrives. It means involving the right expertise when decisions that affect their discipline are being made.

That can be much earlier than organisations expect.

The expensive decisions are often made early

Early-stage development can feel relatively inexpensive because teams are dealing with requirements, sketches, prototypes and concepts rather than tooling, verification or clinical studies.

But this is precisely when some of the most commercially important decisions are being made.

Who is the real user?

What problem are we solving?

Where will the device be used?

What are the critical user needs?

What evidence will eventually be required?

What are the significant technical and usability risks?

How will the device be manufactured?

What does it need to cost?

What would make someone choose it over the current standard of care?

Get these decisions broadly right and development becomes progressively more focused.

Get them wrong and the consequences compound.

The FDA’s design control framework reflects this logic, moving from clearly defined design inputs through outputs, verification, validation, design transfer and change control. (⁠U.S. Food and Drug Administration)

This should not be viewed simply as regulatory process. It is good product development discipline.

Stop confusing progress with activity

One of the most dangerous characteristics of a struggling development programme is that everyone can be extremely busy.

More meetings. More prototypes. More research. More documentation. More testing.

But activity is not the same as progress.

A better question for leadership is:

What uncertainty did we remove this week?

Successful development teams systematically reduce uncertainty.

Does the clinical need exist?

Can we solve it technically?

Can the user operate the device safely?

Can it be manufactured reliably?

Can we meet the target cost?

Can we demonstrate the required performance?

Can we navigate the regulatory pathway?

Will someone ultimately buy it?

Each prototype, experiment and design iteration should ideally answer one or more of these questions.

This changes prototyping from a process of making the product increasingly polished into a process of making the business increasingly certain.

Human factors cannot be the final usability check

One particularly costly mistake is treating human factors as something that happens once the product is largely designed.

By then, the fundamental architecture may be difficult and expensive to change.

Human factors should influence requirements and concepts from the beginning, particularly where user interaction could affect safety or clinical performance.

The FDA’s current guidance emphasises understanding intended users, use environments and user interfaces, with the objective of reducing use-related risk through design. (⁠U.S. Food and Drug Administration)

That means clinicians, patients and other intended users should not simply validate what the development team has created.

They should help shape it.

Give somebody responsibility for the whole product

Cross-functional teams can create another problem: shared responsibility becomes unclear responsibility.

Engineering owns engineering. Regulatory owns regulatory. Commercial owns commercial.

But who owns the product?

High-performing programmes need clear product leadership with enough authority to resolve competing priorities and maintain focus on the overall objective.

That does not mean one individual makes every decision.

It means someone remains accountable for ensuring that technical feasibility, user need, regulatory requirements, manufacturability and commercial viability converge around one product definition.

Without that ownership, difficult decisions tend to be deferred.

And deferred decisions have a habit of becoming expensive decisions.

Small teams can have an advantage

Large organisations have extraordinary capabilities, but those capabilities can exist in separate departments, locations, reporting structures and budgets.

For breakthrough development, that organisational scale can sometimes become friction.

A smaller, tightly integrated team can behave differently.

The best operate more like a skunk works: senior multidisciplinary specialists focused on a clearly defined problem, with short communication lines, rapid experimentation and enough autonomy to make decisions quickly.

This does not mean abandoning governance.

In MedTech, rigour is essential.

It means applying governance intelligently, while removing unnecessary organisational friction.

The objective is not simply to develop faster.

It is to learn faster, identify failure earlier and commit significant investment later, when there is stronger evidence that the product is worth pursuing.

External teams should add capability, not another layer of management

There is also a temptation to outsource individual tasks.

Industrial design goes to one supplier. Electronics to another. Human factors to another. Regulatory somewhere else.

Each may be excellent independently, while the client is left managing the interfaces between them.

A better external development model is integrated.

The value of a development partner should not simply be the number of designers or engineers available. It should be the ability to bring the right disciplines together around the problem and understand the consequences of decisions across the entire development pathway.

This is particularly valuable when internal teams are stretched, specialist capabilities are missing or a strategically important programme needs to progress faster than the organisation around it.

Build teams around outcomes, not functions

At Maddison, we believe successful MedTech development requires more than good design.

It requires industrial design, engineering, electronics, human factors, UX and UI, regulatory thinking, prototyping and commercial understanding to work as one development system.

Our role is often similar to an external skunk works.

A focused senior team can sit alongside the client’s internal experts, fill capability gaps and challenge assumptions without adding unnecessary organisational complexity.

The objective is simple:

Reduce uncertainty. Make better decisions earlier. Build the right product. Get it to market.

Because ultimately, MedTech companies are not rewarded for the number of development projects they start.

They create value from the products they successfully finish.