Surgeons love coloured buttons

“Surgeons love buttons. Coloured buttons, preferably.”

This was one of the design considerations offered by a physician-founder during a meeting with the development team several years ago.

He was not being entirely serious. Nor was he entirely joking.

I remember sitting with the development team, looking at early ideas for the device and discussing what it should actually do. There were sketches, features, observations and a fair amount of possibility still on the table. Some of it would eventually become part of the device. Some of it would not.

This is one of the most enjoyable stages of medical device development. The problem is still recognisable from real life, while the solution has not yet been translated into design inputs, requirements, claims, classifications, evidence plans and milestones. People are allowed to think aloud. A feature can be suggested because surgeons like coloured buttons, and everyone in the room understands that there may be a real observation hiding somewhere inside the joke.

Then development begins in earnest.

That story belongs to one of us, but the pattern behind it is something we have both seen repeatedly from different sides of product development.

A device changes language as it develops

As development moves forward, the original observation is translated into user needs, design decisions and eventually an intended purpose. Assumptions are committed, features are added and the scope quietly expands. Unlike the code, however, the original reasoning rarely comes with a reliable version history. By the time the regulatory pathway and evidence questions are being defined, different parts of the company may be working from different branches without quite realising it.

That is a fairly expensive merge conflict to discover late.

However, this does not usually happen because someone makes an obviously bad decision. More often, each stakeholder makes a perfectly reasonable decision from within a particular discipline, under a particular set of pressures and on a particular clock.

R&D may be working towards the next prototype. An investor may be looking for a value-creating milestone before the next funding round. Regulatory Affairs may be trying to identify a viable route to market. Clinical Affairs may see questions and lead times that cannot be compressed simply because the answer is now urgently needed. And regardless of who owns the question, the design will eventually need to stabilise enough for the product to be manufactured reproducibly.

Medical device and IVD development are not without a formal structure for this journey. The international standard ISO 13485:2016, particularly clause 7.3, provides a framework for controlled design and development: planning, design inputs and outputs, review, verification, validation, transfer and change control. The MDR and IVDR add the regulatory expectations around the quality management system, risk management, technical documentation and the evidence needed to support the product and its intended purpose.

Those frameworks are not separate from product development. They are the structure through which an idea becomes a product that can be manufactured reproducibly, supported by evidence and placed on the market with claims that can be defended.

On paper, the steps can look sequential. In practice, one product decision can travel through several of them at once. And as that decision moves between functions, the language often travels with it without the meaning staying quite the same.

The words may sound familiar across the room: ready, validated, feasible, proven, successful. They do not necessarily mean the same thing.

Take the often-used word “validated” as an example. In everyday development language, it may be used loosely to mean that something has been tested and shown to work. In the formal design and development framework, however, verification and validation answer different questions: verification asks whether design outputs meet the design inputs, while validation asks whether the resulting product meets the requirements for its intended use.

And beyond that sits the evidence question: does the available evidence actually support the intended purpose and the claims the company intends to make?

The same word may be used around the table, while the questions being answered are quite different.

Visible progress is not the whole story

In a small MedTech company, progress tends to be measured by what can be shown. A prototype on the table, a technical problem solved, something new the product can do. It is tangible, reassuring and conveniently easy to recognise as progress.

Other work is less photogenic.

It is common to see a young company build a substantial R&D team while Quality and Regulatory Affairs is covered by a limited consultancy arrangement and Clinical Affairs has barely entered the conversation. The reasoning is understandable. There is not enough money to do everything, the design is still evolving, and much of the work appears premature while the regulatory pathway remains uncertain.

But involving a discipline early is not the same as starting every activity early. Clinical does not need to launch a study the moment it enters the room, nor does every regulatory workstream need to begin at once. Early input may simply help the company understand what needs attention now, what can sensibly wait, and what must be in place before the next activity begins.

The problem is not waiting. It is waiting without understanding the consequences.

A delayed activity may later require information that is no longer available, a design choice that has already hardened or a study idea that cannot be fitted into the promised timeline. What looked like sensible sequencing can become an expensive dependency. The cost is not created when the late question is finally asked. It began accumulating while nobody considered the question urgent.

In a larger organisation, the problem is often not the absence of expertise but the absence of ownership across boundaries. Regulatory, Clinical, Quality, R&D and Commercial expertise may all be present, but distributed across separate functions with clearly defined responsibilities. That clarity is useful until a decision falls between them.

Each team may reasonably focus on its own remit. The risk is that no one is explicitly responsible for connecting the pieces. Regulatory may see only part of the commercial ambition. Clinical may be working from an earlier version of the intended purpose and claims. R&D may be progressing against requirements that were agreed before the claims evolved.

Depending on how decisions are made and communicated, some perspectives may enter the discussion earlier than others. Commercial and Marketing may be close to early strategic decisions, while Regulatory is consulted once the question has already been framed. By then, some of the assumptions behind that question may already feel settled.

The issue is not that one function should overrule the others. Leadership needs to keep sight of the whole chain: product, intended purpose, claims, evidence, risk, route to market and commercial goals, while decisions move across organisational boundaries. That requires enough insight into each discipline’s constraints, dependencies and lead times to set priorities with an understanding of the consequences.

A development decision does not stop at the edge of an organisational chart. Neither do its consequences.

One decision, several downstream consequences

The point is that a product decision does not need to be dramatic to have consequences beyond the development team. Consider a feature that performs well during development. Users like it, the team sees its potential and, quite naturally, the language around it becomes stronger. What began as an observation starts to become something the company would like to say about the product. At that point, the decision is no longer only about the feature itself. It has also become an evidence question: what exactly needs to be demonstrated to support that statement?

The clinical work may already be planned, but the outcomes being measured may not demonstrate the claim the company now wants to make. The evidence can be scientifically sound and still support a slightly different story.

The same applies to seemingly small product changes. A colour or material changes. A coating or component is replaced. From an engineering perspective, the change may appear minor, but depending on the product, materials and nature of patient or user contact, it may have implications for biocompatibility, risk management, verification or validation activities, technical documentation or the evidence supporting the finished product.

The useful question is not whether everyone has been included. It is whether the people making a decision understand what it changes for those who are not in the room.

Before a decision settles into the development plan, someone needs to ask what assumption is being made, which downstream activity depends on it and what becomes harder if the relevant expertise is brought in later. If the device, population or promise has shifted, that shift needs to be visible across the organisation rather than discovered separately by each function.

Back to the coloured buttons

Which brings us, briefly, back to the coloured buttons. Whether they eventually became part of the device is not really the point. What the anecdote captures is a stage when the observation, the idea and the reasoning behind it were still present in the same conversation.

As development progresses, that conversation becomes distributed across functions, plans and documents. The business strategy should carry clear traces of the regulatory and clinical development strategies, just as regulatory and clinical decisions should reflect where the company intends to go commercially. The different perspectives do not need to use identical language, but they do need to describe the same device, the same use case and a credible route between the two.

A coherent development story is not a narrative created afterwards to make the decisions look connected. The connection should already be visible in the decisions themselves.

Otherwise, the company does not have one story. It has several perfectly well-written ones.