Welcome, friends, this is issue No. 036 of Clinical Product Thinking. This week we’re diving into practical takeaways when considering AI’s impact on healthcare.

This week I tuned into a talk by Dr Keith Grimes for BMJ Future Health, talking about the future of AI in healthcare.

The discussion ranged from prompting and ambient scribes to clinical safety officers, AI agents, regulation and the rise of clinicians as builders.

For anyone thinking about how to approach this space, the message was clear: you do not need to become an AI expert overnight. What matters is becoming the kind of healthcare professional, product leader, or policymaker who can use these tools with curiosity, scepticism and responsibility.

Start with low-risk use cases. Learn actively. Ask better governance questions. And remember to consider who is accountable.

Here are my top 10 takeaways with actions you can take today:

1. Prompting matters less than context

The way we ask AI questions still matters, but the bigger determinant of useful output is increasingly the quality of the context we provide. In healthcare, that context might include the workflow, the patient group, the local policy, the intended use, the constraints of the service, and the specific decision or task we are trying to support.

Action point: Try prompting through voice rather than typing, because when we speak, we tend to give more natural background, more nuance and more useful context than when we type a short instruction into a chat box. I use Wispr Flow Pro and would never go back.

2. Digital governance cannot be someone else’s problem

Healthcare has mature ways of thinking about the governance of clinicians, drugs and devices, but digital tools have often been treated as though someone else must already have checked them properly. As AI tools move closer to clinical work, that assumption becomes increasingly unsafe.

Action point: Ask one simple governance question about any AI or digital tool you are using or considering: who is responsible for knowing whether this is safe in our setting? If the answer is vague, that is probably where the next conversation needs to start.

3. Clinical safety standards are becoming everyday knowledge

Clinical safety standards such as DCB0129 and DCB0160 have existed for years in England, but AI has made them much more visible, especially as ambient scribes and other tools begin to affect consultations, documentation and clinical workflows.

Action point: Consider getting clinical safety training, or at least learning the basics of clinical risk management for digital tools, because this is likely to become a core capability for clinicians, product teams and healthcare leaders working with AI.

4. Clinicians do not need to become AI engineers, but they do need to know enough

The expectation should not be that every clinician becomes a technical expert, but clinicians do need to understand the tools they use well enough to practise safely. That means knowing what the tool is for, what it is not for, how it can fail, what needs checking and what to do when something goes wrong.

Action point: Pick one AI tool you already use, or one your organisation is considering, and write down five things: what it does, what it does not do, how it might go wrong, what the user must check and how concerns should be reported.

5. Ambient scribes show both the promise and the risk

Ambient scribes may reduce documentation burden and improve the flow of consultations, but they also create new responsibilities around consent, accuracy, review and record quality. Their outputs can sound fluent while still being incomplete, distorted or wrong.

Action point: Before using an ambient scribe, practise explaining it to a patient in plain English, including what it does, why you are using it, what happens to the information, and how the final clinical note will be checked.

6. Clinicians are now builders and that is both good and risky

AI has made it easier for clinicians and healthcare teams to prototype tools, calculators, chatbots and workflow aids without needing advanced coding skills. That is exciting, because frontline staff often understand the problems best, but a prototype is not the same as a safe clinical product.

Action point: When experimenting with AI-built tools, keep a clear boundary between experimenting, prototyping and deploying, and do not use real patient data or real clinical decisions until governance, safety, data protection and accountability have been properly considered.

7. Agents are coming, fast

AI agents are different from simple chatbots because they can pursue goals, use tools, plan steps, retrieve information and adjust their approach. They are likely to have a major impact on administrative, operational and back-office work before they are, quite rightly, trusted with higher-risk clinical tasks.

Action point: Look for one repetitive administrative task in your work that involves gathering information, drafting, checking or organising, and consider whether an agentic workflow could support part of it under human supervision.

8. AI should be compared with real care, not imaginary perfect care

AI tools are often judged against an idealised version of healthcare rather than the care patients actually receive. That matters because current processes are often delayed, inconsistent, poorly measured or unavailable, especially in pressured parts of the system.

Action point: Before dismissing an AI tool because it is imperfect, ask how the current process performs, how often it fails, whether that failure is measured, and what harm or burden patients already experience without the tool.

9. AI will amplify the system it enters

AI does not fix broken workflows by magic. If a service has clear processes, good measurement and strong accountability, AI may help it become faster or more consistent, but if the existing process is confused or unsafe, AI may simply scale that confusion.

Action point: Do a quick workflow review before introducing AI: map the current process, identify where patients or staff struggle, decide what outcome should improve, and only then ask whether AI is the right intervention.

10. Start learning somewhere low-risk

The safest way to build fluency with AI is not to begin in clinical care, but somewhere personally familiar and low-risk. Hobbies are useful because you usually know enough about the subject to spot when the model is helpful, vague or confidently wrong.

Action point: Start using AI for one of your own hobbies this week, whether that is cooking, running, writing, music or travel planning, and use that experience to learn how context, checking and judgement change the quality of the output.

The rate of change of AI is astounding and will only continue to speed up. If you’re feeling a bit left behind, you’re not the only one! But remember you do not need to know everything, and you definitely do not need to chase every new tool. But it is worth getting curious, trying things in low-risk ways, and building the habit of asking good questions about safety, workflow, governance and accountability. That is probably where the real value starts. Happy AI-ing all.

Join the next clinical product panel 🎤

On 12th May, Danielle Brightman and I are hosting a panel covering some of the most pressing questions in clinical product management. Tickets have been going fast. 👉 Sign up here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 035 of Clinical Product Thinking. This week we’re diving deep into Claude Code and the clinicians-as-builders movement.

The next generation of clinicians will practise medicine through the products they build, not just the patients they see… Dr Keith Grimes via Bitelabs

Until now most healthcare innovation has happened at a distance from the people experiencing the pain points. That space is starting to collapse.

On Thursday, I joined the Claude Code for Healthcare talk by Anthropic, where clinicians were building tools live on stage. Each product built by someone who has felt the problem and now had the ability to act on it.

This shift is worth paying attention to.

The rate-limiting step is moving

The bottleneck in building products has typically been engineering capacity. Claude Code and tools like it are quietly moving it somewhere much more interesting.

As one of the speakers put it: “The rate limiting step is no longer learning HTML or JavaScript. It’s: do you understand the problem well enough?”

The implication of this is big. Clinical insight, the thing CPMs and practising clinicians have always brought, has just become way more valuable, not less.

Signal: Problem selection is now the scarce skill. Prototyping is becoming commodity. Production still isn't.

Pocket knives over platforms

One of my favourite framings from the talk was the “pocket knife” analogy. Plenty of clinical problems can be solved by a small, focused tool that does one thing brilliantly, without reaching for a Swiss Army platform every time.

A few examples from the demos:

1. A newborn note generator that could be adapted for Saudi newborn screening, a Californian paediatric practice, or a UK neonatal unit with small tweaks. This was built live during the call!

2. An air quality dashboard, one built for patients, clinicians and public health authorities. The fun twist: make it Gen Z and add main character energy.

3. Pre-visit tools that gathered patient history in plain language and translated it into a clinically structured summary, and post-visit tools that walked patients through their diagnosis, medications and follow-up in language they could actually use.

Same underlying pattern each time: small tools, doing focused work, built by the people who feel the pain directly.

Where I get cautious

I want to hold two things at once here. First, this is a genuine shift. Clinicians have never had this much creative latitude over their own tooling.

Second, a prototype is still a long way from a product. Some risks to put on your radar:

1. Shadow IT creeping into clinical settings. A clinician who emails around an HTML file containing patient data has just created a governance incident, however elegant the tool. Privacy, security and audit trails do not disappear because the build was easy.

2. Local optima masquerading as solutions. A tool that is perfect for one clinician’s workflow can be almost impossible to generalise, maintain or safely scale. Brilliant in one pair of hands. Risky across a department.

3. Problem expertise being mistaken for product expertise. Feeling the pain is necessary but not sufficient. Good product still requires prioritisation, usability research, workflow integration, behavioural insight and commercial thinking.

4. Compliance being underplayed. As far as compliance goes the talk seemed to conclude: “Ask Claude, then ask a lawyer” which is a very incomplete regulatory strategy. DCB0129/0160, UK MDR, EU AI Act classification, DPIAs, supplier due diligence, data processing agreements: none of these become optional because the build was faster.

Signal: Build has democratised. Governance has not.

The distribution problem nobody solved

The demos were compelling. The deployment story was thinner.

Even if a clinician prototypes a tool in an afternoon, getting it safely used across a department, a practice or a trust remains genuinely hard. APIs help. FHIR helps. TEFCA in the US and the interoperability work happening here in the UK help. But the real blockers tend to be structural: procurement cycles, vendor lock-in, information governance committees, local IT politics, and the question of who carries the responsibility when the tool does something unexpected in production.

Distribution remains an unsolved layer.

Practical takeaways

If you work in or around clinical product and you haven’t tried Claude Code yet, I highly recommend giving it a go. You can use it via the terminal (scarier but more powerful) or via the browser or desktop app (friendlier starting point).

The hardest part is just getting started. If you don’t know where to begin, steal this:

I’m a clinical product manager building a [one-line product description, e.g. “post-natal symptom tracker for women in the first six weeks after birth”]. I want to draft a PRD.

Before we start, help me write a clear intended use statement in one sentence, covering who uses it, in what setting, for what clinical purpose, and what it explicitly does not do. Ask me any clarifying questions you need to get this right.

Once we have the intended use, draft a PRD that includes:

• Problem statement and user personas (both clinician and patient)

• Intended use and out-of-scope uses

• Clinical risk considerations and likely hazards

• MHRA medical device classification assessment with reasoning

• Evidence plan (what we’ll need to demonstrate the tool works)

• Success metrics framed as clinical outcomes, not engagement

• Open questions and assumptions that need validating with users

Where you’re uncertain, flag it clearly rather than guessing. Where clinical or regulatory nuance matters, err on the side of caution and tell me what you’d want a CSO to verify.

If you start building your own tools, let me know how you get on (just hit reply) and please, no patient data!

The clinician builder moment is arriving. Clinical product is how it gets to real patients safely.

Join the next clinical product panel 🎤

In May, June and July Danielle Brightman and I are hosting 3 panel events spanning the most pressing questions in clinical product management. Tickets have been going fast. 👉 Sign up here.

Join us at HLTH Europe 🇪🇺

Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.

👉 Register your interest for the panel here.

🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Join the next clinical product coffee & chat ☕️

Trialling a new format over the next 3 months, a monthly small group chat where we discuss what’s coming up for you in clinical product and your most pressing questions.

Read more

Welcome, friends, this is issue No. 034 of Clinical Product Thinking. This week I’m incredibly excited to let you know about a new 3-part webinar series.

A few months ago, Danielle Brightman and I hosted a panel in London on how to break into clinical product. We expected a good turnout. What we didn’t expect was how many people reached out afterwards asking if there would be a recording, an online version, or another chance to join the conversation.

In response we’re launching a 3-part webinar series: three online sessions exploring some of the biggest questions in clinical product.

We’ll be focusing on:

• How to build clinical products safely and at scale

• How to create meaningful clinical AI products

• Why clinical product is emerging as a new kind of product leader in healthtech

We’d love to see you there.

1. Building HealthTech: From Product Thinking to Patient Safety

Most product teams are taught to move fast, test assumptions and iterate.

Healthcare adds a harder question:

How do you move fast without compromising patient safety?

In this session, we’ll explore how to build healthtech products where safety is not something you check at the end, but something designed into the product from the beginning.

We’ll talk about:

• how clinical judgement changes product decisions

• where teams most commonly create risk without realising it

• how to think about safety, evidence and experience together

• why the best healthtech products are designed around the realities of care delivery, not just software

This is the conversation more product teams should have earlier.

Tuesday 12th May, 7pm BST. 👉 Sign up here

2. Building AI Clinical Products: How to Build Safe, Effective Clinical AI

Everyone in healthtech is talking about AI.

Very few people are diving deep into what it actually takes to build clinical AI safely.

Healthcare is full of products that seem impressive in a demo but become much more complicated when they meet real patients, clinical workflows and real-world risk.

In this session, we’ll explore:

• the difference between AI that is useful and AI that is genuinely safe

• the new risks created by clinical AI products

• how regulation, evidence and product design need to work together

• why many of the old approaches to product management are not enough for AI-enabled healthcare

If you are building AI in healthcare, leading a clinical AI product, or trying to understand what “good” looks like, this session is for you.

Tuesday 2nd June, 7pm BST. 👉 Sign up here

3. The Clinical Product Gap: Why HealthTech Needs a New Kind of Product Leader

Most companies have clinicians and a product function. What most don’t realise is the gap that is forming between the two functions as both speak different languages and prioritise different things.

In this session, we’ll explore why traditional product thinking often breaks down in healthcare, why clinical expertise alone is not enough, and why a new kind of leader is emerging in between.

We’ll cover:

• what clinical product actually is

• why so many teams struggle to integrate product, clinical and operational thinking

• the common failure modes when this role is missing

• how the best companies are starting to structure it differently

If you’ve ever found yourself acting as the bridge between clinicians, product, safety and operations, this session is probably for you.

Tuesday 14th July, 7pm BST. 👉 Sign up here

If you’re passionate about building healthcare products that are not only beautifully designed, but also safe, effective and genuinely useful, I’d love you to join us.

