Be Bold. Kill Your Darlings.

Some of the shortest documents in a MedTech project are also the ones with the longest-lasting consequences.

I'm referring to the Intended Purpose, but not just those few sentences under that heading. I'm also talking about the intended population, intended user, intended use environment, contraindications, limitations and, of course, the product claims. Together, they define the product far more than many teams realise.

The Intended Purpose is often written as a description of the product, when in reality it should describe something much simpler: the intended medical use. Nothing more. Nothing less. If your Intended Purpose starts reading like a brochure, it's probably trying to do too much. I've seen Intended Purpose statements that try to explain the technology, describe every product feature, hint at future possibilities and subtly introduce claims that don't really belong there. It's easy to understand why. Years have often been spent developing the technology and there's a natural desire to communicate everything it is capable of. Resist that temptation. Also resist the temptation to copy-paste from any benchmark product. Sure, you can use them as example, but try not to fall into that trap where you just twist some wordings around.

Keep the Intended Purpose, intended population, intended user and intended use environment as separate elements. Don't try to squeeze everything into the Intended Purpose itself. It only makes the framework harder to understand and much more difficult to work with as it gradually evolves into a coherent narrative.

Taken together, these elements set the boundaries for what the device is, who it is for, where it should be used and, just as importantly, what it is not.

It's easy to underestimate how much follows from them. But know this: the entire regulatory journey, together with how the product is eventually perceived by regulators, clinicians, HTA bodies, investors and other stakeholders, is largely influenced by the decisions made here.

I have seen discussions ending up in focusing on the wording itself when the more interesting conversation is about the consequences of each alternative. A broader patient population may sound attractive until you realise what it means for the evidence you now need to generate. A different intended user can change far more than a sentence in the Instructions for Use. Even a seemingly minor adjustment to a claim can affect study design, endpoints and the overall evidence strategy, or even make previously collected evidence less relevant.

That's why I don't mind when these discussions take time. In fact, I think they should.

Try different alternatives. Challenge each other's assumptions. Test the consequences of every option before you decide. Once you've made the decision, commit to it. It's surprisingly difficult to generate convincing evidence for a moving target.

The same applies to claims.

I've found it useful to separate them into technical claims, performance claims and clinical claims. Not because the categories themselves are particularly important, but because they force a different discussion. Technical claims are usually supported through verification. Performance claims require validation and clinical performance data. Clinical claims raise an entirely different question: what role is the information actually intended to play in clinical care?

That distinction often makes another issue much easier to spot.

Some claims strengthen the product. Others simply make it more difficult to prove what you're trying to achieve.

Which brings me to the advice I probably give more often than any other during this stage of product development.

Be bold. Kill your darlings.

The first generation of a product doesn't need to do everything. It doesn't need to address every patient group, support every clinical decision or include every possible claim the technology might one day justify. Quite the opposite. I'd much rather see one clear clinical claim supported by convincing evidence than several ambitious claims where the evidence becomes diluted, difficult to interpret or simply insufficient.

Patience is an underrated quality in product development. Not every idea needs to become part of the first-generation product, and not every aspirational claim has to be pursued from day one. There is often far more value in bringing a focused product to market, learning from clinical use, building stronger evidence and then expanding with confidence in the next generation.

While we're defining the boundaries of the product, there's another distinction that's worth getting right: Contraindications and limitations are often treated almost as administrative details, but they're worth discussing carefully as well because they answer two very different questions. Contraindications define when the device should not be used. Limitations describe where performance has not yet been established. The distinction may seem subtle, but it's an important part of setting realistic expectations for both regulators and users. One is about avoiding use. The other is about being honest regarding the boundaries of the available data.

This is usually the point where I open a blank page and start drawing arrows. Can I follow a clear line from the Intended Purpose, through the performance claims, to the clinical claim, the expected clinical benefit and finally to the clinical relevance?

Does every step naturally lead to the next? Or does something suddenly feel like a leap rather than the next logical step?

Technical claims sit slightly outside this chain. They establish that the technology performs as intended, but they don't, on their own, explain why the product matters in clinical practice.

If the Intended Purpose says one thing, the claims suggest something slightly different, the expected clinical benefit drifts in another direction or perhaps you've realised that the expected clinical relevance depends on assumptions that haven't yet been tested against the actual user need or clinical context, neither regulators, clinicians nor investors are likely to find the story particularly convincing.

When that happens, my advice is usually the same: don't try to defend the weak link. Acknowledge that it's there, challenge it and, if necessary, go back and start again. It can feel frustrating in the moment, but it's almost always less painful than trying to defend a narrative that never really held together in the first place.

A narrative. One that should tell exactly the same story from beginning to end.

One Final Thought

The point isn't to get the wording perfect. The point is to see whether the story still makes sense. Because once you start generating evidence, you're no longer just testing a product.

You're testing the narrative you've built around it.