See all upcoming events and register here: clinicalproductthinking.com/events

Join Us at HLTH Europe 🇪🇺

Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.

👉 Register your interest for the panel here.

🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Join the Next Clinical Product Coffee & Chat ☕️

Trialling a new format over the next 3 months, a monthly small group chat where we discuss what’s coming up for you in clinical product and your most pressing questions.

Read more

Welcome, friends, this is issue No. 033 of Clinical Product Thinking. This week is something a little different.

Over the past few months, Clinical Product Thinking has grown a lot faster than expected. So many new faces, reading and sharing every week.

As it grows, it feels more and more like we are collectively defining what clinical product is, what great looks like, how people break into the profession and how to build safer, better healthcare.

So as such I would love your help. I’ve put together a very short survey to better understand what the community is looking for.

As a thank you, everyone who completes it can choose one of three practical resources:

• ✅ How to Break into Clinical Product Panel Event - Recording (previously only available to paid subscribers)

• ✅ Commercial Cheatsheet for CPMs - The top 50 commercial terms that every clinical product manager needs to know

• ✅ Clinical Product & Chat event - a free 45-minute group call to discuss your clinical product questions and challenges

In addition to the above you will also receive my eternal gratitude! 🙏

What the Community Are Reading

If you’re new here (and many of you are), welcome.

Over the past few months, a few themes have come up again and again in Clinical Product Thinking. These are the posts that readers have shared most, replied to most and told me helped them make sense of their own role.

If you’re building, hiring into or trying to break into clinical product, these are probably the best place to start.

1. How to Break into Clinical Product

By far the most popular theme has been how to break into clinical product.

Posts like:

• How to Land Your First Clinical Product Role with Danielle Brightman of Numan

• Want to Be a Clinical Product Manager? Here’s Exactly What Employers Are Looking For

…were very well received.

And I think they resonated because many people are asking themselves the same question:

“Am I actually qualified to do this?”

The answer is probably more than you think.

The message from Danielle Brightman, who leads one of the largest clinical product teams in the UK, was that employers are not primarily hiring for credentials.

They are hiring for a way of thinking.

The traits that came up again and again were:

• Curiosity

• Systems thinking

• The ability to spot risk

• Thinking in journeys and workflows, not isolated features

• Being able to translate between clinical and product language

As Dani put it:

“Experience matters, but mindset wins.”

2. Clinical Product Is Becoming a Real Profession

Another thing readers seem to be finding most useful is clarity that what clinical product is and is not: clearer expectations, career ladders and responsibilities.

One of the most-read posts was analysis of all recent clinical product job descriptions.

The biggest themes:

• Clinical backgrounds are increasingly expected

• Governance and safety are now core parts of the role

• Employers want people who think in systems and outcomes, not features

• CPMs are increasingly expected to bridge product, operations, regulation and clinical care

Healthcare products are not judged only by typical product metrics like clicks, activation or retention.

Increasingly, they are judged by:

• Clinical outcomes

• Pathway performance

• Safety

• Whether they work in the real world

Job descriptions are calling for people who can deliver the above.

3. Who Owns What

Another of the most popular posts tackled a question every scaling healthtech team eventually faces:

Who is actually owning what?

Most people understand the role of a Product Manager. Fewer understand what a Clinical Director owns. And almost no one seems entirely clear where the Clinical Product Manager fits.

The simple framework that resonated most was:

• PM owns what to build

• CPM owns how to build it safely

• Clinical Director owns clinical integrity and sign-off

The reason this matters is that role confusion does not just create frustration.

It creates risk.

Early on, “everyone does everything” can feel fast and scrappy.
Later, it becomes chaos disguised as collaboration.

One idea that seemed to strike a chord: phantom accountability.

Often CPMs are being held responsible for governance, safety or clinical decisions without the authority or support to do so properly. That is a governance problem.

4. Y’all Love Regulation

Some of the other best-performing posts have been about regulation, SaMD and AI.

I think it is because many people know these things matter, but do not know where to start.

The most-read post on SaMD boiled the whole thing down to four questions:

1. What is the intended use?

2. What class of device is it?

3. Who regulates it?

4. Which standards apply?

The key message:

Safety, governance and evidence are not separate from product.

They are the product.

Most Importantly: Thank You

Thank you again for being part of Clinical Product Thinking.

I’m excited to help build the future of clinical product together.

Louise

Join Us at HLTH Europe 🇪🇺

Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.

👉 Register your interest for the panel here.

🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)

That’s the public post for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Join the Next Clinical Product Coffee & Chat ☕️

Trialling a new format over the next 3 months, a monthly small group chat where we discuss hot topics and your most pressing questions.

Read more

Welcome, friends, this is issue No. 032 of Clinical Product Thinking. This week, we’re diving into ways biases are created and propagated in clinical AI systems.

When we talk about bias in clinical AI, people are usually referring to the model. Specifically, biased training data, poor representation of the dataset to the intended population and algorithms that perform worse for some groups than others.

This is a huge problem. But it is only part of the picture.

Bias in clinical AI exists across multiple layers:

• Model and data bias

• Cognitive bias

• System and workflow effects

A recent review in PLOS Digital Health argues that bias in clinical AI should be thought of as cumulative rather than isolated. Bias can enter at every stage and each compounds the one before it.

By the time an AI system reaches the clinician, the final output may reflect multiple layers of distortion rather than a single flaw in the model.

A clinical AI model can be statistically fair, rigorously validated and still cause harm. Why?

Because bias in clinical AI does not live in one place. It accumulates.

First in the data. Then in the clinician’s mind. Then in the workflow around it.

Layer 1: Model and Data Bias

This is typically top of mind for most people. Clinical AI models inherit the biases embedded in the data they are trained on.

That includes:

• Historical bias: when past inequalities in healthcare become encoded in the model

• Representational bias: when some groups are under-represented in the training data

Clinical AI datasets are still remarkably unrepresentative. Studies show more than half of published clinical AI models are trained on data from either the US or China, and many overrepresent White patients relative to the populations they are ultimately used on. A model may therefore appear accurate while performing far worse for minority groups, different health systems or lower-resource settings.

• Measurement bias: when the labels or proxies used do not accurately reflect reality

Labels themselves are often treated as “ground truth”, but they frequently reflect human judgment rather than objective reality. Diagnoses, triage decisions and even treatment recommendations can encode the cognitive biases and unequal care patterns of clinicians. If a model is trained on those labels, it may not just reproduce the bias, but scale it.

• Aggregation bias: when one model is applied across groups that differ clinically

• Deployment bias: when a model is used outside the setting it was validated for

The Epic Sepsis Model is one example. A model was deployed as part of the Epic EHR to flag early signs of sepsis. However, when researchers independently evaluated it, performance varied significantly between hospitals and was poorest in patients with multimorbidity and cancer. Epic subsequently began recommending that hospitals train the model on their own patient data before clinical deployment.

These biases are well documented. But even if the model is technically fair and accurate, the story does not end there. The moment a human encounters an AI recommendation, a new layer of bias begins.

Layer 2: Cognitive Bias

Once a clinician sees an AI recommendation, the model begins to shape human thinking.

The most obvious is automation bias, the tendency for humans to over-rely on automated systems, trusting AI suggestions over their own judgment, even when the system is incorrect or contradicts available evidence.

A randomised controlled trial showed that when physicians were shown an incorrect LLM output, diagnostic accuracy significantly degraded compared to error-free advice. This occurred despite prior AI-competency training. Diagnostic accuracy dropped from 85% to 73%.

But that is only one of several cognitive traps.

Clinicians may also experience:

• Authority bias: the AI feels authoritative, so concerns are ignored

• Confirmation bias: we trust outputs that agree with what we already think

• Base-rate neglect: we over-weight the AI’s prediction and under-weight how common the disease actually is

Many companies design systems with human-in-the-loop as a key risk mitigation without realising they have also designed a system that can systematically distort the human judgment they are relying on.

The imperative is therefore not just to improve model accuracy but to design interfaces that reduce cognitive bias.

That means asking:

• Should the AI output appear before or after the clinician makes an initial assessment?

• How should uncertainty be displayed?

• Should the system show alternative possibilities?

• When should the AI force the user to slow down or escalate?

Layer 3: System and Workflow Effects

And then there is the next layer: the wider system around the model which itself can push people towards poor decisions.

That includes:

• Alert fatigue: clinicians begin to ignore warnings because there are too many of them

Alert fatigue is one of the most well-documented workflow failures in clinical AI. Studies have shown clinicians override between half and 96% of clinical alerts. In primary care, clinicians receive more than 50 alerts a day. At that point, the problem is no longer whether the model is technically correct. The problem is that no human can realistically respond to that volume of interruption.

• Deskilling: clinicians may become progressively less able to make decisions independently because they have become used to relying on AI

Over time, repeated reliance on AI can erode clinical judgement and reduce clinicians’ ability to work without it. One study found that after clinicians began using AI-assisted polyp detection, their unassisted detection rates declined.

• Timing effects: the same AI output can lead to different decisions depending on when it appears in the workflow

An AI recommendation shown before a clinician has formed an initial judgement may anchor their thinking and make them less likely to challenge it. The same recommendation shown later, after an independent assessment, may be interpreted much more critically.

Studies suggest that the timing of AI input relative to the clinical encounter affects performance independently of the model itself.

• Workflow friction: clinicians are less likely to act on AI recommendations when doing so creates interruption, complexity or when they have poor workflow integration

Studies have shown a model may be technically accurate, but still fail if it creates extra clicks, interrupts at the wrong moment, requires the clinician to leave their usual workflow or adds more work than it saves. Over time, people begin to ignore or bypass the system altogether.

This is why so many clinical AI pilots can look impressive in a demo and not perform well in practice.

Why This Matters

The critical point is that these layers are cumulative. Model and data bias are the foundation, cognitive bias amplifies, and then workflow design either mitigates or magnifies the problems.

By the end, harm may have very little to do with the original model:

• Imagine a model that slightly under-predicts sepsis risk in one population. (Model bias)

• Next, imagine clinicians begin over-trusting the score and stop questioning it. (Cognitive bias)

• Now, imagine the system surfaces those alerts constantly until clinicians either stop escalating or escalate everyone. (Workflow effect)

The result is a much larger failure than the original model error alone.

The Future of Clinical AI Will Be Won in the Workflow

This is why I increasingly think that the future of clinical AI is not about building smarter models. It is about building smarter systems around them.

The teams that succeed will not only ask:

• Is the model accurate?

They will ask:

• How could this output distort human judgment?

• What biases might this interface create?

• What happens when the AI is wrong?

• How do we design the workflow to catch that?

And that is why clinical product management matters. Because the hardest problems emerge in the messy space that CPMs operate in, between the product, the clinician and the workflow.

Learn More 👩‍🏫

Looking to learn more about building safe clinical AI systems? Here are a few resources I recommend:

• Read the Arise report on the State of Clinical AI 2026

• Join this webinar on how clinicians are building with Claude Code (I’ll be there!)

• Keep an eye out for the next Openclaw Clinical Hackathon

• Join the Clinical AI Interest Group by Alan Turing Institute

• Take this course on fairness in human-AI interactions in healthtech

Hiring Spotlight 🚀

Heidi are hiring a clinical associate to join the customer success team. While not a pure play clinical product role this would be a great way to gain startup experience before pivoting into a more pure play CPM role. 👉Apply here.

HealthHero are hiring for 2 x clinical product specialists to join their team. HealthHero is one of Europe’s largest digital health provider and they’re working on some incredibly innovative products. 👉Apply here.

Join Us at HLTH Europe 🇪🇺

Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.

👉 Register your interest for the panel here.

🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 031 of Clinical Product Thinking. This week we’re diving into business models in healthtech and how to reject false trade-offs.

Healthtech founders love to talk about purpose. Investors love to talk about profit. And somewhere in the middle, most companies get stuck.

To dig into this, I sat down with Kevin McDonnell, an operator who’s scaled clinical services to millions in revenue and advised boards wrestling with this exact tension.

Here’s what he said.

The False Trade-Off

Kevin puts it bluntly:

“Too many founders treat purpose and profit as separate lanes. Some obsess over outcomes and impact but ignore the need for a sustainable engine. Others chase revenue so hard they erode clinical trust. Both approaches fail.”

The best businesses reject the trade-off. They build models where clinical outcomes and commercial success reinforce each other.

👉 Practical steps for CPMs/founders:

• Map your current initiatives: which are primarily “purpose-driven” vs “profit-driven.” Where are they reinforcing each other (green zone) vs in conflict (red zone)?

• Pressure-test your product: can you clearly articulate how better outcomes = better business performance?

• Run a “dual lens” review of new ideas: what’s the clinical case and what’s the commercial case? If you can’t articulate both in one sentence, pause.

When Compromise Kills Trust

I asked Kevin about the hardest trade-offs he faced when running a clinical services business.

His answer: speed and scale.

• Do you hire more clinicians to maintain service levels, or stretch the team and risk patient dissatisfaction?

• Do you take low-margin contracts to keep the doors open, knowing you can’t invest properly in quality?

Kevin’s lesson:

“Some compromises kill trust. And trust once lost is almost impossible to regain.”

👉 Practical steps:

• Create a “red lines” list of compromises you will not make (e.g. minimum staffing ratios, clinical governance guardrails).

• Build a “trust recovery” playbook: how will you handle it if something goes wrong? Communicate openly, fix fast and log lessons learned.

• Stress test your processes: if you had to double volumes tomorrow, would safety break?

Designing Models Where Safety Saves

Clinical excellence on its own won’t pay the bills. Kevin argued you need a business model where safer care directly reduces cost.

• Fewer readmissions → saved bed days

• Fewer unnecessary scans → saved spend

• Longer time at home → freed up system capacity

And then? Quantify it. With real-world evidence, not just trial data.

Kevin pointed to Cera, which uses AI to predict risk in home care. They claim £100m+ in NHS savings while scaling to millions of visits. That’s what it looks like when clinical and commercial reinforce each other.

👉 Practical steps:

• Identify 2–3 safety metrics that naturally translate into cost savings (e.g. readmissions, ED attendances avoided).

• Build those into your KPI dashboard alongside financial metrics.

• Partner with your finance or ops team to quantify savings in real money terms (£/bed days).

• Turn your “safety saves” stories into case studies, both for clinicians and investors.

Metrics That Actually Matter

Vanity metrics are tempting: downloads, pipeline size, number of pilots. Kevin calls them “hollow.”

What matters instead:

• Adoption: Are clinicians actually using it?

• Utilisation: Are patients sticking with it?

• Impact: Are you shortening stays, reducing costs, preventing escalation?

And don’t forget the commercial backbone, metrics like:

• Net revenue retention

• Margin per contract

Pilots that don’t convert? Contracts that never scale? That’s not a business.

👉 Practical steps:

• Replace vanity metrics in your OKRs with metrics such as adoption, utilisation, impact and NRR.

• Run a quarterly “metric audit”: are we tracking things that actually drive decisions, or just what’s easy to measure?

• For pilots: set explicit conversion criteria before you start (e.g. “will only proceed if X% adoption within 3 months”).

One Metric to Rule Them All

The hardest part of alignment, Kevin said, is language.

• Clinicians talk safety.

• Product talks features.

• Investors talk revenue.

They’re all chasing outcomes, but with different vocabularies.

Kevin’s fix: one shared metric that everyone can rally behind.

“Take reduced bed days. Clinicians see safer care. Product sees adoption. Investors see cost savings that convert into revenue. Alignment happens when you stop letting each group keep their own scoreboard.”

👉 Practical steps:

• Facilitate a cross-functional session (clinical, product, commercial, investors) to agree on one shared anchor metric.

• Translate that metric into each group’s language. (e.g. “reduced bed days” = safer care for clinicians, freed capacity for ops, £ savings for investors).

• Put that shared metric at the top of your OKRs.

The Guiding Question

At the board level, founder level and advisor level, Kevin always comes back to the same question:

👉 Does clinical value drive commercial value?

If yes, double down. If not, you might be in the wrong market or have the wrong model.

Because at the end of the day, a healthtech business is still a business.

The takeaway?

Stop pitting purpose and profit against each other. The companies that will win are building models where one fuels the other.

Join Us at HLTH Europe 🇪🇺

Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.

👉 Register your interest for the panel here.

🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)

Clinical Product Drinks ✨

Last week we held Clinical Product Drinks #002 and it was such a fantastic crowd. 30+ clinical product leaders and managers all passionate about building the future of healthcare. 👉 For future events subscribe here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Welcome, friends, this is issue No. 030 of Clinical Product Thinking. This week we’re diving into a question I hear a lot: should clinical product managers be clinical safety trained? Let’s talk about it.

At its simplest, clinical safety is about ensuring that the products we build, digital health apps, medical devices, AI tools, prescribing services and care pathways do not cause harm when they are used in the real world. That is with real patients, messy workflows, incomplete data and clinicians who are already under pressure.

In the UK, clinical safety officers (CSOs) are responsible for ensuring that health technology systems are safe to use and that risks are identified, assessed and managed across the lifecycle of a product or service.

That includes understanding regulatory frameworks, running formal risk assessments, documenting hazards, reviewing incidents and making sure organisations meet relevant standards such as DCB0129 / DCB0160.

What CSO Training Actually Covers

Formal CSO training is not about learning how to write documents. It’s about learning how to think about risk in a structured way.

Most training covers some combination of:

• Risk identification and hazard analysis: How to systematically ask: what could go wrong, how likely is it and what would the impact be?

• Risk mitigation: How to design controls that reduce the likelihood or severity of harm

• Regulatory and safety standards: Understanding frameworks like ISO 14971, DCB0129 and DCB0160.

• Clinical risk assessment and documentation: Writing safety cases, hazard logs and risk assessments that stand up to scrutiny.

• Post-market surveillance and incident review: What happens after launch, when real users do things you didn’t expect.

• Patient safety principles: Designing systems that are safe not just when used correctly, but when used imperfectly.

None of this is theoretical. It is an essential part of building safe and effective digital health.

Should Clinical Product Managers Be Safety Trained?

My view is yes, Clinical Product Managers (CPMs) should be CSO-trained and here’s why:

1. Safety problems start in product decisions, not in safety reviews

If you’ve ever worked on a clinical product, you’ve seen examples like this first-hand:

• A prescribing flow that works perfectly in staging but fails when a patient misunderstands a question.

• A speech-to-text algorithm that performs well in validation but behaves unpredictably in a noisy A&E.

• An alert system that flags the right events in testing but generates so much noise in production that clinicians start ignoring it

CSO training helps CPMs see these risks sooner, when they are still cheap to fix.

2. Regulation is part of the product, not something bolted on later

Regulation is a design constraint, not a post-build action. When you’re building healthtech, you need to know:

• what standard applies

• what needs documenting

• what needs sign-off

• what will get questioned later

If people in the product team don’t understand this, you get the classic pattern:

Build → launch → panic → retrofit → slow everything down.

When CPMs understand safety frameworks, they design with those constraints in mind instead of discovering them at the worst possible moment.

3. It makes cross-functional work much easier

Clinical products sit in the middle of a lot of worlds:

• clinicians

• engineers

• compliance

• safety

• commercial

• regulators

And those groups do not naturally speak the same language.

A CPM with clinical safety knowledge can translate between them, turning risk into product decisions, regulation into requirements, and incidents into design changes.

That reduces friction across the whole team, and friction is usually what slows you down.

4. Risk management is already part of the CPM skillset

Clinical safety is structured thinking about failure modes.

What happens if the user clicks the wrong thing?
What happens if the data is missing?
What happens if the workflow is used differently than expected?

Good CPMs tend to think this way already, but CSO training makes that thinking explicit and systematic. You start designing with the assumption that the real world will not behave exactly as the spec says it should, and that mindset tends to produce products that are both safer and more usable.

In summary, the relatively modest time and monetary investment (more on this below) is well worth it. I’d also add that I consider clinical safety principles every single day.

The Case Against CSO Training

It is worth making an important distinction here. Completing CSO training as a CPM does not mean you should formally take on the CSO role. My personal view is that most CPMs working on clinical products would benefit from safety training, but only a small minority should hold formal CSO responsibility. We will look at clinical product and clinical safety team structures in a later post.

1. You’re more likely to be asked to take on the role

In startups, as a CPM with CSO training, there is a real chance you will asked to take on the CSO role, often with only a small amount of your time reserved for the task e.g. 10%.

This can work for earlier-stage, lower-risk products but it can also create risk for the individual as well as the organisation. Clinical safety is a formal responsibility, and it is difficult to do properly as a side task.

2. Role overlap and specialisation

Clinical safety is a highly specialised field. While having familiarity with safety standards is beneficial, CPMs need to focus on the broader scope of product development. The time invested in CSO training might distract from the core responsibilities of a CPM.

3. Role boundaries can become unclear

In many organisations, clinical safety sits with a dedicated CSO or safety function. If CPMs are also CSO trained the risk is that role boundaries become unclear.

You can end up with decisions sitting in the middle, where clinical product thinks safety owns the risk, safety thinks clinical product owns the design, and nobody is quite sure who is accountable for the final call. Organisations still need clear ownership of safety decisions.

4. Risk of over-engineering

CPMs who are newly exposed to safety frameworks can sometimes feel pressure to design for every possible risk scenario, which can slow development or introduce unnecessary complexity.

Safety matters, but so does usability, speed and the ability to iterate. Balancing those pressures is part of the job.

So, Should CPMs Be CSO-Trained?

My view is yes. Anyone working as a Clinical Product Manager on clinical products should understand clinical safety principles, and formal training is a worthwhile investment. Increasingly, job descriptions are also starting to ask for it.

Taking on the CSO role, however, will only make sense for some people, in some organisations, at some stages.

Clinical Safety Training Courses

Most people in the UK complete the NHS England Clinical Safety training. This usually involves basic and intermediate self-paced online modules, followed by a one-day practitioner course, which can be taken remotely or in person.

If you are currently working within the NHS the online courses are typically free. For practitioner training the cost ranges from £475 - £625. They also sell out quite quickly so do book ahead!

Another well-regarded option is the clinical safety course run by DPM. I haven’t taken this one myself, but several peers in the industry have told me it’s a longer, slightly more in-depth, manufacturer-focused course.

(This is not sponsored, just sharing options people commonly take.)

Join Us at HLTH Europe 🇪🇺

Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.

👉 Register your interest for the panel here.

🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)

Clinical Product Drinks ✨

📆 25th March, 6:30pm, The Folly.

Join for a drink with other folks at the front line of clinical product. This is an informal evening to mingle and share experiences. No agenda, no panel or slides. 👉 More tickets released here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Subscribe now

Welcome, friends, this is issue No. 029 of Clinical Product Thinking. This week I’m sharing something a little different: a look back over 2025 and a perspective on where we’re heading in 2026. Buckle up as this is a bit of a long one!

I think we can all agree Clinical Product isn’t a niche role anymore.

It’s no longer a clinician who ‘somehow ended up in product,’ or a product manager expected to absorb clinical risk by osmosis. It’s a discipline being defined in real time, by people like you, dear gentle reader.

Last year, I spoke with hundreds of people working in the clinical product orbit: founders, Clinical Safety Officers, product leaders, regulators and clinical product managers at the centre of increasingly complex systems.

I asked them all one simple question:

💭 What are the biggest challenges faced by Clinical Product Managers right now?

Together they point to a larger picture:

What did 2025 reveal about the state of Clinical Product? And where is the discipline heading next?

That’s our topic for today. Specifically, we’ll cover:

• Pain points: the six core challenges shaping day-to-day clinical product work

• The market: what current job descriptions reveal about how the role is being formalised

• What’s next: where the discipline is likely to evolve over the next 12–24 months

Section 1: The Core Challenges that Defined Clinical Product in 2025

1. Regulation vs innovation (the dominant tension)

This is the single most consistent theme.

CPMs are struggling with:

• Balancing regulatory compliance with speed and experimentation

• Building AI or data-heavy products under uncertain or evolving regulatory interpretations

• Translating regulatory requirements into practical product decisions, not just documentation

This shows up as:

• ‘Regulation vs innovation’

• ‘AI as a medical device, performance vs explainability’

• ‘Engineering approaches to facilitate regulation’

Signal: CPMs respect regulation but currently sometimes lack product-native ways of working within it.

2. Influence without authority

A close second.

Many CPMs describe difficulty:

• Getting buy-in from engineering, commercial or leadership

• Advocating for clinical safety, evidence, or quality when it’s not immediately revenue-generating

• Being listened to without being perceived as the blocker

• Operating in ambiguous roles where decision rights are unclear

This includes:

• ‘Communicating clinical needs to other stakeholders’

• ‘Influencing roadmap decisions’

• ‘Getting clinical considerations taken seriously early, not at sign-off’

Signal: CPMs are often senior in responsibility but junior in formal power.

3. Translating clinical reality into product systems

Another strong theme.

CPMs struggle with:

• Turning messy, contextual clinical practice into clean product logic

• Designing workflows that work across multiple clinician types and care settings

• Avoiding over-simplification without building unusable complexity

• Making products safe and usable in the real world

This often shows up as:

• ‘Product touches many clinicians’

• ‘How to represent clinical nuance in software’

• ‘Bridging the gap between clinical needs and technical implementation’

Signal: This is not a ‘requirements gathering’ problem; it’s a sensemaking problem.

4. Clinical safety integration (too late, too bolted-on)

Another frequently described challenge is clinical safety and how it’s integrated into teams.

Challenges include:

• Safety being treated as a checklist or gate rather than a design input

• Unclear ownership between product, clinical and governance teams

• Difficulty embedding safety thinking into agile development

• Friction between delivery timelines and safety assurance processes

Signal: Teams want safety by design, but many currently lack shared language, tools and rhythms.

5. Evidence, outcomes and ‘what’s enough?’

A quieter but important thread.

CPMs raised:

• Uncertainty around what level of evidence is proportionate

• Tension between real-world evidence and formal validation

• Pressure to ‘prove impact’ without being clear on the standards

• Confusion over how evidence expectations differ by market (UK / EU / US)

Signal: Evidence strategy is becoming a product strategy, but many CPMs feel a lack of clarity.

6. Role ambiguity and career uncertainty (implicit but real)

Present underneath many responses is uncertainty about what clinical product actually is.

CPMs are operating in:

• Poorly defined roles

• Organisations that don’t yet understand ‘clinical product’

• Career paths without clear progression or peer benchmarks

Signal: The discipline is still forming and people feel that.

The underlying pattern

Across all responses, the core issue is not lack of skill or expertise.

Clinical Product Managers are often:

• Holding risk, safety, evidence and user impact

• Moving at startup speed

• Operating without shared frameworks, organisational backing or clear authority

In short:

Many Clinical Product Managers are carrying systemic responsibility in organisations that have not yet built systems to support them.

This is Clinical Product as per 2025.

Section 2: The Hiring Market

What UK and US Clinical Product Roles Reveal

As Clinical Product is evolving, job descriptions give clues as to the direction of travel.

Here are insights from analysing job descriptions from the UK, and for the first time, including analysis specifically for friends over in the US (who now account for 20% of readership!) Roles span startups, scale-ups and more established healthcare organisations, published in 2025.

🇬🇧 The UK Market

Across UK roles analysed, there is increasing consistency in how clinical product is defined.

1. Clinical background is expected, not optional

Most UK roles explicitly require clinical training, e.g. doctor, nurse, pharmacist, or other allied health professional, although often with relatively limited patient-facing experience (1–3 years). The emphasis is not on senior clinical practice, but on clinical credibility and systems understanding.

This signals a shift: Clinical Product is no longer positioned as a generic PM role that anyone can move into. It is becoming a clinician-led function by default.

2. Safety, governance and regulation are embedded in the role

UK Clinical Product roles routinely include responsibility for:

• clinical risk identification and mitigation

• incident investigation and follow-up

• integration of clinical governance into delivery

• understanding and applying clinical safety standards (e.g. DCB0129)

• supporting or leading regulatory activity

In several roles, Clinical Product implicitly absorbs responsibilities that may traditionally sit with dedicated safety, quality or regulatory teams. In practice, this creates CPM roles that are responsible for clinical safety, not merely contributors to it.

3. “Product” is defined as care delivery, not features

UK job descriptions consistently frame product as an end-to-end care system, encompassing:

• clinical pathways and decision logic

• operating models, SOPs and training

• escalation and safety mechanisms

• internal tools for clinicians and operations

Clinical product managers are expected to design entire care journeys rather than building isolated features.

4. Evidence beats engagement

Across job descriptions, success isn’t defined by metrics like daily active users, retention or NPS.

Instead, CPMs are being measured on:

• pathway performance and quality indicators

• outcomes and evaluation

• real-world data and evidence generation

• credibility with regulators, partners and the NHS

Traditional product engagement metrics are secondary to clinical impact and assurance.

5. Scope is wide and often stretched

Many UK roles combine responsibilities across:

• product strategy and delivery

• clinical operations

• safety and risk management

• regulatory coordination

• evidence and evaluation

• partnerships and due diligence

This breadth suggests a discipline still maturing, with organisations relying on Clinical Product to hold together multiple high-risk domains.

While powerful, this can create roles where accountability outpaces resourcing, authority… and support!

🇺🇸 The US Market

US roles show significantly greater variation in how “Clinical Product” is defined, alongside a clearer separation of responsibilities.

1. Clinical Product does not consistently require clinical training

Unlike the UK, many US roles do not require candidates to be clinicians. This suggests that in the US, “clinical” often refers to:

• the problem space (healthcare, medicine, diagnostics), or

• the outcomes being targeted

—not necessarily the professional background of the product leader.

2. Regulation and safety are present, but rarely owned by clinical product

US job descriptions acknowledge regulatory and clinical constraints, but responsibility is more often described as:

• collaboration with medical, quality or compliance teams

• consultation on validation, human factors or regulatory pathways

Rather than direct ownership.

This indicates a structural difference: US Clinical Product roles interface with governance; UK roles internalise it.

3. Greater emphasis on scale and business impact

Across US roles, success is commonly defined in terms of:

• measurable health outcomes at scale

• provider or member efficiency

• adoption and operational performance

• ROI for employers, payers or customers

Clinical Product is framed as a lever for organisational scale and impact, with strong alignment to commercial or population-level goals.

The key contrast

Across this dataset, the most important distinction is where accountability sits.

• In the UK, Clinical Product is a clinician-led function, often absorbing clinical risk, governance and safety.

• In the US, Clinical Product roles are more commercial, focusing on scale, outcomes and product impact, with governance distributed across specialist functions.

Both approaches create senior roles with influence, but the work itself and the risks that come with it look very different.

Section 3: Predictions for 2026

It wouldn’t be a ‘state of’ report without making some predictions for what comes next 🔮. Here’s where I believe the clinical product market is moving in 2026:

1. Director and VP clinical product roles become standard, not exceptional

In 2026, Clinical Product is moving decisively into senior leadership at Director and VP level.

These roles won’t exist to “manage PMs”. They will exist to:

• hold explicit accountability for clinical risk at product level

• arbitrate trade-offs between safety, evidence, speed and scale

• sit alongside engineering, commercial and medical leadership as peers

This trend is likely to produce something new: the first C-suite clinical product leaders, emerging in organisations where clinical decision-making is fundamentally embedded in the product itself.

2. AI becomes core infrastructure for clinical product work

In 2026, AI will reshape Clinical Product management itself, not with generic GPTs, but with purpose-build products that act as core capacity infrastructure, embedded into how work gets done.

Expect AI to be used for:

• assisted clinical risk identification and hazard surfacing

• supporting workflow and pathway modelling across complex care systems

• natural language querying across safety cases, regulatory documentation and standards

As a result, the scope of what a single CPM can reasonably own, and is expected to own, will expand.

3. Clinical Product formalises as a function

In 2026, Clinical Product will no longer be defined primarily by individuals, but by structure.

Organisations will begin to formalise Clinical Product as a governed function with:

• clearer decision rights

• explicit ownership boundaries

• defined interfaces with clinical safety, medical, regulatory and engineering teams

The persistent question, “What does a Clinical Product Manager actually do?”, will begin to fade, replaced by more consistent expectations of scope, authority and accountability.

4. The first widely recognised Clinical Product career framework emerges

By 2026, Clinical Product will begin to develop a shared career language.

We’ll see early convergence around:

• clearer role definitions (CPM → Senior CPM → Head → VP → C-suite

• emerging levelling, competency expectations and salary banding

• clearer separation between Clinical Product, Clinical Safety Officer and QARA roles

• more realistic job scopes aligned to authority and support

This will materially reduce career ambiguity and accelerate the discipline’s maturation.

Conclusion: Clinical Product at a Turning Point

Clinical Product is crossing a threshold. It is becoming core infrastructure, shaping how clinical risk, evidence, regulation and care delivery are designed into products from the outset.

In practice, this shift shows up as a set of clear trajectories:

• Compliance → Design

• Reactive → Proactive

• Clinical translator → Clinical strategist

• Feature delivery → Outcome delivery

• Supporting role → Core function

In many organisations, however, responsibility has moved faster than structure. The scope of the Clinical Product role often exceeds the authority, frameworks and organisational support available to sustain it.

How deliberately organisations respond to this will shape the next phase of the discipline. As healthcare products become more complex, the need for people who can think across clinical, product and regulatory domains will only increase.

Clinical Product is no longer an emerging niche. It is becoming part of the foundation on which great healthtech is built.

Your Turn

If you work in or around clinical product:

👉 Which challenges feel most pressing in your work right now?
👉 Where do you think the discipline needs to go next?

I’d love to hear from you - just hit reply.

Hiring Spotlight x 5 🚀🚀🚀🚀🚀

🇬🇧 Aisel Health, the clinical operating system for modern psychiatry are hiring a Head of Clinical Innovation to support mapping clinical workflows and clinical pathway design. 👉 Apply here.
🇬🇧 Manual, or Voy, the online care provider, are hiring a weight loss Clinical Lead and a Clinical Advisor for weight loss. 👉 Apply here & here.

🇬🇧 Numan, the online care provider are hiring a Clinical Governance Lead. This would be a great opportunity to work alongside one of the largest clinical product teams in the UK. 👉 Apply here.
🇺🇸 Headway, the matching platform for therapists are hiring a Director of Clinical Product. 👉 Apply here.

Join Us at HLTH Europe 🇪🇺

Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.

👉 Register your interest for the panel here.

🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)

Clinical Product Drinks ✨

📆 25th March, 6:30pm, The Folly.

Join for a drink with other folks at the front line of clinical product. This is an informal evening to mingle and share experiences. No agenda, no panel or slides. 👉 Get your ticket here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Subscribe now

Good afternoon friends, this is issue No. 028. This week we’re diving into the different cognitive modes of clinicians and product people and how clinical product managers learn to switch between them.

“The mindset of a clinician and the mindset of a product person are diametrically opposed.”

Said to me by a healthtech CEO.

It’s an uncomfortable truth that many startups and clinicians face when bringing in clinical support.

A clinician’s job is to recognise patterns quickly and mitigate risk.

A product manager’s job is to stay curious, explore ambiguity and resist jumping to solutions too early.

At first glance, these might not seem so different. In reality, they often collide.

Convergent Thinking: The Clinical Mode

Clinical training is built around convergent thinking. You rule out, narrow down and try to eliminate uncertainty. Pattern recognition becomes automatic.

Take for instance, a febrile child in a ten-minute GP consultation. Your mind immediately runs through the worst-case scenarios, e.g. could this be meningitis?

You assess the symptoms, examine the child, consider the history and make a decision: Does this child need urgent escalation?

You can see clinicians are trained to:

• recognise patterns quickly

• rule out danger

• make defensible decisions with incomplete information

Clinical success depends on reducing the problem space safely and quickly.

Divergent Thinking: The Product Mode

Product development operates in the opposite cognitive mode. Product teams work in divergent thinking. Instead of trying to narrow the problem space, they seek to endlessly expand it.

Take the same febrile child scenario, a product team might ask very different questions:

• Why do parents struggle with managing fever at home?

• What was their experience in the GP surgery?

• Why did they decide to seek care?

• Why aren’t existing resources helping them?

Instead of collapsing the situation into a diagnosis, product thinking explores the system around the problem.

The goal is to understand why this situation occurs, so something better can be designed.

The Misdiagnosis

Because of this tension, I’ve heard an incorrect narrative in the startup ecosystem:

“Clinicians make bad product managers.”

But that diagnosis is, in my opinion, totally wrong. The issue isn’t capability. It’s training.

Product managers didn’t leave the womb knowing how to run discovery interviews, design experiments or build opportunity-solution trees. They learned those skills through experience.

Product management is a craft. And like any craft, it can be taught… including, of course, to clinicians.

The Real Skill: Switching Modes

The people who become effective clinical product leaders don’t abandon their clinical thinking. They learn when to use each mode.

During discovery and product design, divergent thinking is critical. You explore the problem space, ask why repeatedly and resist jumping to solutions.

But when designing clinical pathways, prescribing criteria, or safety processes, convergent thinking becomes essential.

You narrow the options, you assess risk and you arrive at defensible decisions.

Clinical product thinking is the ability to move deliberately between these modes. Too much convergence too early leads to premature solutions.

Too much divergence too late means systems don’t get launched.

The real skill is knowing when to switch between them.

Join Us at HLTH Europe 🇪🇺

Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.

👉 Register your interest for the panel here.

🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)

Clinical Product Drinks ✨

📆 25th March, 6:30pm, The Folly.

Join for a drink with other folks at the front line of clinical product. This is an informal evening to mingle and share experiences. No agenda, no panel or slides. 👉 Get your ticket here.

Hiring Spotlight 🚀

Heidi Health are hiring a Clinical Associate. This role sits within the Customer Success team, so while it isn’t a pure clinical product role, it would be an excellent stepping stone for clinicians interested in moving towards clinical product management. 👉 Apply here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Subscribe now

Good afternoon friends, this is issue No. 027. This week we’re diving back into regulation with a breakdown of one of the biggest grey areas in digital health: when patient support apps cross into medical device territory.

Many teams in digital health don’t set out to build a medical device but somewhere between helping patients manage and clinicians decide, they cross that line. Sometimes without even realising it.

That’s exactly what the whitepaper from Avegen and 8fold Governance is tackling: the grey zone where an unregulated patient support app becomes a medical device, designed for treatment. Highly recommend you check it out here.

The Problem

Companies building patient support tools often run into the same catch-22:

Build something too light, and it likely won’t change outcomes.
Build something too clinical, and suddenly you’re in regulated territory.

So teams risk ending up with half-baked solutions that sound great on paper but collapse in clinical reality, watered down until they’ve lost real impact.

The difficulty lies in recognising exactly where the line sits between wellness and medical device, and designing accordingly.

If you’re new to medical device regulation, I wrote a 101 for CPMs that you can check out here.

The Grey Zones

The whitepaper expertly lays out a number of grey zones in patient support apps that I’ve summarised below:

1. The AI Analysis Line

The scenario:
You’ve built an an app to support people with digestive health issues. It includes a food diary and symptom tracking to help users understand possible food triggers. The CEO wants to use AI to analyse patterns and generate personalised insights.

❓Ask yourself the question: Is this a medical device?

The Answer:
This one’s subtle. The moment the app moves from tracking to interpreting health data, you’re moving towards regulated territory.

• ✅ Not SaMD: Logging food and symptoms side-by-side.

• ⚠️ Grey zone: Showing correlations (”Your symptoms spike after dairy”) - the app is interpreting health data.

• 🔴 Definitely SaMD: AI-driven suggestions of causal links used for clinical decisions.

👉 Navigation approach:

• Presentation matters: Use language like “patterns observed” rather than “this food causes your symptoms”

• Document your intended use: Position the app as a wellness tool to support lifestyle management, not as diagnostic.

• Mitigate: Ensure you control and limit any medical claims and include guidance that the app is not a substitute for medical advice.

2. The Educational Content Edge

The scenario:
A digital health programme included a patient-facing “Learn” module with educational materials on exercise, nutrition, and smoking cessation alongside condition-related information to improve engagement with a rehabilitation process.

❓Ask yourself the question: Is this a medical device?

The line:
General health and lifestyle education is usually fine. But when educational content is condition-specific and provided within the context of a structured treatment programme, there’s a risk it may be perceived as part of the therapeutic intervention.

• ✅ Not SaMD: General health and wellness resources

• ⚠️ Grey zone: Condition-related information in a rehab programme

• 🔴 Potentially SaMD: Educational content framed as delivering therapy

If the educational content is presented as prescriptive instructions or framed as delivering therapy, the feature could meet the definition of a medical device.

👉 Navigation approach:

• Frame intent: Document that the Learn module is educational only aimed at patient empowerment, not as a treatment or therapeutic.

• Limit scope: Present content in an informational way without personalisation based on health data.

• Content governance: Be mindful of not overstepping in content language and avoid declarative statements like ‘use this treatment’.

3. The Behaviour Change Boundary

The scenario:
You’ve build a digital intervention aimed at people living with chronic fatigue or long COVID. The app includes fatigue tracking through self-check-ins as well as exercise, balance and cognitive behavioural content and allows communication with healthcare professionals.

❓Ask yourself the question: Is this a medical device?

The line:
General health and wellness education is usually fine. But when behaviour change is tied to disease-specific outcomes and delivered as part of a structured therapy, you could have built yourself a medical device.

• ✅ Not SaMD: Generic wellness tips not tied to specific conditions

• ⚠️ Grey zone: Condition-related educational content within a rehab programme

• 🔴 Definitely SaMD: Evidence-based therapeutic intervention intended to reduce clinical symptoms

By providing insights into fatigue patterns, supporting behavioural interventions, and facilitating healthcare professional engagement, the app functioned as a therapeutic tool to manage a disease-related symptom. Classification: Class I medical device.

4. The Clinician Dashboard Dilemma

The scenario:
You’ve built a clinician-facing portal that consolidates patient-reported data into progress dashboards.

❓Ask yourself the question: Is this a medical device?

The line:
If those dashboards are used for remote monitoring and inform clinical decisions about care management, you’re building a medical device, even if the patient-facing side feels like “just tracking.”

• ✅ Not SaMD: Exchange secure messages with clinical staff

• 🔴 Definitely SaMD: Scoring or dashboards with analysis that directly support care management decisions

If a clinician relies on your dashboard output to adjust medication, escalate care, or change treatment plans, you’re looking at a medical device.

The Clinical Product Thinking Takeaway

A clinical product manager’s job is not to act as the QARA or head of regulatory but knowing when a product becomes a medical device will be enormously helpful.

Before you build, ask yourself the question:

Could this feature drive a clinical action?

If you answered “yes”, you’re entering SaMD territory and need to plan accordingly.

We don’t need any more unregulated medical devices. We need safe, smart, clinically grounded tools that patients and clinicians can trust.

The future of digital health isn’t about avoiding SaMD. It’s about designing for it intelligently.

That’s the public post for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

[NEW] Want to Go Deeper? 👇 Join Paid

Founding Members get access to additional resources, frameworks and recordings plus a free 30-min personal advisory session with me to accelerate your next move.

Limited to 30 members only.

Read more

Subscribe now

Good afternoon friends, this is issue No. 026. This week, we’re talking about clinical vibe coding and why and when it’s useful.

Over the past few weeks, I’ve had the pleasure of teaching at Bitelabs, where the cohort are about to start building their first healthtech products, as well as judging a startup competition with More than Medics, where teams presented genuinely beautiful clinical product prototypes.

These events brought to mind one of the most useful conversations I’ve had recently with Mike Pogose, Director of Quality Assurance and Regulatory Affairs at Hardian Health.

He described a pattern he’s seeing more and more: clinicians building thoughtful, impressive vibe-coded solutions and understandably feeling they’re close to certification, when in reality they’re still at the prototype stage.

This isn’t a judgement. It’s a misunderstanding, accelerated by the power of the tools we’re using.

We now live in a world where something can look production-ready long before it is mature.

Which is why clinical product leaders need to understand the basics of Technology Readiness Levels (TRLs) and what they mean for product maturity.

What Are Technology Readiness Levels?

Technology Readiness Levels were originally developed by NASA to assess whether a technology that worked in a lab was actually ready to operate in space.

They’re not a regulatory framework. They’re a maturity framework.

TRLs are now widely used across aerospace, defence, advanced engineering and publicly funded R&D to describe how developed a technology really is.

In simplified terms:

• TRL 1–3 → Early concepts and prototypes

• TRL 4–6 → Development, validation, early real-world testing

• TRL 7–8 → Demonstrated in operational environments, certification-ready

• TRL 9 → Fully operational with post-market surveillance

They answer one question:

How mature is this technology, really?

Not:

Is it legally approved?

That’s regulation.

TRL is about engineering and operational maturity.

The Vibe Coding Distortion

Large language models have changed the visual and experiential bar.

You can now:

• Generate polished user interfaces

• Create clinically coherent-seeming logic

• Draft documentation in minutes

• Simulate a security posture

I’ve seen this repeatedly. The prototypes look genuinely impressive. But impressive is not the same as mature.

Most vibe-coded solutions sit firmly at TRL 1–3. And that’s fine.

TRL 2 is where ideas belong when they’re being explored.

What’s dangerous is mistaking:

“Ready to explore”
for
“Ready to certify”
or worse
“Ready for patients.”

What TRL 1–3 Usually Means in Practice

At TRL 1–3 you typically still lack:

• Robust, production-grade software architecture

• Deterministic behaviour under edge cases

• Validated and tested risk controls

• Traceability from requirements → hazards → mitigations

• A defensible clinical safety case

The logic might work. The UI might be elegant. But the foundations are not yet there.

“But It’s Just a Simple Tool…”

A common response is:

“It’s just a dosage calculator.”
“It’s only being used inside a hospital.”
“We’re not selling it.”

Even then, the bar is high.

The moment a tool influences clinical decision-making, you are in high-consequence territory.

TRL ≠ Certification Readiness

This is the distinction many teams miss.

Being ready to plan certification is not the same as being ready for certification.

At TRL 1–3 you should be asking:

• Is this problem worth solving?

• Does this intervention make clinical sense?

• What would the regulatory pathway look like if we pursued this properly?

You should not be expecting:

• CE or UKCA marking

• FDA clearance

• Or serious regulatory engagement beyond exploratory conversations

That work typically belongs much later, once the system has been deliberately engineered, tested and governed.

The Refactoring Fantasy

There’s another myth:

“We’ll just refactor it later.”

Refactoring is the process of restructuring existing code to improve its architecture, safety and maintainability without changing what it does.

In theory, yes, you could ask an engineer to refactor your vibe code base. But in practice, this usually means:

• Rewriting large parts of the codebase

• Untangling logic never designed for audit

• Retrofitting safety and maintainability

• Asking engineers to take ownership of decisions they didn’t make

Often, the prototype is quietly abandoned and rebuilt. Which can be painful if expectations weren’t set correctly.

Why This Matters for Clinical Product Managers

This is where clinical product judgement becomes critical. Your role isn’t to dampen innovation.

It’s to place it accurately on the maturity curve.

A strong CPM can say:

• “This is still in prototype stage, excellent for learning, not for patients.”

• “This is promising, but we are realistically 12 - 18 months from certification.”

• “This needs proper engineering input before we discuss regulatory strategy.”

That clarity protects:

• Patients

• Teams

• Founders

• And your own credibility

Because nothing erodes trust faster than overselling maturity in a safety-critical domain.

The Bottom Line

I’m personally incredibly excited by vibe coding tools and with Lovable recently raising $330m they are surely here to stay. While they are a powerful accelerator for early-stage exploration, clinical product maturity cannot be vibe-based.

Technology Readiness Levels give us a language to separate:

What looks real
from
What is ready

And in healthcare, that distinction matters a lot.

If your product lives at TRL 3, that’s not a bad thing. It’s the right place to start.

Just don’t mistake it for something it isn’t.

Join Us at HLTH Europe 🇪🇺

Danielle Brightman and I are running a panel event on clinical product with two incredible guest speakers. If you don’t know about HLTH, it’s the health tech conference you absolutely cannot miss.

👉 Register your interest for the panel here.

🎟️ Get your HLTH ticket here. (Use code: HE26PP_CPT250 for €250 off your ticket!)

Clinical Product Drinks ✨

📆 25th March, 6:30pm, The Folly.

Join for a drink with other folks at the front line of clinical product. This is an informal evening to mingle and share experiences. No agenda, no panel or slides. 👉 Get your ticket here.

Hiring Spotlight x 2 🚀🚀🚀

1️⃣ CareADHD

CareADHD are hiring a Clinical Product Manager, an exciting opportunity to help shape product strategy inside a fast-growing, specialist digital clinic delivering ADHD care. This role sits at the intersection of clinical governance, patient experience and scalable product delivery, translating complex care pathways into robust, patient-safe systems. If you’re a clinician or clinical product thinker who wants to build responsibly in a high-growth environment, this is a serious opportunity. 👉 Apply here.

2️⃣ AIBody:

AIBODY are hiring a Clinical Product Owner, a genuinely hybrid role at the intersection of clinical governance, product ownership and real-world deployment. You’ll translate complex physiology and clinical workflows into product features and lead rollouts into live clinics. If you’re a clinician who wants to move beyond advisory into true product ownership, balancing safety, usability and adoption in a high-complexity environment, this is a serious build role. 👉 JD is here. Please contact the team directly.

That’s the public post for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

[NEW] Want to Go Deeper? 👇 Join Paid

One of the biggest reasons Clinical Product Managers don’t get the cut-through they deserve isn’t capability, it’s commercial fluency. If you can’t confidently speak in terms of CAC, LTV, margin, runway or procurement dynamics, you risk being positioned as clinical support rather than strategic leadership. So I’ve created a 50-term Commercial Cheat Sheet for CPMs, the core vocabulary you need to operate credibly at C-suite level. It’s available below for paid subscribers. 👇

Read more

Subscribe now

Good afternoon friends, this is issue No. 025. This week, we’re talking about balancing speed vs safety in clinical product and why the best CPMs reject this false trade-off.

In startups, the mantra is clear: “Move fast and break things.”

In medicine, it’s even clearer: “First, do no harm.”

If you work in Clinical Product, you sit between those two worlds.

You are asked to move with urgency… and with restraint.
To accelerate progress… without compromising safety.
To ship quickly… and to design responsibly.

One side prizes speed. The other prizes certainty.

And you’re the one balancing both to find a pragmatic path forward.

Why Going Fast in HealthTech Can Feel Impossible

"Can we just ship this and iterate later?" The question no CPM wants to hear.

In consumer tech, broken features mean frustrated users and poor reviews. In healthcare, the consequences are potentially far more serious. Those stakes fundamentally change what “speed” actually means.

Here's what I've learned from teams spending months undoing "quick wins":

Speed without safety isn't speed at all; it's expensive future rework disguised as progress.

The real paradox? The safest, fastest way to build in healthcare often feels painfully slow upfront.

Examples I see constantly:

• Teams that delay clinical safety input until late-stage testing often discover fundamental issues, forcing substantial redesign rather than small, early corrections.

• Products built without clinicians in early discovery reach customers who don’t find them useful, fit for purpose, or safe, leading to stalled pilots, rework or quiet disengagement.

• Features designed without proper consideration of edge cases break down in real-world use, forcing reactive fixes in production.

The CPM Approach: Measured Speed

Great Clinical Product Managers don't just ping pong between clinical and product teams, they internalise both mantras and create a third way: measured speed.

Instead of choosing between "move fast" and "do no harm," they ask: "How do we move fast because we have the systems/processes to ensure we’re doing no harm?" (not as pithy, I’ll admit!)

This might look like:

• Building hazard identification into design sprints, not bolting it on later. When CPMs bring clinical safety thinking into wireframing, they catch issues when they’re easy to fix, not when they require architectural change.

• Translating safety into usable guardrails, not vague blockers. Instead of saying, “This isn’t safe,” effective CPMs say, “This creates a medication error risk. Here are three design patterns that eliminate it while preserving the experience.”

• Helping teams go slow where it matters so they can go fast everywhere else. Not every feature requires the same level of clinical scrutiny. CPMs clarify which decisions need formal clinical sign-off and which are safely reversible.

Why "Slow is Smooth" Wins Every Time

The irony is obvious once you see it: teams that feel "slow" because they're investing in clinical rigour upfront often ship faster overall.

• Approval processes don’t turn into urgent fire drills; requirements were clear from the start.

• Critical workflow flaws aren’t discovered at go-live, when changes are slow and costly.

• Clinical incidents are rarer, and trust with providers and patients remains intact.

• Safety issues are designed out early, rather than patched in later.

The result is what every HealthTech leader actually wants: safe speed.

The Compound Effect of Smooth

Teams that embrace "slow is smooth" don't just ship better products, they build better product muscles.

• Clinical thinking becomes embedded in product culture, not an external checkpoint. Product managers start asking safety questions naturally.

• Product thinking influences clinical processes, making safety reviews faster and more actionable.

• Regulatory requirements are treated as early design constraints, not last-minute surprises.

Over time, this integration creates something remarkable: teams that can move fast because they've internalised how to do no harm.

Over to You

The next time you feel that familiar tension between speed and safety, remember: you're not choosing between them. You're figuring out how to achieve both.

The question isn't "How fast can we go?" or "How safe can we be?"

It's "How do we build the systems and infrastructure that let us be fast and safe?"

Hiring Spotlight x 3 🚀🚀🚀

1️⃣ Dyad

Dyad are hiring a Chief Clinical Product Officer, and this is the first CCPO role I’ve personally seen. 🤩 This is a senior executive role owning product strategy end-to-end for Dyad’s clinically grounded AI platform, combining deep NHS credibility with real startup product leadership. If you’ve been asking what the C-suite endpoint for Clinical Product looks like, this is it. 👉 Apply here.

2️⃣ Semble:

Sara Fikrat, CPO at Semble, is hiring a Clinical Product Manager to scale clinical safety within their cloud-based clinical system used by thousands of clinicians. I caught up with Sara about the role and they’re looking for someone who can embed clinical safety by design while partnering closely with product and engineering, combining DCB0129 governance with real roadmap influence. 👉 Apply here.

3️⃣ Hesta Health

Hesta Health are hiring a Clinical Operations Associate. You won’t usually find ops roles here but as a favour to the team (who are mega) here we are. This is an excellent opportunity for anyone looking to break into HealthTech and who is passionate about redefining postnatal care. (Also gaining startup experience in an operations role is a good way to eventually move into product). 👉 Apply here.

That’s the public post for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

[NEW] Want to Go Deeper? 👇 Join Paid

Below is the recording from our recent panel with Danielle Brightman (Numan), Tulsi Patel (Hertility), and Dr Yath Premadasan (Flo Health), moderated by me.

We share an honest, expert perspective on how to find and secure your dream role in Clinical Product and how to truly nail the interviews when you get the opportunity.

Read more

Subscribe now

Good afternoon friends, this is issue No. 024. This week, we’re chatting with Dr Karim Sandid, GP turned clinical product manager and clinical safety officer, on what it means to build clinically safe products.

For years, startups have followed Mark Zuckerberg’s mantra:

Move fast and break things.

In consumer tech, breaking things usually means a feature that doesn’t work, a faulty release, or a short-lived outage. Annoying, but recoverable.

In healthtech, the things that break are different.

They include trust.
They include clinical confidence.
And sometimes, they include people.

So while this mantra may work in consumer tech, in clinical product, it would be something closer to: moving deliberately, with an eye on downstream consequences (not quite as catchy, I’ll admit).

That difference shaped much of my conversation with Karim:

Many clinical safety incidents aren’t unexpected failures.
They’re the unintended result of early product decisions.

Not software bugs.
Not freak edge cases.
But small, reasonable-seeming decisions that quietly shaped risk long before anyone called it a “safety issue”.

Where teams go wrong: design without a safety lens

Most healthtech teams use some form of design thinking:

• researching real user problems

• prototyping and testing solutions

• iterating towards better experiences

On paper, this should reduce risk.

But in reality, these processes often run without continuous clinical safety input, especially during everyday product decisions.

Safety tends to appear:

• at the very start (“Does this make clinical sense?”)

• or right at the end (“Can someone sign this off?”)

What’s missing is the middle, where hundreds of seemingly minor choices accumulate into material risk.

This is where an important distinction gets blurred:

Clinical input ≠ clinical safety input

A clinician might help you answer:

• Is this clinically sensible?

• Is this aligned with guidelines?

• Would this fit into a real workflow?

A clinical safety lens asks different questions:

• How could this be misunderstood?

• Where might a user place inappropriate trust in the product?

• What happens if this is used incorrectly, partially or under pressure?

• What assumptions are we making about behaviour, context or attention?

Those questions rarely come up unless someone is explicitly responsible for asking them.

A concrete example: when UI decisions become safety decisions

Karim shared a blood pressure product that looked, on the surface, very low risk.

The interface used:

• green, yellow, and red zones

• a clear disclaimer stating it was not intended to diagnose or treat medical conditions

From a product perspective, this felt sensible.
From a marketing perspective, it felt intuitive.

From a regulatory and safety perspective, it was a problem.

The colour coding alone implied normal versus abnormal.
That implication effectively positioned the product as a medical device, disclaimer or not.

Nothing about the data changed.
No new algorithm was added.

A single interface choice altered the product’s regulatory and safety profile.

This is the pattern I’ve seen a number of times:

• clinical input exists

• but safety implications of product decisions are only recognised after they’re embedded

The “house you can’t move” problem

Karim used an analogy that captures this perfectly.

Bringing clinical safety in late is like laying the foundations of a house, pouring the concrete, and setting the structure, only to be told afterwards that the house should sit two feet further up the hill.

You can move it.
But the cost is enormous.

In product development, early decisions harden quickly:

• data models

• escalation logic

• defaults and thresholds

• information architecture

By the time a product reaches beta or launch, many of these are effectively locked in.

Late safety review often means:

• rework

• scope reduction

• significant delays

• or uncomfortable compromises

So what does this mean day to day?

Clinical safety isn’t just documentation or sign-off.

It’s product decisions made long before launch, especially those that influence how users interpret, trust and act on what they see.

In practice, that means safety needs to be present:

• when success metrics are defined

• when defaults, thresholds and visual cues are chosen

• when workflows are simplified or steps removed

• when disclaimers are added instead of design constraints

These may not be moments that teams typically label as “safety decisions”.
But they’re exactly where risk is introduced.

The teams that do this well don’t run separate safety processes.
They ensure someone in the room is consistently asking:

“What could go wrong here, in the real world, not the happy path?”

Not at the end.
Not just for compliance.
But while decisions are still cheap to change.

This is also why I believe clinical product managers should be clinically safety trained, to ensure safety-aware judgement is present throughout product development.

Clinical Product Dinner ✨

📆 4th March - Designing Virtual Care Pathways: Where Clinical Safety, Product, and Operations Collide

An intimate dinner on the product, safety and operational decisions that make or break virtual care pathways. We’ll examine where teams underestimate risk as care moves into the home, and why early design choices matter most. Featuring Dr Sukrti Nagpal, Interim CMO at Doccla, on what actually happens at scale. 👉 Get your ticket here.

Hiring Spotlight 🚀

Dr Reinhold Innerhofer, co-founder and CMO of a new stealth healthtech company, is hiring a product-minded clinician to join the founding team. I caught up with Reinhold to talk about their direction: they’re on a mission to help 100 million people live their healthiest lives by moving healthcare upstream. This is a fantastic opportunity to help shape how a new category in preventive health is built. 👉 Apply here.

That’s the public post for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

[NEW] Want to Go Deeper? 👇 Join Paid

Below is an extended, off-the-record conversation with Dr Karim Sandid (Semble) exploring how clinical safety decisions actually get made in product teams, including trade-offs that are hard to capture in writing.

Read more

Subscribe now

Good afternoon friends, this is issue No. 023. This week, we’re diving into how to land your dream job in clinical product by avoiding these 7 mistakes.

I had the absolute pleasure of co-hosting a panel event with Danielle Brightman, Clinical Director of Numan, on Thursday, talking about how to break into clinical product.

What struck me both during the panel and from interviewing clinicians for product roles, as well as speaking to teams actively hiring into clinical product, is the same pattern I keep seeing.

Brilliant doctors.
Strong clinical instincts.
But a mismatch between what they say and what hiring teams are actually looking for.

If you’re a clinician trying to break into clinical product, here are seven shifts that will materially improve how you show up.

1. Clinical judgement, not niche expertise

Many clinicians assume credibility in clinical product comes from deep experience in a specific clinical domain.

In practice, most teams care far more about broad clinical judgement:

• how you reason under uncertainty

• how you weigh trade-offs

• how you anticipate downstream consequences

• can you think beyond treating one patient to building a system to treat many

Passion matters. Adaptability matters.
Rigid domain defensiveness rarely does.

What to do instead

• Talk through how you make decisions, not just your conclusions

• Frame risk as trade-offs with downstream impact, not binary blockers

• Practise translating individual clinical decisions into system-level thinking

2. Accept that there are no frameworks (yet)

Clinical product is still forming as a discipline.

There are:

• no standard playbooks

• no agreed best practices

• no formal training pathways

• no obvious route in

That’s unsettling, especially for clinicians used to structured progression.

But the practical implication is this: no one is going to tell you what “good” looks like.

In clinical product, hiring teams are looking for people who can:

• define the problem when it’s still fuzzy

• create structure where none exists

• make reasonable decisions without perfect information

What to do instead

• Practise turning ambiguous problems into clear options and recommendations

• Get comfortable proposing a direction before you’re 100% certain

• When interviewing, describe how you’d approach a problem, not just the answer

3. Ignore titles. Obsess over responsibility.

Titles in clinical product are unreliable signals.

The same title can mean radically different jobs.

What matters is:

• where clinical input enters decision-making

• whether you shape direction or review at the end

• what you actually own when things go wrong

What to do instead

• Read the job description.

• Ask how decisions are made.

• Don’t let the title alone make your decision.

4. Stop saying “we can’t”. Start offering paths forward

One of the biggest interview red flags is this sentence:

“We can’t do this because it’s clinically unsafe.”

That may be true but it’s incomplete.

Strong clinical product thinking sounds like:

“We can’t do this because it introduces X clinical risk, but here are two alternative paths that preserve safety while still supporting the commercial goal.”

Clinical product is not about blocking progress.
It’s about finding safe paths forward.

What to do instead

• Always name the specific risk, not just “safety”

• Offer at least one alternative option, even if it’s imperfect

• Frame safety as a constraint to design within, not a reason to stop

5. Design for experience, not just risk

Clinicians are excellent at spotting risk factors.

Where many struggle is translating that into a product experience.

I’ve seen assessments that:

• obsess over edge cases

• catalogue risk meticulously

• but ignore how the product actually feels to use

Things like:

• push notification timing

• scheduling system integration

• what happens when users don’t behave “as expected”

Clinical safety without experience design isn’t actually safe. Patients drop out of poorly designed products.

What to do instead

• Balance clinical safety with user experience, they’re not separate concerns

• Design for engagement, trust, and retention, not just risk reduction

• Consider the holistic end-to-end journey, not just individual clinical decision points

• Test your clinical logic against real user behaviour, not idealised pathways

6. Learn to speak clinical safety in commercial terms

This is the biggest unlock.

Clinical product leaders don’t just understand risk; they translate it.

They can explain:

• how safety decisions affect growth

• where regulation creates leverage, not just constraint

• why certain shortcuts increase long-term cost or reputational risk

If you don’t understand how businesses make decisions, your clinical insight won’t land, no matter how correct it is.

Clinical and commercial thinking are not trade-offs.
They’re mutually reinforcing.

What to do instead

• Frame safety decisions in terms of impact on trust, retention, and scale

• Link regulatory choices to long-term business value, not just compliance

• Quantify risk where possible (cost, delay, churn, reputational damage)

7. Don’t wait for the title to start doing the work

The strongest candidates rarely followed a neat path.

They:

• applied clinical product thinking in existing roles

• built side projects or prototypes

• experimented with LLMs, agents or tooling

• learned by doing, not waiting

What to do instead

• Apply product thinking to problems in your current role, even if it’s unofficial

• Build something small on the side to practise decision-making under constraints

• Document your thinking and trade-offs, not just the output

• Use examples from real work when interviewing, not hypothetical answers

The bottom line

Clinical product isn’t about choosing between medicine and product.

It’s about learning how to apply clinical judgement inside complex, imperfect systems.

The clinicians who stand out aren’t the ones with the neatest CVs or the most niche expertise.

They’re the ones who:

• think in trade-offs, not absolutes

• design for real people, not idealised patients

• avoid false trade-offs like safety and use experience

That’s the work.
Happy job hunting y’all! 💪

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Subscribe now

Good afternoon friends, this is issue No. 022. This week we’re discussing why good organisational structure alone isn’t enough and what actually makes clinical product effective

Last week, we looked at the Tech–Product–Medical (TPM) model that worked at Ada Health, based on my conversation with Lorenzo Espinosa.

The structure matters. But structure alone doesn’t make it work.

Part of what determined whether TPM accelerated delivery or collapsed into friction came down to how clinical product managers showed up inside it.

In particular, three mindset shifts consistently separated clinical product managers (CPMs) who became trusted partners from those who didn’t.

1. From “clinical input” to true partnership

The Tech-Product-Medical model only works well when clinical product stops operating as an external checkpoint and starts acting as a partner in product development.

At Ada, the clinical product managers who had the most impact didn’t sit at arm’s length.

They got close to:

• the product manager,

• the problem being solved,

• and the decisions being made as the work took shape.

That proximity mattered.

It meant clinical product wasn’t reacting to designs or solutions after they were formed. It was shaping the direction early, while options were still open and trade-offs were still cheap.

The mindset shift here is subtle but important:

Not “I represent clinical safety.”
But “I’m jointly responsible for helping this team make a good product decision.”

When clinical product shows up this way, it stops feeling like a gate at the end of the process and starts feeling like part of the engine.

2. From “can’t be done” to pragmatic option-building

One of the biggest unlocks Lorenzo described was pragmatism as a muscle.

Early on, clinical feedback often landed as a hard stop:

“This isn’t safe.”
“This doesn’t comply.”
“We can’t release this yet.”

Those concerns were usually valid.
But framed that way, they stalled momentum.

Over time, the most effective CPMs shifted from acting as gatekeepers to acting as option-creators.

Instead of:

“No, this can’t be done.”

They moved towards:

“Yes, that’s a real risk, but what if we approached it this way instead?”

That might mean:

• sequencing delivery differently,

• narrowing scope,

• reframing what “minimum clinically viable” really means,

• or proposing an alternative path that reduced risk without killing progress.

The mindset shift here isn’t about lowering standards.
It’s about helping the team move forward safely, rather than blocking movement entirely.

In TPM teams, progress comes from people who can hold safety and momentum at the same time.

3. From “clinical correctness” to commercial awareness

The third shift is the one many CPMs find most uncomfortable, but it’s also the one that builds the most trust.

At Ada, CPMs who understood the commercial context of decisions had far more influence.

They knew:

• what the product was sold for,

• who was paying,

• which clients were at risk,

• and what would happen if a feature slipped or failed.

That knowledge changed the conversation.

It meant clinical product could:

• prioritise risks in context,

• help teams make trade-offs consciously,

• and step into client conversations as a reassuring, credible clinical voice when needed.

The mindset shift is this:

Clinical doesn’t exist in a vacuum.
It exists inside a business that has customers, contracts, and consequences.

CPMs who grasp that become far more effective.

How these mindsets actually develop

What struck me most in this conversation is that none of these mindset shifts come from formal “clinical product training”.

In reality, there isn’t a single, established pathway for learning this work yet.

These skills are built through exposure, by seeing how product decisions get made under uncertainty, by working closely with product teams and by developing judgment over time.

What actually builds them is:

• spending time with product managers,

• learning how product decisions are made under uncertainty,

• understanding how the business really works,

• and seeing clinical product as part of the system, not outside it.

Equally, Lorenzo made a strong point about the other side of the partnership.

Product managers coming from a traditional product management model often underestimate how much clinical product can amplify their impact, not slow it down.

When that partnership clicks, output doesn’t just improve incrementally.
It compounds.

The real takeaway

The TPM model doesn’t succeed because it balances disciplines.

It succeeds when the people inside it adopt the right mental posture:

• partnership over policing,

• pragmatism over purity,

• context over isolation.

That’s where clinical product stops being perceived as friction and starts being experienced as force-multiplying.

Clinical Product Career Coaching 💁‍♀️

Opening up 4 spaces for clinicians looking to break into or progress within clinical product in 2026. For those who know their experience is valuable, but aren’t sure what actually counts or how to demonstrate product thinking that gets offers.

Focused, practical support (not generic advice or guesswork). 👉 Join here.

Hiring Spotlight 🚀

Raj Kohli, co-founder and CEO of HealthTech-1, is hiring a Clinical Product Manager. I caught up with Raj about the role and the team’s direction. HealthTech-1 is doing incredible work in primary care, and this position would suit a mid-level CPM with a strong regulatory mindset and Clinical Safety Officer (CSO) experience. 👉 Apply here.

That’s the public post for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

[New] Want to Go Deeper? Join Paid

A practical look at the decision frameworks and risk-thinking that allowed clinical product to stay embedded without slowing teams down. Plus early access to Clinical Product Thinking events in Q1.

How Ada Operationalised Clinical Product Without Stalling Delivery

To support the Tech-Product-Medical model, teams used multiple frameworks throughout the product development process:

Read more

Subscribe now

Good afternoon friends, this is issue No. 021. This week, we’re chatting with Lorenzo Espinosa who led B2B product at Ada Health, on the clinical product model that worked for them.

Ada has spent years building an AI-powered symptom assessment used by millions of patients across healthcare systems, insurers and providers. What interested me wasn’t just what they built, but how they structured clinical product to move fast without compromising safety.

Introducing the TPM model

Lorenzo explains that at Ada, product work was organised around standing cross-functional triads:

• Tech (engineering leadership)

• Product (product management)

• Medical (clinical / clinical product)

In some teams, a designer was also part of the core group. In others, a clinical product person was split across two squads, depending on demand.

Crucially, this wasn’t just a delivery-level construct. The same Tech–Product–Medical setup existed at the leadership level, creating a consistent decision-making structure from strategy through to execution.

That meant no meaningful decision happened without all three perspectives in the room.

Mutual education, not alignment theatre

This way of working didn’t click overnight.

It took time for teams to find their footing, but once they did, the value of true interdisciplinary work became obvious. A big part of that was mutual education.

Each function had to be explicit about what it optimised for:

• Tech prioritised platform stability, quality and scalability

• Product pushed for differentiation, speed and user-centred outcomes

• Medical focused on safety, regulatory compliance and avoiding harm

Those incentives are in tension, and that tension wasn’t a problem to be smoothed over. It was a feature.

Before this, many of those priorities were implicit. Decisions felt slow not because people disagreed, but because the trade-offs were never named.

With TPM, trade-offs became explicit. No single function could optimise unilaterally. Every major decision required negotiation across safety, value and feasibility.

Counterintuitively, that led to better decisions earlier, when changes were cheap and options were still open.

Pragmatism as a muscle

One of the biggest shifts TPM created was when clinical showed up.

Instead of product and engineering ideating in isolation, only to bring clinical in halfway through and discover fundamental issues, clinicians were involved from the very start.

Designers, engineers, product managers and clinical product worked together from inception. That alone prevented a huge amount of late-stage backtracking.

But structure wasn’t enough. The deeper shift was in how teams approached delivery.

Early on, clinical feedback often landed in an all-or-nothing frame:

“This cannot be done until everything is fully validated, verified and tested across all user demographics.”

That instinct is completely understandable. It’s driven by a deep responsibility for patient safety.

But framed that way, teams often had to wait until a feature was “fully done” before launching anything at all, which, in practice, meant shipping very slowly.

As Lorenzo described, you simply can’t operate that way and still build product.

Over time, Ada deliberately reframed the role of clinical product.

From approval to shaping the path

Instead of asking clinicians to approve or reject a fully formed solution, teams involved them in defining the safest sequence of delivery from the outset.

This wasn’t about lowering the bar on safety.

It was about doing the right safety thinking earlier, so teams could agree what was acceptable to release now, and what could responsibly come later.

The practical question shifted from:

Can we ship this at all?

to:

What does this need to include to be clinically viable as a first release, given the risks and context?

That single reframing, from binary approval to phased responsibility, unlocked progress without compromising patient safety.

A concrete example: EHR integrations

Consider ingesting data from an Electronic Health Record (EHR).

All-or-nothing approach:
Don’t launch until you can ingest the full dataset.

TPM approach:

• Phase 1: Ingest the minimum clinically necessary data (defined by clinical product). Launch and learn.

• Phase 2: Expand based on real-world usage.

• Phase 3: Full payload integration.

Because clinical product was in the room from day one, “minimum clinically necessary” was defined before a single line of code was written.

That’s the difference structure makes.

Why this matters

The TPM model worked at Ada because it:

• Embedded clinical product from day one

• Made trade-offs explicit and negotiable

• Built pragmatism into the system, not individual heroics

This wasn’t about faster delivery at any cost.

It was about creating a structure where safety, value and feasibility could be negotiated early, when changes are cheap and options are still open.

That’s the real power of clinical product done well.

Tune in for Part 2 next week on the three mindset shifts CPMs need to excel in the TPM model, plus practical ways to apply them in your own teams.

Clinical Product Dinner ✨

📆 4th February - How Clinicians Can Turn Expertise Into Category-Defining Healthtech Products

With Dr Arun Notaney, Founder of GP Automate, exploring how lived clinical experience can be transformed into category-defining healthtech products, and how frontline frustration becomes scalable, NHS-ready solutions. 👉 Get your ticket here.

That’s the public post for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

[New] Want to Go Deeper?

The two patterns that quietly derail TPM and access to new Clinical Product Thinking events in Q1.

The TPM model: the two failure modes that quietly kill it, and how to avoid them

If you take one thing from Ada’s TPM model, let it be this:

Read more

Subscribe now

Good afternoon friends, this is issue No. 020. This week, we’re talking about how to land your dream role in clinical product/healthtech.

In a few weeks, I’m co-hosting an event with Danielle Brightman, Clinical Director of Numan, on how to break into clinical product (link). In the lead-up, I’ve been reflecting on a question I’m asked quite a lot: how did you get the roles you’ve held over the last decade?

And here’s the tea:

I have never applied for a role online and then been invited to interview. Ever.

I’m sharing this because many clinicians leave clinical practice already questioning what they bring to a new industry. When they then spend months applying for jobs online and hearing nothing back, that doubt hardens into a totally inaccurate story:

Maybe I’m not qualified, good enough, [insert self-criticism here]

But that is the wrong conclusion, based on a flawed strategy.

Since leaving medicine in 2018, I’ve worked across venture capital, product leadership and healthtech in roles that are traditionally seen as difficult to access. Each came through people, proximity and visible thinking, not my CV standing out in a pile of 800 from an online application.

Below is how I secured each role, along with the lessons you can apply today to land your next role in healthtech.

How I actually got each role

🔗 Entrepreneur First

A business accelerator that’s harder to get into than Google or Harvard. I didn’t apply cold. Someone in my network knew Alice, co-founder and now CEO, and got me an interview just before the cohort started.

What mattered:
Not only did I have a warm introduction, but I’d already been building a product for six months.

🤝 Forward Partners (Venture Capital)

I did apply online. Then heard nothing. (Told you.)

Instead of leaving it at that, I chased down Matt, one of the partners, at a networking event. I introduced myself, talked through my career, referenced their portfolio, and shared how I’d been thinking about product strategy in one of their companies. He suggested an interview on the spot.

What mattered:
I’d already taken a product management course where I studied their portfolio deeply, was already networked with some of their portfolio CEOs and understood how startups are built. Then I did the uncomfortable thing of tracking him down at an event.

🎯 Bea Fertility

I met David, Bea’s co-founder, at a random hardware-in-femtech workshop years before joining. I had absolutely no reason to be there. I think the organiser was mildly annoyed I’d taken a spot.

What mattered:
I was already researching and writing about women’s health and attending random events years before the opportunity presented itself.

✍️ Metronomic

I wrote a piece on intuitive decision-making that I nearly didn’t publish. Sujith, the CEO, read it, reached out, and hired me.

We had:

• Never met

• No mutual contacts

• Lived on different continents

What mattered:
My thinking was visible, and I did the cringey thing of putting it out into the world.

🌱 Simplyhealth

I encouraged someone who was struggling to find a job. Later, they sent me this role.

Separately, I’d also been connected to the team through Annie Coleridge.

What mattered:
Instead of applying cold, I emailed the hiring manager I’d already spoken with. I paid it forward to support someone else in their search for their next role and it came back multiple-fold.

“This all sounds like luck…”

If you got through that list and thought:

“This is all luck and happenstance and completely unreplicable.”

Bear with me. Yes, there was timing. And chance. And generosity from others.

But there were also patterns. And those are replicable.

Here’s what was really happening underneath.

The underlying strategy (whether I realised it or not)

• I was building before being hired

• I was learning and sharing publicly

• I was thinking in years, not applications

• I was showing up in rooms, not inboxes

• I was giving without expectation

When I met each of those people:

• I already had work in motion

• I could speak concretely about problems and trade-offs

• I wasn’t asking for permission; I was showing capability

This brings me to another point we will expand on in another post: You don’t need a job title to do clinical product work.

If I were starting again, here’s how I’d approach it

I’d stop obsessing over the number of job applications and start optimising for surface area.

I would:

• Learn ferociously: Product fundamentals, strategy, delivery, AI, regulation, clinical safety. This means you’re ready for opportunities when they come.

• Build something: A clinical product, a prototype, a concept, a service, even if it never sees a patient. What you’ll learn will likely be more valuable than anything you read in a book.

• Invest in LinkedIn: I’ve never met a clinician who didn’t think this extremely unappealing at first but building a personal brand on Linkedin is one of the highest leverage things you can do.

• Put my thinking out there: Write. Post. Speak. Share unfinished ideas. When you share what is on your mind people know who to connect you with and what opportunities are relevant.

• Network in real life, with a long time horizon: At first, I would network indiscriminately. That’s how I started. Then, over time, more intentionally and strategically.

• Pay it forward relentlessly: Help without an agenda. It compounds in ways you can’t predict.

• Get formal signals where they matter: Clinical Safety Officer training. Core AI principles. Governance literacy. Not to collect certificates, but to prove commitment and capability in skills that actually matter.

• Seek early-stage advisory roles: Even if unpaid initially. It’s the fastest way to practise translating clinical expertise into product thinking.

What I wouldn’t do is rely on job boards as a primary strategy. Many of the most interesting roles in healthtech are filled long before a formal role is ever posted.

If you’re a clinician trying to move into healthtech and nothing is landing, the thing I’d love you to take away is this: it’s not a signal about your value. It is feedback on your approach.

If you’re in the middle of this transition, I’m rooting for you. 💪

Work With Me 💁‍♀️

I have a small amount of capacity to work with clinicians, founders and teams navigating career transitions or building clinical products, particularly where clinical risk, governance and product trade-offs are complex. If you’re facing a decision that feels high-stakes or hard to untangle, send a short note and I’ll let you know if it’s a fit. 👉 More info here

Clinical Product Dinner ✨

📆 4th February - How Clinicians Can Turn Expertise Into Category-Defining Healthtech Products

With Dr Arun Notaney, Founder of GP Automate, exploring how lived clinical experience can be transformed into category-defining healthtech products, and how frontline frustration becomes scalable, NHS-ready solutions. 👉 Get your ticket here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Subscribe now

Good afternoon friends, this is issue No. 019. This week we’re diving into two rooms I’m hosting, each designed to support clinicians and clinical product leaders at very different inflection points in their journey.

Over the last year, I’ve spoken to dozens of clinicians trying to move into clinical product and just as many product leaders trying to work out how to use clinical expertise well once they’re in the room.

What keeps coming up is this: most of the advice out there is either too abstract, too sanitised, or too late.

So I’m hosting two deliberately different kinds of rooms:

• One is about breaking in.

• The other is about breaking through.

Both are based on lived experience from experts in the field, not theory.

Event 1: Breaking Into Clinical Product with Numan (Live Panel)

Breaking into clinical product can feel daunting, not because clinicians lack capability, but because the path in isn’t clearly marked.

This live panel brings together clinicians and product leaders who’ve each taken very different routes into clinical product at leading healthtech companies.

Rather than abstract career advice, this session is grounded in personal experience: what worked, what didn’t, and what each panellist wishes they’d known earlier.

What we’ll explore

• ​How each panellist broke into clinical product and the inflection points that mattered

• ​The skills and experiences that actually make a difference when looking for a role

• ​What they look for now when working with, hiring or developing clinical product talent

• ​How to nail a clinical product interview

• ​Practical advice on how to get your foot in the door at leading healthtech companies

You’ll hear directly from

• Danielle Brightman (Numan) on building the clinical product team at Numan and what she looks for in a clinical product manager

• Tulsi Patel (Hertility) on what non-clinical product leaders look for in clinical product hires

• Dr Yath Premadasan (Flo Health) on breaking into clinical product at a company with global scale

• ​Host: Dr Louise Rix (Clinical Product Thinking) on patterns she sees across dozens of clinical product careers and where people most often get stuck

​Bring your questions, your uncertainties and your curiosity. The value of the session comes from the room as much as the panel.

Get Tickets Now

Event 2: From Burnout to Breakthrough — An Intimate Clinical Product Dinner

If the panel is about getting in, this dinner is about what happens after.

Join a small group of clinical product leaders, clinicians and founders for an intimate dinner exploring how lived clinical experience becomes the engine for category-defining healthtech products.

This is for people who already feel the frustration: you see the problems clearly, but turning that insight into a scalable, credible product is harder than it looks.

What we’ll discuss

• How to turn clinical expertise into a true product advantage, not just a credential

• Common patterns clinicians face when building products and businesses

• How to move from problem → insight → product → traction in the NHS

• How to navigate regulation, partnerships, evidence and early GTM without burning out

• Why strong clinical insight, safety and product thinking still differentiate teams in a crowded market

We’ll hear from Dr Arun Notaney, Founder of GP Automate, on how his experience as a GP partner sparked the idea for automating GP workflows and how he turned frontline pain into a product now used across the NHS.

As always, the dinner is highly collaborative. Bring your questions, your stories and your toughest challenges. We co-create the room together.

The practical bits

• Food: A delicious three-course meal, served family-style

• Cost: £65 (including service). Drinks can be ordered and paid for separately on the night 🍸

Get Tickets Now

Why these rooms matter

Conferences give you content. Panels give you positioning. Small rooms of people doing the work give you something closer to the truth.

These events aren’t about optics. They’re about helping clinicians and product leaders navigate the real trade-offs.

If either room sounds like where you are right now, I’d love to have you there!

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr. Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Made with 💜 for better, safer HealthTech.

Subscribe now

Good afternoon friends, this is issue No. 018. Today’s piece is about what emerges when clinical product leaders are brought into the same room to work through shared challenges.

In 2025, I ran a small experiment. I hosted a series of deliberately intimate, practitioner-led, off-the-record gatherings. No slides. No sponsors. No panels.

Just clinical product leaders in a room, comparing notes and solving problems.

The events themselves aren’t the story. What surfaced from them is.

This issue distils the patterns that kept reappearing across companies, seniority levels and problem spaces and why they matter right now.

Why These Rooms Matter Right Now

Conferences give you content.
Panels give you positioning.
Closed rooms of people doing the work give you something closer to the truth.

Clinical product is still young enough that many people working in it feel structurally alone. They’re the only clinical product person in their organisation, or one of very few, operating without established playbooks, precedents or career paths.

The isolation isn’t geographic.
It’s disciplinary.

These rooms mattered because they broke that isolation, not through networking, but through recognition.

Oh. You’re dealing with that too.

What Each Room Revealed

1️⃣ CPT Dinner: Defining Clinical Product as a Discipline

🔑 Key signal: No two companies define the role the same way.

The conversation wasn’t abstract. People compared actual job descriptions, reporting structures and decision-making authority. What became clear wasn’t just variation. It was a fundamental disagreement about what clinical product leaders are accountable for. Some own product strategy. Some own clinical safety. Some are brought in to “add clinical perspective” to decisions already made.

Beneath the surface, this isn’t a maturity issue. It’s a legitimacy question. Companies are still deciding whether clinical judgement is a strategic input that shapes product direction or a specialist function that validates choices after the fact.

2️⃣ CPT Dinner: Integrating Clinical Safety into Product Development

🔑 Key signal: Clinical product is often brought into safety conversations too late to shape outcomes.

The conversation with Karim Sandid from Semble highlighted what good integration looks like, but the room’s response revealed it’s not the norm. People described being asked to “sign off” on safety documentation after features are already built, or being looped into risk assessments when designs are locked. The frustration wasn’t about capability. It was about timing. Clinical safety isn’t something you can retrofit. When clinical product people arrive after architectural decisions are made, their options narrow to documentation and mitigation, not design and prevention.

3️⃣ CPT Dinner: Advocating for Clinical Product and Building Influence

🔑 Key signal: Influence is the hardest part of the job, and no one is teaching it.

Shubs Upadhyay, ex-Ada Health spoke about building buy-in across teams, but what dominated the conversation afterwards was how tiring it is to constantly justify your seat at the table. Several people described feeling like they’re perpetually having to prove clinical expertise matters every time a decision is made, instead of being assumed as foundational. The pattern wasn’t about lacking influence skills. It was about working in organisations where clinical judgement isn’t always structurally valued (at least not until something goes wrong).

4️⃣ CPT Drinks 🍸 #001

🔑 Key signal: Clinical product people feel isolated, not because they’re rare, but because the work has no established community of practice.

The conversation in the room revealed many feel like they are the only one facing these challenges. The isolation wasn’t about being the sole clinical product person at their company, some weren’t. It was about working in a discipline so new that there’s no shared language, no established career path and no obvious place to compare notes. People weren’t networking. They were confirming that their problems are real and valid.

5️⃣ CPT Dinner: Regulation Without Killing Innovation - AI as a Medical Device

🔑 Key signal: Building safe AI systems is top of mind.

Dr Dom Pimenta from Tortus AI described building a Class I medical device with regulatory rigour, but the room’s questions revealed how many clinical product folks are grappling with this. People were trying to figure out: when does our AI become a medical device? How do we govern updates? What does clinical safety look like for AI systems? It’s creating operational paralysis for teams trying to do the right thing without clear mental frameworks.

What Stayed Consistent Across All Rooms

Three patterns cut across all events, regardless of topic, seniority or company context.

1. Clinical product is often brought in too late to do its best work

By the time clinical expertise enters product decisions, the most consequential choices have already been made.

Clinical input is still too often treated as validation, not strategy.

2. The isolation is disciplinary, not geographic

People aren’t isolated because they’re remote or unique.
They’re isolated because there’s no established playbook, progression path or shared precedent.

The relief in these rooms came from realising the ambiguity wasn’t personal, it was structural.

3. Influence is the unlisted job requirement

The hardest part of the role isn’t technical complexity or regulatory knowledge.

It’s convincing organisations to value clinical judgement before problems surface, not after.

That negotiation, of scope, authority, timing and relevance, is rarely acknowledged, rarely taught, and often more exhausting than the work itself.

What Does This Changes for 2026

These patterns are shaping how I convene going forward.

In 2026, I’m moving away from broad networking and toward smaller, focused conversations around shared, specific challenges.

Less noise.
More signal.
More collective sense-making.

I hope to see you in one of those rooms in 2026.

Happy New Year ✨

Coffee & Chat ☕️

Trialling a new format in Jan: a relaxed, 50-minute online chat for people working in and around clinical product. The first session is 21 January at 4pm. Spaces are limited 👉 Sign up here.

Save the Date 📆

29 January — the first in-person Clinical Product Thinking event of the new year. We’ll be kicking things off with a panel event on how to get into clinical product with some very special guests. CPT subscribers will receive early access 👀

Hiring Spotlight 🚀

Raj Kohli, co-founder and CEO of HealthTech-1, is hiring a Clinical Product Manager. I caught up with Raj about the role and the team’s direction. HealthTech-1 is doing incredible work in primary care, and this position would suit a mid-level CPM with a strong regulatory mindset and Clinical Safety Officer (CSO) experience. 👉 Apply here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Subscribe now

Made with 💜 for better, safer HealthTech.

Subscribe now

Good afternoon friends, this is issue No. 017. This week, we’re keeping things intentionally light with a look back over Clinical Product Thinking content in 2025.

It’s 21 December, and if you’re anything like me, your brain is half in “wrap things up” mode and half in “please let me lie down” mode.

So rather than introducing something new, I wanted to share what resonated most in Clinical Product Thinking over the last few months and what I think that reveals about the direction of clinical product.

Clinical Product Thinking turns 4 (months)

Clinical Product Thinking 🧠 launched in mid-August 2025. We’re now 17 issues in, with 500+ subscribers and over 15,000 views.

Looking back across that time, a few themes clearly stand out.

The topics you’ve engaged with most:

• Introduction to regulation for Clinical Product Managers

• Clinical product as an emerging discipline

• How to get into clinical product and what “good” looks like in practice

Taken together, these themes aren’t random. They point to a need for orientation: Clinical Product Managers are defining their role in an increasingly complex landscape, while healthtech organisations are trying to make sense of a function that’s still taking shape.

⭐️ Most read: Intro to regulatory

Post: Software as a Medical Device Regulation — 101 for CPMs

I very nearly didn’t publish an introduction to software as a medical device because I worried it might feel too basic. In reality, the fundamentals are exactly what people are looking for.

Here are the practical takeaways from the post you can apply today:

⚙️ Practical takeaways for new CPMs

• Bookmark the MHRA’s guidance. You’ll use it often to check whether a feature tips your product into medical device territory.

• Clarify your intended use early. This single statement drives risk class, evidence requirements and regulatory pathway.

• Know your class. If you’re Class IIa or higher, expect deeper scrutiny, clinical evaluation and an external conformity assessment.

• Understand who regulates you. If you operate in both the UK and EU, you’ll need to align with both UK MDR and EU MDR frameworks.

• Familiarise yourself with key standards. ISO 13485 (quality), ISO 14971 (risk) and IEC 62304 (software lifecycle) shape how products are designed, tested and documented.

And most of all… don’t fear all the letters and numbers. You’re not meant to master everything overnight, just know what they govern and who in your team owns them.

👍 Most liked: Clinical product as a discipline

Post: Welcome to Clinical Product Thinking

This one means a lot to me because it’s the reason this Substack exists!

The central premise is simple:

We need to stop duct-taping clinical onto product development.

Clinical product isn’t a “nice to have”. It’s not “a clinician who ended up in product”.

It’s an emerging discipline that sits at the intersection of:

• patient safety

• evidence & outcomes

• real-world usability

• regulation

• and delivery at scale

When that discipline isn’t present, or isn’t properly resourced, teams pay for it later: in trust, adoption, safety workarounds and expensive rebuilds.

🙇‍♀️ Most engagement: How to get into clinical product

Post: How to Land Your First Clinical Product Role with Danielle Brightman of Numan

This post performs consistently because it answers a core question:

“Am I thinking about this role in the right way?”

Based on conversations with leaders hiring CPMs, the message was clear:

It’s not about having the perfect background or ticking every credential.

It’s about:

• curiosity over compliance

• systems thinking over feature delivery

• translating clinical risk into product decisions

• and catching problems before they become incidents

In other words, CPMs are trusted not because they know everything but because they know how to think, who to involve and where risk hides.

A quiet pattern I’m noticing

When you put these posts side by side, a pattern starts to emerge. There’s demand for shared language and decision-making frameworks that help teams do clinical product work when the stakes are high and the timelines are short.

Look out for more of this in 2026.

Happy holidays, all 🎄

Coffee & Chat ☕️

Trialling a new format in Jan: a relaxed, 50-minute online chat for people working in and around clinical product. The first session is 21 January at 4pm. Spaces are limited 👉 Sign up here.

Save the Date 📆

29 January — the first in-person Clinical Product Thinking event of the new year. We’ll be kicking things off with a panel event on how to get into clinical product with some very special guests. CPT subscribers will receive early access 👀

Hiring Spotlight 🚀

Raj Kohli, co-founder and CEO of HealthTech-1, is hiring a Clinical Product Manager. I caught up with Raj about the role and the team’s direction. HealthTech-1 is doing incredible work in primary care, and this position would suit a mid-level CPM with a strong regulatory mindset and Clinical Safety Officer (CSO) experience. 👉 Apply here.

That’s all for this week. See you next time! 👋

🤝 Work with me | 📅 Attend an event | | ✍️ Send a message

Written by Dr.Louise Rix, Head of Clinical Product, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on Linkedin.

Subscribe now

Made with 💜 for better, safer HealthTech.