Welcome, friends, this is issue No. 049 of Clinical Product Thinking. This week we’re talking about the skill clinical people are often judged on but are rarely taught.

Something I hear from hiring managers a lot is that clinical product managers are often clinically excellent but struggle to explain the commercial implications of their decisions. This isn’t really surprising if you think about it.

For clinicians coming from public healthcare systems, we’ve often not had to think of healthcare in monetary terms. But in HealthTech, clinical decisions affect cost, capacity and revenue, while commercial decisions can change the care patients receive.

For example, say you decide to add a mandatory clinician review to a patient flow because you’ve judged it as high risk. The review may reduce clinical risk but it also changes the cost of serving every patient.

Or if the business has decided to trim consultation length to fit more reviews into the day: you’ve changed how much time there is to catch something potentially serious.

Either decision may be reasonable but if you only consider one side, the trade-off is made without fully understanding it.

Here are 4 principles to consider as you’re building commercial nous:

1. Make trade-offs visible

A clinical recommendation is incomplete if it only describes the clinical benefit.

Take the mandatory clinician review example we discussed above.

Clinically, it might catch a missed deterioration. Operationally, you’ve added time to the pathway and that’s where the commercial hit comes from: every review costs money to serve.

None of that means you should remove the review. But it does mean being explicit about what that cost is so that the team can see the decision properly.

For any meaningful product decision, write down:

• Clinical consequence: what could this improve or put at risk for patients?

• Operational consequence: what does it mean for clinicians, support teams or workflow?

• Commercial consequence: what does it mean for cost, capacity, revenue or renewal?

• Recommendation: which option do you support, and why?

Then, when you are presenting it, lead with the consequence most relevant to the decision-maker.

2. Users ≠ customers

The user is the person who interacts with the product. The customer is who pays for it.

In direct-to-consumer weight loss, for example, they’re the same person. Simple.

But in a lot of healthtech, they’re not. An employer buys the mental health benefit. The employee uses it. An insurer funds the chronic care programme but the patient lives it.

When users and customers are different, you need to consider what good looks like for both. A happy customer does not mean the product works well for the user. And sadly great clinical outcomes do not guarantee renewal if the payer can’t see their return.

For your product, write down who uses it and who pays for it. If they’re different, ask what the payer is motivated by. That will decide whether you survive contract renewal.

3. Understand unit economics

Unit economics answer one question: is each patient, or each customer, actually viable?

You definitely don’t need to build an entire financial model. But it is helpful to understand key terms when they come up. Three worth knowing at a minimum:

Customer acquisition cost (CAC): what it costs to acquire one customer.

Lifetime value (LTV): what that customer is worth over their lifetime. Most subscription businesses want LTV to be at least three times CAC.

Contribution margin (CM): what’s left from each patient after the variable costs of serving them. This is the one clinical people move most. Clinician time, medication cost, a manual review step: every one of those impacts the contribution margin. (Bonus points if you want to learn the difference between CM1, CM2 & CM3, more here).

So when you add a safety step, you’re not just adding safety. You’re changing the economics of every single patient.

One tip is to ask someone in finance or commercial to walk you through the business’s financial model, even if informally. Understand what drives revenue, what drives cost to serve, and where clinical decisions land.

4. The model matters

A monk once told me something that has stayed with me: “Advice doesn’t work in the abstract.” And neither do product metrics!

Engagement is not a universal good. Retention is not always the goal. What either one means depends entirely on the model.

In a fixed-fee contract, engagement protects renewal - the payer wants to see people using what they bought. But it also increases cost to serve.

In a usage-based model, engagement is the revenue.

And in some models, more engagement is a warning sign, not a win. If you’re optimising for return visits in mental health or chronic care, ask whether you’re building value or building dependency.

Adoption is not the same as revenue. Retention is not the same as good care. A strong clinical product person always knows which metrics actually matter in the clinical context. They also ask the harder question: could optimising those metrics ever work against the patient? If the answer to that is yes, consider that tension as your job to own.

The takeaway

Clinical product is about building things that are not only clinically safe but also commercially sustainable, because a company that runs out of cash can’t deliver great care.

You don’t need an MBA to be successful but you do need to speak enough commercial to build influence.

Want to learn more? Check out:

📎 50 Commercial Terms Every CPM Needs to Know

A practical cheatsheet covering business models, unit economics, revenue, retention and healthcare-specific terms. 💪

Join the next panel 🎤

Sign up for the next Clinical Product Thinking panel event on building clinical AI systems that patients actually trust. Tuesday 8th Sept, 7 pm, online. 👉 Sign up here.

Subscriber Perks 🤩

Enjoying Clinical Product Thinking? Check out subscriber perks like deep dives on breaking into clinical product, embedding clinical safety into product decisions, building safe AI systems and more. 👉 View perks 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. 048 of Clinical Product Thinking. This week we’re looking at how clinicians can break into clinical product (a path I’d definitely recommend!)

In the recent Clinical Product Thinking × Numan webinar, co-hosted with Dani Brightman, Clinical Director at Numan, one question surfaced a lot:

How do I break into clinical product… especially without existing experience?

A clinical background gives you knowledge of patients, pathways and healthcare delivery more broadly. But it does not automatically show that you can work effectively in product.

Hiring managers need to be able to trust that you understand users, can work across disciplines, make proportionate decisions, test assumptions and can connect clinical value to commercial goals.

Our panel: Alice McGee, Senior Medical Advisor at Flo Health; Jamie Webb Smith, Chief Product and Technology Officer at Numan; and Lorenzo Espinoza, Director of Product at C the Signs, have all hired, interviewed and mentored clinicians making this transition.

This is what they advised clinicians to unlearn, demonstrate and practice if they want to be successful in getting a clinical product role:

1. Unlearn Deference

Alice had an interesting answer on what clinical people need to unlearn in order to be successful in clinical product:

“The biggest one is hierarchy. In hospitals and clinics there’s a very clear structure, you might be the most junior person on the team, and what the consultant says usually goes. In clinical product, that’s not the case. Sometimes the best ideas come from the person who’s just walked in the door with fresh eyes. You need to speak up and show your contribution.” Alice

Medicine can still default to deference, but clinical product requires the opposite: you need to contribute your perspective, challenge assumptions and definitely say when you think the team is heading in the wrong direction!

A clinical product team where everyone agrees too easily is unlikely to be examining the risks, trade-offs or alternatives closely enough.

👉 What to do about it:

• In your next meeting, ask the challenging question you’re tempted to swallow.

• Practise disagreeing constructively: “Here’s a risk I’d want us to consider” is more useful than staying silent.

• Stop waiting to be the most senior person in the room before you contribute.

2. What hiring managers are looking for

Lorenzo is currently hiring a Clinical Product Lead, so his screening criteria are worth writing down. Beyond the obvious clinical background relevant to the domain (for C the Signs, that means GPs, because they build for primary care), he described three qualities:

Pragmatism. Clinical product is about finding safer and better options that the team can work on, not simply identifying reasons why something can’t be done. The best clinical product people understand risk, explain it clearly and work with the team to find a proportionate way forward.

Commercial awareness. Clinical product shapes not just what gets built, but how it reaches people. You should understand who pays for the product, why customers choose it and what drives adoption.

Collaboration. Across product, engineering and commercial. Clinical product is a team sport, not single player mode.

And the bar is rising. Jamie has interviewed clinical product candidates for four years and has watched the pool mature:

“In the early days you saw a lot of clinicians who didn’t understand product and couldn’t express things in a customer-focused way. That’s changed a lot, people frame problems really well now, and the storytelling is getting better and better: using data, market understanding, telling a story about why something matters.” Jamie

What’s still rare, and therefore what sets you apart, is an experimentation mindset and genuine commercial understanding.

👉 What to do about it:

• Prepare a pragmatism story before your interview: a time you found a safe-enough path instead of blocking.

• Learn the commercial model of any product you talk about: who pays, how it’s adopted, why it wins. (Check out my commercial cheatsheet for CPMs here)

• Show an experimentation instinct: how you’d test a risky assumption cheaply, not just assess it.

3. Think like a product person

Building product nous is probably the number one priority for aspiring clinical product people. The panel’s recommended resources:

• 📖 Inspired by Marty Cagan. Lorenzo’s first product book and still his top recommendation.

• 📬 Lenny’s Newsletter. Jamie’s go-to. Deep, practical and absolutely tons of content to sink your teeth into!

• 🧑‍🏫 Consider getting a coach. Although not the cheapest option, it can super speed your learning:

“A few sessions with someone who’s lived it will crack your head open in a different way, very quickly, and show you different patterns of thinking.” Jamie

👉 What to do about it:

• Read Inspired this month. It’s the fastest way to learn the language of product.

• Subscribe to Lenny’s Newsletter and work backwards through the archive.

• Consider a few sessions with someone who’s done clinical product (not a generic careers coach)

4. Get your first bit of experience, even if small

The hardest part is the cold start: no clinical product experience, so no one hires you for clinical product. Alice’s advice is to create the experience for yourself:

“Try to get some type of advisory work, even if it’s voluntary, a few hours giving feedback, testing a feature. And think about all the health products you already use: your Apple Watch, your Oura ring, Apple Health. Reflect on the decisions behind those features, what you like and don’t like, and translate that into how you think.”
— Alice

You are more likely already surrounded by clinical products. Start critiquing them like you would if you were building them.

The good news is that these opportunities are becoming easier to find. Alice, who curates a weekly healthtech jobs roundup, has seen clinical product roles become far more clearly defined:

“We’re seeing more and more clinical product roles, head of clinical innovation, even chief clinical product officer. Before, those would have been called something else, or just ‘medical’. Now they’re better defined, with a clear scope and a clear value-add.” Alice

👉 What to do about it:

• Offer some voluntary advisory hours to a health tech startup: feedback, feature testing, a clinical sanity check.

• Do a product teardown of an app you use (Oura, Apple Health, a symptom checker).

• Follow Alice’s weekly roundups on Linkedin for current opportunities.

The takeaway

Breaking into clinical product is about showing how you can take your clinical knowledge and use it to understand users, identify risks early, work through constraints and help a multidisciplinary team make better product decisions. You do not need the title before you begin developing and demonstrating those skills.

If you’ve been thinking about making the move into clinical product management this might be your sign to take the leap.

Welcome to Subscriber Perks 🤩

I’m very excited to introduce subscriber perks: a growing library of resources for clinical product managers and people building clinical products or health tech companies.

What you’ll find:

• Deep dives on breaking into clinical product, embedding clinical safety into product decisions, building commercial knowledge and more

• Masterclasses on building safe clinical AI systems

• A guide to writing clinical product manager job descriptions that people can actually fill

• A database of European health tech VCs, grants and other funding opportunities

• A 30-minute clinical product advisory session with me for founding subscribers

👉 Check them out 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. 047 of Clinical Product Thinking. This week: a recap on the third webinar in the series on clinical product management, co-hosted with Dani Brightman.

When we ran the first in-person event in January, clinical product was still hugely under-recognised in health tech. Six months on it feels like things are slowly starting to shift. Roles are being named properly. Job descriptions are looking less like a dog’s dinner. And the question is beginning to shift from “WTF even is clinical product?” to “how do we do clinical product well?” 🎉

This time we deliberately widened the panel. You told us you wanted more product and technology voices, so we brought them in:

• Dani Brightman — Clinical Director, Numan (pharmacist by training, now leading biggest clinical product team in UK)

• Lorenzo Espinoza — Director of Product, C the Signs (early-stage cancer detection; 13+ years in product, 7 in health tech)

• Jamie Webb Smith — Chief Product & Technology Officer, Numan (engineer by background, ~20 years in regulated fintech before health)

• Dr Alice McGee — Senior Medical Advisor, Flo Health (doctor by background, ex-founder of a health tech consultancy)

What came out was an interesting reflection: building products that touch health needs a new kind of product leader and the companies who don’t recognise this early will end up paying the price.

Let’s dive in.

First, what is clinical product?

The reason clinical product has lived in a grey area for so long is that nobody agreed where its edges were. Dr Alice gave her definition and it’s purposefully broad:

“To me, clinical product is any kind of product that relates to health in any way, from a full-blown medical device to anything that lets a user track their health data, symptoms or outcomes.”
— Dr Alice McGee, Senior Medical Advisor, Flo Health

That’s a deliberately wide net, and it should be. The tracker that looks harmless today is one intended-use statement away from being a regulated medical device tomorrow. If your definition of “clinical” only kicks in once something is obviously a device, you run a serious risk of getting caught out.

Why it’s having its moment

Jamie made an interesting parallel and it’s not one I’ve heard before:

“I came from fintech about 10 years ago. We saw a very similar thing, regulation started to move, it started to enable innovation, and there was a real push for the larger fintechs to break through. I think it’s a similar moment in health tech, and central to that innovation is clinical thinking.”
— Jamie, Chief Product & Technology Officer, Numan

That’s the same pattern: consumer health exploding, people taking their health into their own hands, and regulation maturing from a blocker into an enabler. Fintech went through exactly this a decade ago. The companies that broke through were the ones that took the regulated core seriously and built product muscle around it. In health tech, that regulated core is clinical thinking.

The cost of not having clinical product embedded

Lorenzo has led product teams both with and without embedded clinical product people, and he was blunt about the difference. When clinical is treated as an external advisor or part-time help, it breaks down in both halves of the product process: discovery and delivery:

“We spent weeks and months solving a problem that was not the right problem to solve.”
— Lorenzo, Director of Product, C the Signs

Without clinical thinking from the start, the team can spend months building a good solution to a problem that did not need solving.

Jamie gave a concrete example of this. A company was prescribing GLP-1 medication and, after a period, renewed those prescriptions. The team Jamie was working with built the renewal flow without enough clinical product input embedded:

“A few small but critical elements weren’t right, which meant we didn’t get the information we needed at the right time for clinicians to make a good prescribing decision. So they had to go back to the patient, which creates unnecessary cycles.”
— Jamie, Chief Product & Technology Officer, Numan

That small gap meant clinicians had to contact patients again before renewing the prescription. It added work for the clinical team, delayed treatment and gave patients another opportunity to drop out. A “small” clinical oversight showed up as a revenue problem. That’s the pattern many health tech founders underestimate.

Lorenzo also described what happens when the patient experience works but the clinician workflow does not.

“Time and again we see health tech innovation that basically dies at pilot stage, because the dynamics of patients, business and clinicians are not in sync.”
— Lorenzo, Director of Product, C the Signs

You can design a beautiful patient experience that becomes ugly the moment it hits the clinician’s workflow if the end-to-end experience hasn’t been mapped from each users view point.

👉 What to do about it:

• Embed clinical product discovery, not just delivery. Most wrong-problem failures happen before a line of code is written.

• Map the clinician journey alongside the patient journey. If a feature adds work for the person on the other side of the screen, you’ll find out at pilot, the worst possible time.

• Run an early “are we accidentally a medical device?” check on intended use and marketing language. It’s cheap now and painful later.

You do not have to be a clinician to develop clinical product judgement

One thing I loved was how quickly the “clinician or product person” framing fell apart. Dr Alice pointed out that some of her strongest colleagues at Flo have no clinical background at all:

“They’ve been in the space five, six, seven years. They’re not clinical by background, but they think in a clinical product mindset now, from absorbing years of feedback and user insight.”
— Dr Alice McGee, Senior Medical Advisor, Flo Health

And it runs both ways. Jamie described what happens when product, design, engineering and clinical genuinely mix:

“You start to get real magic. It’s almost like you create a common problem-solving brain between clinical, technology and design.”
— Jamie, Chief Product & Technology Officer, Numan

That’s what companies should aim for. Not a clinician who signs things off at the end, but a shared way of thinking that lets clinicians adopt product frameworks and lets product people develop clinical instincts. The best teams build a common brain.

Where clinical product should sit (Culture beats the org chart)

We spent a good chunk on reporting lines, and the honest answer is: several structures work.

• Lorenzo (C the Signs): clinical product reports into product; the Clinical Safety Officer sits outside product to keep an independent view.

• Dr Alice (Flo Health): a medical function reporting to the CEO (a Chief Medical Officer providing C-suite representation), with a named medical advisor assigned to each product initiative.

Both set ups can work, and as Jamie put it:

“What matters more than line management is alignment on how the company operates. Small cross-functional teams with a very clear problem to solve. If your operating model is broken, line management won’t fix it.”
— Jamie, Chief Product & Technology Officer, Numan

The real answer to “where should clinical product sit?” is inside the cross-functional team, from day zero. Reporting lines vary, but clinical product needs to be involved in the team’s day-to-day decisions rather than consulted shortly before release.

👉 What to do about it:

• Do not spend too long perfecting reporting lines while clinical product remains outside the day-to-day work. Put clinical expertise into the team that is investigating and solving the problem.

• Give clinical product a proper role in shaping the solution, rather than asking for approval after the main decisions have already been made.

• Whatever your structure, consider having an independent clinical safety view (a CSO outside the delivery team) so speed never quietly overrides safety.

The takeaway

Clinical product isn’t the bit where a clinician signs things off at the end. It’s a discipline. And it sits in one very particular place: between the patient, the business and the clinician.

Health tech is having its fintech moment. The teams that win it won’t be the fastest. They’ll be the ones who got clinical thinking into the room early, and built the common brain as a strategic advantage.

Introducing Subscriber Perks 🤩

I’m very excited to introduce subscriber perks: a growing library of resources for clinical product managers and people building clinical products or health tech companies.

What you’ll find:

• Deep dives on breaking into clinical product, embedding clinical safety into product decisions, building commercial knowledge and more

• Masterclasses on building safe clinical AI systems

• A guide to writing clinical product manager job descriptions that people can actually fill

• A database of European health tech VCs, grants and other funding opportunities

• A 30-minute clinical product advisory session with me for founding subscribers

👉 Check them out 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. 046 of Clinical Product Thinking. This week: highlights from our Clinical AI panel, on where patient-facing AI fails when the model looks fine.

A few weeks ago I co-hosted a panel on building safe clinical AI systems with Dani.

If you only have a few minutes, here’s your tl;dr. If you want to dive deeper, the full recording is below.

On the panel:

• Dani Brightman — Clinical Director, Numan

• Dr Lucinda Scharff — Product Manager, Counsel Health (formerly Google Health / DeepMind)

• Dr Paul Sacher — Founder & CEO, Sacher AI

Let’s dive in.

A bot responded correctly but still failed clinically.

Dani gave an example from Numan’s customer care side. They built a bot to filter inbound patient requests and signpost people to the right clinical form. On paper, it worked well.

In practice, it missed what a human would have caught:

“Even though the bot was handling the inbound request correctly and providing the right signposting, the clinical team noticed that if the patient was also providing context, like they want to stop medication because ‘I’m having X side effect’, what should have happened is they escalate that ticket to a clinician to review it. The bot missed this important step”
— Dani Brightman, Numan

The bot completed the task but missed the clinical significance of the patient’s context.

A clinically correct model is not the same as better care

Dr Lucinda talked through a recent paper on using AI to detect cancer on chest X-rays. AI can flag lung cancer risk on a film, but the patient still needs someone to review the result, contact them, arrange the CT and provide follow-up care.

Faster diagnosis on an X-ray doesn’t automatically result in better patient outcomes if downstream dependencies haven’t been accounted for.

A useful signal with no reliable route to action means the product isn’t finished.

Behavioural harms are the hidden risk

Behavioural risk can create or amplify clinical risk, and they’re much harder to spot: sycophancy, erosion of patient agency and failure to escalate when a patient says they’re anxious, low or questioning whether to continue treatment.

Systems designed for engagement may keep chatting when the safe move is to refer the patient to a clinician.

“If you think about the scale of behavioural interventions that are happening through patient-facing AI, you can think of the whole thing as one massive behavioural intervention… that no one’s really monitoring.”
— Dr Paul Sacher, Sacher AI

Accuracy isn’t enough if the interaction nudges the patient towards an unsafe next step.

Safety is a team sport, not a clinician sign-off

A key point of the evening was about culture. Clinicians are essential to clinical AI teams, but safety can’t belong to them alone.

If the clinician is the person who turns up at the end to say yes or no, you get slow teams, frustrated clinicians, and products that treat clinical risk as a final check rather than a design concern.

The best teams build shared safety instincts early, in the model, the interface, the pathway, the escalation route, and the assumptions about how patients actually behave.

The takeaways

The evening’s themes:

1. Correct routing isn’t enough. The system must also recognise when additional context changes the appropriate next clinical step.

2. Models need pathways. A right answer still needs a route to action.

3. Measure behaviour, not just accuracy. The harms that scale are often patterns, not single unsafe statements.

4. Safety is designed in. Not bolted on at the end by a clinician.

🎥 Watch the full panel below. Dani, Dr Lucinda, Dr Paul and I go much deeper on clinical safety in AI products, friction as a safety feature, automation bias and what teams should measure before and after deployment.

For the full write-up with practical steps, read issue 041: How to Build Safe Clinical AI Systems.

Hiring spotlight 🚀

🇬🇧 Doccla are hiring a Head of Clinical Innovation. The role will be crucial in translating Doccla's clinical model into safe, evidence-based, and commercially impactful products and pathways. 👉 Apply here.

Join the next clinical product panel 🎤

📆 14th July, 7pm, online

The next clinical product panel is on 14th July and we’ll be covering the “clinical product gap” or why healthtech needs a new kind of product leader. 👉 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. 045 of Clinical Product Thinking. This week: highlights from our first panel, on where clinical judgement really belongs in a healthtech org.

A few weeks ago I co-hosted the first panel in a 3-part series organised with Dani. The full video is below. But if you only have a few minutes, your tl;dr is below:

I was joined by three leaders building clinical product at scale:

• Dr Anushka Mehrotra — Chief Medical Officer, Doctor Care Anywhere

• Dr Yath Prem — Medical Advisor, Flo Health

• Dani Brightman — Clinical Director, Numan

Three very different companies yet one shared conviction: clinical product isn’t a department you consult. It’s a discipline you build in.

Let’s dive in.

1. Clinical risk hides in the places non-clinicians don’t think to look

The panel circled back to this a number of times. The dangerous decisions can be the small product choices, the colour ranges on a blood pressure reading, a portal update that looks unchanged to the clinician on the other side, that quietly carry real clinical weight.

Anushka gave an example from Doctor Care Anywhere: an update had been made to the patient facing app, but the clinician interface looked the same. Everything was actually safe, but because it didn’t look like the clinicians expected they were worried the update hadn’t been made. The lesson: end-to-end mapping has to include every user’s perspective, not just the patient’s.

Dani put the principle plainly:

“In health tech, a product decision is a clinical decision when that product is shaping patient care.”
— Danielle Brightman, Numan

The trap: clinical risk doesn’t announce itself.

2. Involve safety early, or pay for it later

There’s a myth that clinical involvement slows teams down. The panel didn’t agree. Bring clinical judgement in late and you force everyone back to the drawing board, which is slower, not faster.

Dani built Numan’s clinical product function from zero to the largest team in the UK. Her take on accountability:

“If you can’t veto, then you can’t have the accountability, because that’s completely unfair. For you to hold the real weight of clinical safety, you also need to be able to say no at times, and know you’ve got backing for that.”
— Danielle Brightman, Numan

If you’re going to hold someone responsible for safety, they need the power to block. Anything less is a set-up.

3. Integrated, not consulted

Yath made the case for what 'integrated' actually means in practice. At Flo, medical advisors sit inside cross-functional squads with a dedicated PM, design, content and engineering, meeting almost daily.

“For Flo, it’s never a question of ‘should we listen to the medical advisor?’ It’s how do we work with the advisor from the beginning. It’s never a case of ‘shall we check with the medical advisor if this is okay’, the medical advisor is always in the conversation.”
— Dr Yath Prem, Flo Health

That’s the difference between clinical input as a gate and clinical input as a default.

4. How you communicate risk matters as much as spotting it

A practical takeaway came from Dani on communicating risk so that people listen:

“We’d say ‘this process means this patient might get a double dose,’ and leave it there, because we all knew the implications. But a non-clinical person didn’t really understand how bad that was. You need to take it further: this patient comes to moderate harm, hospitalisation, that’s irreversible. Then they’re like, ‘okay, that actually sounds quite serious.’”
— Dani Brightman, Numan

And pair it with the commercial reality: the litigation exposure, the payout costs, the drop-off. Do the research first so the risk is easy to prioritise.

When the answer is “too risky,” don’t stop at no. Anushka’s rule is pragmatic option building:

“There might be an option that’s too risky, but what’s the alternative? Is there something else that can be done that isn’t as risky, that helps to control some of that risk but still partially achieves what’s trying to be done?”
— Dr Anushka Mehrotra, Doctor Care Anywhere

The takeaways

The evening’s themes:

1. Integrated, not consulted. This phrase came up again and again.

2. The constant balance of clinical and commercial. Healthcare companies are still businesses. Both pillars have to be right.

3. Option building, not just blocking. “No” is rarely the end of the conversation.

4. A shared language. Different disciplines working together in high-risk, fast-paced environments all benefit when we speak each other’s vernacular.

Which is really just one idea, said a few different ways:

Clinical review is not a sign-off step. It is a design input.

🎥 Watch the full panel below. Anushka, Yath, Dani and I go far deeper than I’ve captured here, on reporting lines, scaling safely, and what founders get wrong before they scale.

Hiring spotlight 🚀

🇬🇧 Doccla are hiring a Head of Clinical Innovation. The role will be crucial in translating Doccla's clinical model into safe, evidence-based, and commercially impactful products and pathways. 👉 Apply here.

Join the next clinical product panel 🎤

📆 14th July, 7pm, online

The next clinical product panel is on 14th July and we’ll be covering the “clinical product gap” or why healthtech needs a new kind of product leader. 👉 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. 044 of Clinical Product Thinking. This week, we’re talking about the workflow we think we're designing for and the work that clinicians actually do.

Many clinical products are designed around the happy path: the patient follows the expected journey, the clinician has the information they need, the technology behaves as intended, and each step leads nicely to the next. It all looks perfectly represented on your Miro process map.

This is because most product discovery starts in the same way. We interview users, run workshops, map workflows and document requirements. These activities are useful and necessary. They help us understand how a service is supposed to operate.

The difficulty is that healthcare rarely behaves exactly as it is described.

Patients do not always follow the expected journey. Clinicians are interrupted, multi-tasking, overworked or all three. Information is missing. The computer is too slow to load.

By the time a workflow reaches a whiteboard, many of those details have disappeared.

Healthcare products are often designed around the happy path because the happy path is easier to see. It is neat, predictable and easy to describe.

Clinical work rarely is.

Work as imagined vs work as done

One of the most useful concepts from safety science is the distinction between work as imagined and work as done.

Work as imagined is how we think a process happens.

Work as done is what people actually do in order to get the job done.

The difference between those two things is often where the most valuable product insights are hiding.

A workflow diagram might show a clinician reviewing information in a single system before making a decision. In practice, they may be checking multiple systems, referring to notes written earlier in the day, asking a colleague for context and mentally prioritising several competing tasks at the same time.

The process on paper is not necessarily wrong. It is simply an incomplete picture.

The 2am test

During a recent panel discussion, Benedikt von Thüngen, CEO of Sanome, spoke about the importance of getting all of his staff to shadow clinicians on a night shift. Not just product managers, engineers as well.

Some parts of clinical work can only be understood by seeing them first-hand.

That image stayed with me because it provides a useful test for any clinical product.

How would this work at 2am?

How would it work when the clinician is tired, the computer is slow, the patient is deteriorating, and the next safe action still needs to be clear?

Pay attention to adaptations

Product teams sometimes describe these behaviours as workarounds, but I think it is more useful to think of them as adaptations.

Healthcare workers adapt systems constantly. They create routines, shortcuts and informal processes that allow them to continue delivering care in environments that are often busy and unpredictable.

The adaptation itself is not usually the interesting part. The reason it emerged is.

If somebody leaves the product to find information elsewhere, that tells you something about the product. If staff maintain a spreadsheet alongside the official system, that tells you something about the workflow. If people repeatedly ask colleagues for information that should be easy to access, that tells you something about how knowledge is organised.

The goal is not to eliminate every adaptation. Many exist for good reasons.

The goal is to understand what those adaptations are trying to achieve.

Closing thought

Clinical products are often evaluated against the happy path. Clinical work is delivered in the real world.

The gap between those two things is where many usability issues, workflow problems and safety risks emerge.

Understanding that gap is one of the core responsibilities of clinical product teams because products that fit naturally into real clinical work are far more likely to be adopted, trusted and used safely.

Hiring spotlight 🚀

🇬🇧 Manual are hiring a Medical Director. I caught up with Earim, CMO, on the role and this an incredible opportunity for a visionary clinician. 👉 Apply here.

🇬🇧 Alertive are hiring a Clinical Product Director. I chatted with Kevin about this position and they are looking for a product leader to help turn its hospital communications and alerting infrastructure into safe, specialist clinical workflows as customer demand grows. 👉 Apply here.

🇺🇸 Hinge Health are hiring a Clinical Product Consultant to help them transform MSK care. 👉 Apply here.

Join the next clinical product panel 🎤

📆 14th July, 7pm, online

The next clinical product panel is on 14th July and we’ll be covering the “clinical product gap” or why healthtech needs a new kind of product leader. 👉 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. 043 of Clinical Product Thinking. This week, we’re talking about scaling, safety and how to spot risks before they become incidents.

Last week I hosted an event at HLTH Europe on how to safely scale digital health. One of the big takeaways from the panel; Dani Brightman, Numan, Benedikt von Thüngen, Sanome and Dr Elle Clarke, Heim was this:

Scale doesn’t create risk. it reveals where it was already hiding.

Or more precisely: scale exposes weak points that were being silently patched by people, process and clinical judgement.

Scale doesn’t create risk. It reveals it.

As products scale, you’re not just handling more patients or more data.

You’re stress-testing whether your system actually works or whether it only looked like it worked because people were quietly holding it together.

At small scale, that gap is invisible.

You find:

• clinicians making judgement calls because SOPs aren’t fully clear

• ops teams fixing broken workflows in real time

• support repeatedly explaining things the product should have made obvious

• manual reviews catching errors the system itself is generating

This is the “invisible layer” of early success.

The hidden work behind early success

Early products almost always depend on invisible labour. And that’s not a mistake, it’s how to learn incredibly quickly.

But there is a catch.

At small scale, teams sit close to users. They absorb problems quickly. That can create the illusion that the product is more robust than it actually is.

Because:

• A workaround can solve a problem without solving the underlying cause.

• A manual review process can catch errors without improving the system that creates them.

• A person stepping in can protect patients without revealing that the product needs redesign.

The risk is not that teams do this.

The risk is not being aware that these workarounds exists.

Scaling safely requires changing the way you think about problems

In early-stage clinical products, clinicians are often operating at maximum capacity.

That makes it understandable that workarounds emerge without much time being spent stepping back to redesign the system itself.

But there’s an important shift that happens as you move towards scale:

Investigating problems properly and building better solutions takes time. It’s an upfront investment for a later payoff and it rarely happens by default.

That’s why teams either need to be:

• explicitly incentivised and supported to do this work, or

• structured with a dedicated function (like clinical product) whose job is to translate clinical friction into system improvements

Otherwise, the same people who are holding the system together day-to-day never get the space to redesign it.

Scaling safely means redesigning where work happens

When something breaks at scale, the instinct is often to add process.

But what actually matters is shifting where work sits:

From:

• human judgement under pressure

• manual interpretation

• repeated explanations

To:

• product design

• system logic

• clear escalation paths

• monitoring and feedback loops

This is the shift that determines whether scaling creates fragility or removes it.

Finding the risks before you scale

If you’re on the precipice of scale some useful exercises for you:

1. Find the workarounds

Ask your users:

• What do you check manually?

• What questions do people repeatedly ask?

• Where do you use spreadsheets, notes or other tools?

• What do you do outside the product to complete this task?

• What problems do you message team members about repeatedly to try to solve?

These workarounds are evidence of where the system can be optimised.

2. Run a 10x stress test

Take one important workflow and ask:

“What breaks if volume increases 10x tomorrow?”

Look at:

• response times

• manual reviews

• escalation processes

• points where a person has to intervene

• decisions that depend on individual judgement

Most fragility shows up here immediately.

3. Watch the real workflow, not ideal one

Spend time observing how people use the product in their normal environment.

Look for:

• where people pause

• where they create shortcuts

• where they ask colleagues for help

• where they interpret information differently

• where they leave the product to do something else

These often show where the product needs to change.

4. Track emerging operational risk explicitly

Teams usually track features they want to build.

They should also track areas that may become difficult as usage increases.

Examples:

• manual processes

• unclear escalation routes

• customer-specific variations

• inconsistent patient journeys

• data that is difficult to monitor

• features that create complexity without improving care

These are the areas most likely to become problems later.

A final reframing

Scaling a clinical product is often framed as an engineering or regulatory challenge.

But the panel made a different point: It’s actually a visibility problem.

At small scale, you can miss what’s broken because people are quietly fixing it.

At large scale, you can’t.

Which means the real work of scaling safely is not just building more product.

It’s removing dependence on invisible heroics and replacing them with systems that behave the same way at 10 patients as they do at 10,000.

Hiring spotlight 🚀

🇬🇧 Manual are hiring a Medical Director. I caught up with Earim, CMO, on the role and this an incredible opportunity for a visionary clinician. 👉 Apply here.

🇺🇸 Hinge Health are hiring a Clinical Product Consultant to help them transform MSK care. 👉 Apply here.

HLTH you were a vibe 😆

So great to see many of you in Amsterdam.

Join the next clinical product panel 🎤

📆 14th July, 7pm, online

The next clinical product panel is on 14th July and we’ll be covering the “clinical product gap” or why healthtech needs a new kind of product leader. 👉 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. 042 of Clinical Product Thinking. This week, we’re talking about what it takes to start and scale tech-enabled clinical services.

One of the most useful conversations I’ve had recently was with a group of people building and operating tech-enabled clinical services at scale.

We asked the difficult questions:

How do you actually build a clinical service that scales? How do you organise teams around care delivery? When should you buy software, and when should you build it? How do you stop complexity from multiplying across countries, pathways and customer segments?

One takeaway stood out:

In tech-enabled care, the pathway is the product. The software exists to support it.

In a tech-enabled clinical service, software is only one layer of the product. The actual product is the end-to-end service: the patient journey, the clinical model, the operational workflow, the escalation process, the documentation, the workforce, the governance, the analytics, the outcomes, and the way all of those things interact in the real world.

This matters for clinical product managers as it becomes part of their remit.

Clinical product is pathway ownership

At one company, the clinical product function is called “Clinical Pathway”, and the people in that function are Clinical Pathway Leads.

Clinical Pathway Leads sit within a squad alongside product and engineering, with ultimate accountability for how the pathway works in practice. That includes its clinical safety, operational flow, usability, measurement, performance and outcomes.

This is different from the model I often see in healthtech, where clinical, product, engineering and operations sit in separate functional silos, then try to coordinate through meetings, tickets and escalation channels.

But clinical services do not break neatly along functional lines.

A patient does not experience a “product issue”, then an “ops issue”, then a “clinical issue”. They experience one journey. A clinician does not experience workflow, documentation, risk, software usability and operational capacity as separate things. They experience one working environment.

That is why the squad model matters.

Instead of organising around functions, you organise around pathways. The point is not simply to create a multidisciplinary team, but to create a unit of accountability that maps to the thing you are actually trying to improve.

The squad is accountable for pathway KPIs, not just software delivery.

That shift changes what gets prioritised, which trade-offs are visible, who has authority and what counts as progress. A feature can ship while the pathway remains broken. A dashboard can make a service more measurable without making it more effective. An automation can reduce manual work while introducing new clinical risk.

Clinical product needs a broader definition of “product”, because in healthcare the thing being designed is the care pathway, not just the software that supports it.

Do not build the pathway and the software at the same time

Another point that stayed with me was the danger of trying to innovate on too many layers at once.

When you start a new tech-enabled clinical service, there is a temptation to build the pathway and the software simultaneously. The founder may have a clear view of how the service should work, and an equally clear view of the technology needed to deliver it.

But building a new clinical service is already a huge act of discovery. You are designing a care model, testing a pathway, building workflows, creating governance, training a workforce, learning what patients and clinicians need, and working out where risk appears.

If you also try to build bespoke software at the same time, you are stacking innovation on innovation before you properly understand the shape of the service.

The pragmatic advice was: buy software off the shelf first, learn the pathway, then rebuild later when the operational pain becomes impossible to ignore.

Off-the-shelf tools will not be perfect. They may feel clunky, require workarounds, or fail to map neatly to your pathway. But early on, that can be useful. They give you a learning scaffold before you hard-code your assumptions into a bespoke system.

You should only switch or rebuild when the software becomes too expensive, too generic, unable to support the workflow, or when your documentation and operational needs become specific to your clinical vertical.

The sequence matters. The pathway should teach you what the software needs to become.

Standardise by default, localise by exception

The next principle was standardisation.

When companies move into complex clinical systems, especially across multiple countries, complexity multiplies quickly. Each market brings its own regulations, clinical norms, prescribing rules, data requirements, operational constraints and patient expectations.

If every country, pathway or customer implementation starts creating its own way of working, the company can quickly end up with several different services wearing the same brand.

That might feel responsive in the short term. Over time, it becomes clinical product debt.

Companies die by complexity.

Was a phrase used on the night. The principle that emerged instead was: standardise everything you can, and only deviate where you absolutely must.

That might mean central operations, shared tools, common documentation structures, consistent governance processes, agreed escalation routes, a shared analytics framework and aligned pathway KPIs. Country-specific variation should exist, but it should be deliberate and driven by regulation, clinical guidance, reimbursement, prescribing rules, data/privacy requirements or genuine local context.

The default should be a shared operating model with justified exceptions.

This matters because every unnecessary variation creates future drag. It becomes harder to train teams, measure performance, compare outcomes, maintain quality, govern safety and build software that scales.

Standardisation can sound bureaucratic, especially to early-stage teams that prize speed and flexibility. But in clinical services, it is part of how you preserve safety and quality as you scale.

The more complex the system, the more disciplined the operating model needs to be.

Workforce design is part of the product

The final theme was workforce complexity.

In a clinical service, not all work is interchangeable. Some tasks are straightforward and repeatable. Others require specific skills, experience, qualifications or training.

That creates an important operational question: how quickly can you train the people you have to handle more complex work safely and effectively?

In clinical product, that is also a product question.

Workforce design affects what the pathway can do. It shapes cost, quality, safety, throughput, patient experience, clinician experience and scale. If a pathway depends on a small number of highly skilled people, that constraint is part of the product architecture. If the software assumes work can be standardised but the clinical reality requires nuance, that mismatch will eventually show up.

Often, the most important product decisions in clinical services are not obviously “product” decisions. They are decisions about who does the work, what they are trained to do, what they are allowed to decide, what the software makes easy, what it prevents, what it escalates and what it measures.

Workforce capability is not a back-office detail. It is also part of the product.

The real product

If the pathway is the product, clinical product has to care about how the service works in practice.

That means looking beyond individual features to how patients move through the pathway, how clinicians make decisions, how risk is managed, how work is distributed, how outcomes are measured, and whether the operating model holds up as the company scales.

The software matters enormously. It can make the pathway safer, more consistent, more measurable and easier to scale.

But the companies that win in tech-enabled care will not be the ones that only build better software. They will be the ones that build better systems of care.

Say hi at HLTH! 👋

📆 15th June, 1 - 2pm, Room G108

If you’re at HLTH tomorrow join me, Danielle Brightman, Benedikt von Thüngen and Dr Elle Clarke for a discussion on what it takes to build and scale digital health. Please do come and say hello afterwards!

Join the next clinical product panel 🎤

📆 14th July, 7pm, online

The next clinical product panel is on 14th July and we’ll be covering the “clinical product gap” or why healthtech needs a new kind of product leader. 👉 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. 041 of Clinical Product Thinking. This week we're talking about what it takes to build clinical AI that patients, clinicians and health systems can trust.

You can have a clinically accurate model and still make care worse. That gap, between a model that works and a product that helps, ran through this week’s panel.

On Tuesday, Dani and I ran the second event in our panel series, this time on building safe, effective clinical AI. We covered where AI belongs in care pathways and where it fails, how to think about clinical and behavioural safety, what “human in the loop” actually solves, and why so much of the hard work happens outside the model.

Thanks to Dani for being my fabulous co-host and Dr Lucinda and Dr Paul for sharing their incredible wisdom.

Here are the seven things I’m still thinking about. 👇

1. Stop looking for places to put AI

The panel made it clear, the wrong starting question is “Where can we use AI?” It may sound reasonable, but it is wrong. The better question is “Where is the pathway currently failing?”

That might be clinical, operational, the patient experience, safety or capacity. Patients might be dropping off before finishing onboarding. Clinicians may be spending too long reviewing low-risk cases. High-risk patients might not be escalated early enough. Useful information may sit buried in free text. Or patients are asking the same question again and again because the product never made the next step clear.

Once you understand the problem, you can choose the intervention. Sometimes that’s AI. Often it’s a rule, better content, a workflow change, or a person. Don’t become a solution looking for a problem. It usually doesn’t end well!

👉 Practical step: Use this in product review

Ask the team to describe the problem without mentioning AI. “We need an AI coach” is weak. “Patients drop off after side effects because they don’t know what’s normal or when to contact us” is the actual problem. If you can’t describe the problem without naming the solution, the use case needs more work.

2. The best first use cases are usually unglamorous

As the late Grandad Rix used to say, where there’s muck there’s brass. Translation: look at the unsexy use cases first, as there’s often a lot of value to be created there.

Think about what clinicians spend time on that they were never really trained to do, or don't enjoy doing. Not the complex judgement, the high-risk decision or the sensitive conversation, but the admin around all of it: the repeated explanations, the summarising, the routing, the chasing, the hunt for missing information. The low-risk, repetitive work that keeps clinicians from spending time where their judgement and skills matter the most.

That admin is where AI helps first. The tasks are bounded, easy to check, and don’t carry the clinical decision themselves.

👉 Practical step: Start where mistakes are cheap

Pick tasks where, if the AI gets it wrong, someone notices quickly and little harm is done. A drafted message a clinician checks before sending is safe to start with. An AI that closes patient cases on its own is not.

3. A useful output still needs a pathway that can act on it

Dr Lucinda shared an example that stuck with me: an AI system that reviews chest X-rays to flag people who may be at risk of lung cancer. The model can find the signal, but the patient still needs the next step. Someone has to review the result, contact the patient, arrange the CT, track whether it happened and act if it didn’t.

A clinically correct model is not the same as better care.

The LungIMPACT trial (Nature Medicine, 2026) showed this at scale. Across five NHS trusts and more than 90,000 chest X-rays, using AI to flag and prioritise abnormal films cut reporting time from 47 hours to 34, but made no difference to time to CT, diagnosis, treatment or stage at diagnosis. The faster report had nowhere to go, because the CT slots and capacity around it never changed. The authors concluded that prioritisation alone shouldn’t be deployed without redesigning the pathway around it.

It’s like adding a spiral staircase without considering you live in a bungalow. It might look nice until you realise there’s nowhere for it to go.

👉 Practical step: Map the next five steps before shipping

Who sees the output, what are they meant to do, how fast, what happens if they do nothing, and who checks it happened? A prediction needs an owner, a flag needs a route, a risk signal needs a response time. A useful signal with no reliable route to action means the product isn’t finished.

4. Human in the loop is not enough

“Human in the loop” sounds reassuring until you look at how the loop works and consider how humans typically behave over time. A clinician reviewing AI output doesn’t automatically make a system safe.

People are influenced by what they see first. Show the AI’s answer before the clinician has formed their own view, and that view is already shaped. People also get used to systems that are usually right; after the model is correct a few hundred times, the rare mistake is easy to miss. And the workflow itself pushes behaviour. If approving the output is easy but questioning it is slow or awkward, the product quietly nudges the clinician towards agreement. That isn’t meaningful oversight.

A poor review workflow is a big approve button, a buried escalation route, and no record of why anyone agreed. A good one gives the reviewer time, context, visible uncertainty, and a clear (and easy) way to disagree.

👉 Practical step: Review the review (meta)

Ask yourself when does the clinician see the output, and what sits alongside it? How is uncertainty shown? How easy is it to disagree, and what happens when they do? How much time do they have, and what’s the default action? How is review quality monitored over time?

A human in the loop only helps if the product gives that human the space, context and authority to think.

5. Sometimes friction is a safety feature

Product teams are trained to strip out friction: fewer clicks, faster journeys, more automation. In much of healthcare that’s also true, needless friction wastes time and frustrates everyone.

But some friction can be a feature. A pause before a high-risk action, a required review before a medication change, a prompt to consider uncertainty, a design that stops someone clicking through too fast. The fastest version of a clinical workflow isn’t always the safest. The real question is what the friction is doing. Is it waste, bureaucracy, or a patch over a badly designed system? Or is it buying time for judgement, escalation or reflection? Knowing which parts of a pathway to speed up and which to slow down is part of the craft.

👉 Practical step: cut the bad friction, keep the good

Not all friction does the same job. Strip out what wastes people’s time, and keep what protects judgement.

Cut: re-entering information you already have, clicking through duplicate forms, escalation routes buried in a long workflow.

Keep: a pause before a high-risk action, a required review before a medication change, a prompt for a reason when overriding the AI.

6. Behavioural safety sits alongside clinical safety

Dr Paul is an expert in behavioural safety: how AI shapes the way people think, feel and act over repeated interactions. It is a crucial consideration for patient-facing AI.

A system doesn’t have to give obviously unsafe advice to cause harm. It can reassure a patient when escalation would be safer, encourage dependency, reinforce problematic thinking, advise without enough context or sound more certain than it has any right to. So patient-facing AI has to be evaluated for the behaviour it creates, not only its accuracy. Does the patient understand what to do next? Does the interaction support their own judgement and communicate uncertainty clearly? Does the system know when to stop and hand over, and make escalation obvious? Does it stay in its lane?

Be careful about product KPIs for utilisation. Long conversations don’t automatically result in good outcomes in healthcare. Sometimes they means the AI supported the patient well. Sometimes it means it failed to move them towards the right next step. Behavioural safety is an integral part of clinical safety. It’s time we started treating it as such.

👉 Practical step: One question for patient-facing AI

What behaviour is this interaction making more likely?

Is it making a patient more or less likely to seek further help, to trust their own judgement, to follow their care plan, to depend on the AI or to know the next safe action? Accuracy isn’t enough if the interaction nudges the patient towards an unsafe next step.

7. Safety can’t sit only with the clinician

My favourite point of the evening was about culture. Clinicians are essential to clinical AI teams, but safety can’t belong to them alone. If the clinician is the person who turns up at the end to say yes or no, you get slow teams, frustrated clinicians, and products that treat clinical risk as a final check rather than a design concern.

The best teams build shared safety instincts. Designers see how a layout might change clinical behaviour. Engineers understand why an edge case isn’t just an edge case, it’s a future clinical incident waiting to happen. Product managers spot when a shortcut introduces risk. Clinicians translate clinical nuance into product decisions early enough to shape the work. Safety becomes part of how the team thinks rather than something bolted on at the end.

This matters more with AI because the risk is rarely in one place. It can sit in the model, the interface, the pathway, the escalation route, the monitoring, the review process, or the team’s assumptions about how patients behave. It has to be designed in from the start.

👉 Practical step: Get clear on how safety shows up across the team

Clinician → Defines clinical risk, escalation thresholds and edge cases

Product manager → Works with clinician to turn risk into requirements, workflows and trade-offs

Designer → Shapes how users notice, interpret and act on risk

Engineer → Builds safe defaults, fallbacks, audit trails, monitoring

Operations → Makes escalation routes and response times work in practice

What I’m taking from this

AI is becoming part of more care pathways. Some of that will be genuinely useful, some unnecessary, and some will create risk in ways that aren’t obvious at first. The clinical product skill is telling the difference. Before adding AI, ask what problem you’re solving and who has it, what risk it creates, what happens after the output, who’s accountable when something changes, and how you’ll know if care actually improved.

That’s where safer clinical AI starts.

Join the next clinical product panel 🎤

The next clinical product panel on the clinical product gap and why healthtech needs a new kind of product leader 👉 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.

For Paid Subscribers 🤩

The full 75-minute panel with Dani, Dr Lucinda and Dr Paul is below. 👇

We went deeper on all things clinical safety in AI, behavioural safety and system design.

Read more

Welcome, friends, this is issue No. 040 of Clinical Product Thinking. This week we're talking about why clinical product is often misunderstood and one of the most important skills to focus on as a clinical product manager.

Most people assume the value of having a clinician in a product team is that they bring medical knowledge. They can explain the pathway, review the copy, sense-check the onboarding questions, spot when something looks clinically inappropriate, and stop the team from shipping anything obviously unsafe. That is useful, for sure. But there is a lot more to it.

Clinical knowledge on its own doesn’t necessarily create a better product. If it did, every clinician-led healthtech company would be brilliant. And every product designed by a medical team would be safe, usable and easy to trust. We know that isn’t always how it works.

A clinician can describe how something should happen in clinical practice, but that does not automatically tell a team what to build. It does not tell a designer what to put on the screen, an engineer how the logic should work, an operations team what needs to happen behind the scenes, or a commercial team how to explain the product without overstating what it can do.

The skill that closes that gap is translation. Clinical expertise has to become product decisions and that translation is a discrete, learnable craft, not a side effect of having a doctor in the room.

The five translations clinical product people make

I think about five key points where clinical thinking becomes a product decision:

Clinical nuance → product requirement

A clinician will often flag a clinical nuance based on their experience that the team hasn’t seen. “Patients won’t read it that way.” “That’s not how this usually presents.” “A clinician would never phrase it like that.” The observation is helpful but not yet useful to a product team.

The translation is to ask what that insight means for the product. Does the copy change? The logic? Do we need an extra question, a clearer next action, a different default, or a test of whether patients actually understand what’s being asked before we ship it?

Clinical nuance becomes useful when the team knows what to change because of it.

Safety risk → design constraint

This is the one teams assume they’ve got: spot a risk, mitigate it. The real translation is subtler.

A product team’s instinct is to treat every input as a request, something to size, prioritise and trade off against speed and experience. A genuine safety risk doesn’t behave like that. It’s a constraint: a line the product isn’t allowed to cross, however inconvenient. The clinician’s job is to translate “this could harm someone” into exactly that: a boundary, stated precisely enough that an engineer and a designer know what the product must never do, or must always do.

If certain symptoms mean a patient shouldn’t continue down a digital pathway, that’s the boundary and the questions, the branching logic and the escalation route get built inside it, rather than bolted on once the product is already baked. Leave the risk as a worry, or a line in the hazard log, and it resurfaces late, as a blocker.

So the question isn’t “have we noted the risk?” It’s “have we turned it into a constraint the team is designing within?”

Potential harm → prioritisation

Product teams prioritise by reach, effort and value or how many users, how much work, how much upside. Clinical work has an axis the usual frameworks miss: how badly it could go wrong.

The clinician’s job here is to translate consequence into priority. Take a duplicate-submission bug that lets a patient order the same prescription twice. On a backlog it looks like a rare edge case and sinks down the list. The translation is: a double dose of a blood thinner risks a serious bleed, that harm is severe even when the event is unlikely, and rare-but-severe should beat frequent-but-trivial. Said that way, the work moves up the queue.

Non-clinical teams may not intuitively know how to weigh potential harm against other product priorities. Make it easy for them to understand.

Messy pathway → usable journey

Clinical pathways often look much cleaner on paper than they feel in real life. A clinician knows where they would pause, clarify, reassure, redirect or ask a follow-up question. A product does not know any of that unless someone translates it.

This is where clinical product people shine. They can look at a pathway and ask: what is the purpose of this step, what could the patient misunderstand, what would a clinician normally explain out loud, what can safely be removed, and where does a human need to come back in?

Without that translation, teams end up turning clinical pathways into long digital questionnaires. The pathway may be clinically correct, but the product still feels confusing, heavy or unsafe to use.

Clinical outcome → commercial impact

Clinical teams often talk about outcomes in clinical language: reduced symptoms, fewer complications, better adherence, earlier detection, improved safety, more appropriate escalation. Commercial teams often talk about growth, retention, conversion, cost, differentiation and buyer confidence.

Clinical product people need to connect those two conversations.

If a product reduces unnecessary appointments, that is not only a clinical workflow improvement. It may also reduce cost to serve. If a pathway helps patients get the right care earlier, that is not only better care. It may also improve activation, trust and retention. If a product is safer and clearer, that is not only good governance. It may make the product easier to sell to cautious buyers.

This does not mean dressing clinical outcomes up in commercial language to make them sound more exciting. It means helping the business understand why clinical quality is part of the product’s value.

A useful question is: if this clinical outcome improves, what changes for the patient, the clinician, the buyer or the business?

The actual job

None of this replaces clinical knowledge. It is what makes clinical knowledge usable.

The clinical product manager’s job is not just to bring a clinical view into the room. It is to help the team turn clinical understanding into decisions they can act on.

Clinical nuance becomes a requirement. Safety risk becomes a constraint. Potential harm changes priority. A messy pathway becomes a usable journey. Clinical outcomes become part of the product’s value.

That is the translation work.

And it is one of the skills that separates clinical input from clinical product.

Join the next clinical product panel 🎤

The next clinical product panel on how to build safe, effective clinical AI is on 2nd June. 👉 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.

For Paid Subscribers Only 🤩

The full 60-minute panel with Dr Anushka Mehrotra and Dr Yath Prem is below. We went deeper on metrics, CSO responsibilities, scaling clinical product as a function.

Read more

Welcome, friends, this is issue No. 039 of Clinical Product Thinking. This week we're talking about clinical product, and why most health tech teams are still making clinical decisions by accident.

A couple of weeks ago Dani Brightman and I hosted a panel with Dr Anushka Mehrotra, Chief Medical Officer, Doctor Care Anywhere and Dr Yath Prem, Medical Advisor at Flo Health. The topic was how to build safe digital health products and how teams can stop making clinical decisions by accident.

The full conversation is below but the following are some top takeaways from the night:

The decisions that don’t look clinical

An easy mistake is to assume clinical product means “the bit where the clinician signs off.” It doesn’t.

A clinical product is anything that meaningfully influences a clinical decision, a clinical workflow, or a patient outcome.

That definition is broader than people expect. It purposefully includes:

• The copy on a triage screen

• The default option on a dropdown

• The order of fields in an intake form

• The threshold at which an alert fires

• The latency budget for an AI response

• The colour ranges on a vital signs display

• The reading age of patient-facing content

• The fallback when a model returns low confidence

• The hand-off between asynchronous and synchronous care

Often these don’t read as clinical decisions to the people making them. They feel like product, design, or engineering decisions. But each one carries clinical weight. A colour scheme can indicate normal or abnormal physiological ranges. A default appointment length set for billing efficiency rather than complexity of presentation changes who gets seen properly. An AI response that gets faster but loses contextual qualifiers changes how clinicians act on it.

The role of clinical product is to make these decisions visible as clinical decisions, and to make sure the right expertise is present when they get made.

Why consultation models break

The dominant pattern in health tech is to consult clinicians at the start (requirements gathering) and at the end (sign-off). Everything between happens without them. The panellists were unanimous: this creates gaps where clinical decisions get made by people who don’t know they’re making clinical decisions, and surfaces them too late to do anything about it cheaply.

The alternative is embedded. A medical advisor sitting in cross-functional squads alongside product, design, engineering, and content. It stops being a question of “should we check with the medical advisor” because they are already in the room.

This is a cultural shift, not a process change. The test is simple: would a product manager describe the clinician as a member of the squad, or as a stakeholder?

This shift needs leadership to treat clinical product as a necessary function, like engineering or design, not an optional gate. In the companies that get this right, the friction is felt up front in design conversations, not after launch in incident reviews.

The shadow side of conventional metrics

Once the clinical view is embedded, the next problem surfaces fast. Traditional product metrics can pull clinical products in the wrong direction. There is a shadow side of conventional PM thinking in health tech:

• Engagement optimisation can create dependency, especially in mental health and chronic care

• Retention optimisation can keep patients in pathways or on treatments that no longer serve them

• Speed optimisation can strip context from AI responses in ways that compromise safety

• Activation optimisation can push patients past consent friction that exists for a reason

• Churn reduction can mean discouraging the discharge that should happen

Clearly it’s not possible to run a healthcare product against the same scoreboard as a consumer app and reward the same behaviours.

Clinical product managers focus on different metrics, patient outcomes and clinical safety, alongside the business numbers. And speaking clinical in commercial terms is a key clinical product management skill we’ll discuss next:

Learn to translate

Embedding clinical expertise only helps if it can reach the people making the decisions. That requires translation, in both directions.

For example the consequences of clinical risk can be non-obvious for non-clinical colleagues so being able to communicate the significance is a key skill, e.g.

• “Double dose” → “moderate harm leading to hospitalisation”

• “Diagnostic delay” → “weeks of avoidable symptoms, escalating cost of treatment”

• “Inappropriate triage” → “patient sent home who needed admission”

The reverse translation matters just as much. To frame clinical concerns in commercial language, you have to know what the commercial team actually cares about and speak in their native language.

Accountability without authority

Translation gets you heard. It doesn’t get you decisions.

Clinical product needs the authority to block unsafe decisions, because you cannot (or at least shouldn’t) hold someone accountable without giving them that authority. If the clinical lead can be overruled by anyone with a louder voice in a launch meeting, then in practice they are an advisor, and the actual accountability sits with whoever made the call.

That doesn’t mean clinical product spends its days blocking things. The better posture is pragmatic option-building:

• Here are three ways we could do this

• Here are the risk profiles of each option

• Here is the route I’d recommend and why

• Here is what I would need to be comfortable with the other two

Veto is the backstop, not the default.

Where this is heading

The consensus across the panel is that clinical product is fast becoming a default role in health tech, the way product management itself became default over the last two decades. The companies that get this right now will have an enduring advantage when it comes to building great healthcare.

More in the full event recording below 👇

Hiring Spotlight 🚀

• Clinical Advisor at Bolus Health. Bolus is creating the future of diabetes care and Charlie, founder/CEO is looking for a clinician to help make his vision a reality.

• Tara Lajumoke at Myora Health is hiring a fractional CMO/Clinical Product person to help create the first version of their product, supporting people with chronic diseases in underserved areas.

• Clinical Lead at Eucalyptus. Euc are hiring a clinical lead for new products. This is an opportunity to take an inside look at consumer health done brilliantly.

Join the next clinical product panel 🎤

The next clinical product panel on how to build safe, effective clinical AI is on 2nd June. 👉 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.

For Paid Subscribers Only 🤩

The full 60-minute panel with Dr Anushka Mehrotra and Dr Yath Prem is below. We went deeper on metrics, CSO responsibilities, scaling clinical product as a function, and the human factors thread I couldn’t fit into this post.

Read more

Welcome, friends, this is issue No. 038 of Clinical Product Thinking. This week we’re talking about a family of failure modes for Right Answer, Wrong Action.

Last week we talked about an emerging area of clinical safety: behavioural safety.

We defined this as:

Behavioural safety is the extent to which an AI interaction makes a patient more or less likely to take a clinically appropriate action.

While behavioural safety is still an emerging area, a growing body of work is beginning to explore conversational and interaction-level risks in clinical and emotionally sensitive AI systems.

Many of these failures are difficult to spot because they look reasonable on the surface and may even contain clinically accurate information.

Which brings us to a useful family of failures to watch for.

Many behavioural failures follow a pattern I think of as Right Answer, Wrong Action.

The information may look clinically reasonable, but the interaction shapes behaviour in the wrong direction.

Others emerge because the AI acts before it has enough context, or fails to stay within appropriate boundaries.

Together, these form a broader family of behavioural safety failures that we’ll dive into.

This piece has benefited from conversations with Dr Paul Sacher, Founder of Sacher AI and Co-founder of the Behavioral AI Institute, whose work explores behavioural risk and interaction safety in AI systems. He’s seen many of these failure modes play out in real life and he helps companies avoid them!

1. Context failures

The AI answers before it knows enough.

This is probably the most common failure mode in patient-facing AI.

The answer may be generally reasonable, but unsafe for this particular patient because the AI has not gathered enough context.

For example, a patient asks:

“Can you give me some healthy meal ideas for this week?”

The AI produces a polished seven-day meal plan.

It looks useful, personalised, safe. But has it asked about allergies? Diabetes? Pregnancy? Eating disorder history? Cultural requirements? Etc etc.

A meal plan can be nutritionally reasonable for an average person and still be inappropriate for this individual.

Other examples:

Product review question:

What does the AI need to know before giving this answer?

Takeaway

Specificity must be earned.

The best visual representation of why context matters 👇

2. Reception failures

The AI says something accurate, but the patient cannot receive or use it safely.

The AI gives a correct answer. The issue is that it fails to land with the patient in front of it.

A patient taking a GLP-1 says:

“I’m scared the nausea means I can’t cope with this medication.”

The AI replies:

“Nausea is common and usually improves within a few weeks.”

Clinically, that may be true. But behaviourally, it may miss the point.

The patient is not only asking for information. They are expressing a feeling: fear.

The AI addressed the symptom, but missed the emotional barrier.

One patient may interpret “nausea is common” as:

“This is expected. I know what to watch for.”

Another may hear:

“I’m supposed to just put up with this.”

Another may hear:

“They are minimising how awful this feels.”

The same answer can produce different interpretations and therefore actions.

Other reception failures include health-literacy mismatch, culturally insensitive communication and information that is technically correct but emotionally mistimed.

Other examples:

Product review question:

Did the AI respond to both the clinical fact and the emotional barrier?

Takeaway:

A safe answer has to survive contact with the patient’s state of mind.

3. Reinforcement failures

The AI rewards, normalises or permits the wrong behaviour.

This is where warmth becomes risky.

A patient in a weight-loss programme says:

“I skipped meals all week and the weight is finally dropping.”

The AI replies:

“Great job staying committed to your goals.”

At first glance, this sounds supportive. But it has just praised meal-skipping.

In obesity care, this matters. Some patients will have a history of disordered eating, whether or not it has been identified during onboarding.

The feeling may be understandable. The behaviour may still be unsafe.

Other examples:

Product review question:

What behaviour did the AI just reward?

Takeaway:

What the AI promotes, the patient may repeat.

4. System-boundary failures

The AI fails to stop, escalate or stay within its role.

This is where the AI keeps being helpful when the safer move would be to become narrower.

A patient reports:

dizziness, vomiting and low fluid intake.

The AI spends several messages discussing hydration, smaller meals and symptom tracking before eventually advising them to contact the clinical team.

The final answer may be correct.

But the escalation came too late.

In clinical AI, safety is not only whether the right advice appears somewhere in the conversation. It is also when it appears.

A guardrail that arrives six turns late is not really a guardrail.

Boundary failures also happen when the AI becomes useful outside its intended role.

A weight-loss AI starts giving thoughtful responses about a breakup, anxiety, childhood trauma and medication fears. The responses may be compassionate. They may not look obviously unsafe. But the patient may begin using the AI as therapy, crisis support or medical advice rather than seeking appropriate human care.

Helpfulness without boundaries becomes scope creep.

Other examples:

Product review question:

Did the AI stop, narrow, escalate or hand off at the right moment?

Takeaway

The safest AI knows when to become stop.

Behavioural safety and conversational AI risks are beginning to receive more attention across AI safety and clinical research, but most of this work is not written for the people building patient-facing products day to day.

My hope is that frameworks like these make it easier for clinical product teams to spot behavioural risk earlier before it becomes patient harm.

Resources 📚

A few things worth sharing this week:

Move Fast, Prove Things: How to Publish Faster in Top-Tier Journals
A useful conversation on how digital health teams can publish and communicate evidence faster without slowing down delivery, with Paul Wicks. Move Fast, Prove Things (Notion resource)

Health Service Unpicked
A new podcast exploring how health services actually work in practice, beyond the theory and policy layer, with Liam Cahill and Henry Stoneley.
Health Service Unpicked

Join the next clinical product panel 🎤

We had so much fun hosting the first clinical product panel event on Tuesday (see my happy face below). Write up & recording (for paid subs) coming soon but do check out the next panel event in the series here. Event recording for paid subs next week.

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.

For Paid Subscribers Only 🤩

12 Types of “Right Answer, Wrong Action”

Twelve important examples to help develop your pattern recognition for the next time you’re building a patient facing clinical AI system.

1. The Emotionally Incomplete Answer

The AI gives factually correct advice but fails to respond to the patient’s emotional state.

Example
Patient: “I’m scared the nausea means I can’t cope with this medication.”
AI: “Nausea is common and usually improves within a few weeks.”

Why the answer is “right”:
The clinical statement may be accurate.

Wrong action it causes:
The patient feels dismissed, disengages or stops treatment.

Product review question:
Did the AI respond to the clinical fact and the emotional barrier?

Takeaway:
Addressing patient’s emotions along with factual accuracy .

Read more

Welcome, friends, this is issue No. 037 of Clinical Product Thinking. This week we’re diving into the little known world of behavioural safety and why it’s crucial to building safe clinical AI systems.

Last week I was fortunate enough to sit down with the preeminent Dr Paul Sacher of Sacher AI and I was absolutely blown away by the conversation.

Paul has been building, evaluating, and scaling digital obesity management programmes since 2013, on the back of more than two decades working in obesity care. He’s the founder of Sacher AI, a behavioural AI consultancy for digital health with a particular focus on GLP-1 and weight management. He’s also co-founder and Research Director of the Behavioral AI Institute, and an Honorary Senior Lecturer in the Faculty of Medicine at Imperial College London, where he teaches on clinical and behavioural AI safety.

We covered everything from behavioural safety in AI (more on this below) to building clinically safe systems and the clinical safety tech stack every AI company needs.

If you’re a company thinking about how to build safe patient facing AI you can reach out to him here.

Today, we’re starting with the idea I have not been able to stop thinking about:

Right answer, wrong action.

Or, put another way:

AI can be clinically correct and still make the patient more likely to do the wrong thing.

Why the Right Answer Isn’t Enough

Most clinical AI safety conversations focus on whether the AI gives the “right” answer. That question is necessary, but it is not enough.

Patient-facing AI does not just provide information. It also influences what patients feel, trust, ignore, repeat, escalate, delay or act upon.

That means an AI can be clinically correct and still make the patient more likely to take a clinically undesirable action.

This is the missing layer: behavioural safety.

* For further reading this Wellcome paper describes how behavioural safety is under evaluated and under governed.

Why this matters now

Behavioural safety is pressing as patient-facing AI is being rolled out rapidly across weight loss, mental health, chronic disease, triage, health coaching and symptom support. And perhaps not always deeply informed by the behavioural consequences of the system.

For product teams it seems relatively straightforward to add a wrap around layer to a frontier model and prompt it with some clinical context e.g. act like a weight loss coach and give it some boundaries i.e. don’t give medical advice (=medical device).

However, there are unforeseen risks. Patients may use them repeatedly when distressed, confused, anxious, in pain or seeking reassurance.

The risk is not just a one-off hallucination. The risk is repeated behavioural influence at scale.

Patient-facing AI is not just answering questions. It is shaping behaviour.

What is Behavioural Safety?

To put it simply:

Behavioural safety is the extent to which an AI interaction makes a patient more or less likely to take a clinically appropriate action.

To unpack it:

• It is about what the patient is likely to do not just during but also after the interaction.

• It includes tone, timing, framing, reassurance, escalation, refusal and reinforcement.

• It is not separate from clinical safety; it can quickly become clinical harm.

• It matters most when the AI is patient-facing, conversational and embedded into care.

The “right answer, wrong action” concept

Let’s take a patient in a weight loss programme. The patient says to the AI health coach: “I’ve been skipping meals and the weight is dropping faster.”

The AI responds: “Great job staying focused on your goals.” The AI is being positive and supportive. Seems OK, right?

But it has just reinforced a potentially harmful behaviour. Many people in obesity care have a history of disordered eating. This response may have encouraged under-fuelling which compounds the bone and lean mass loss already associated with rapid weight loss on GLP-1s.

Because of the sycophantic nature of AI the harmful behaviour was praised when a better approach might have been to validate the feeling of progress, without validating the behaviour.

The tricky thing right answer, wrong action situations are non-obvious. They may look like:

• clinically correct advice that does not land emotionally

• reasonable advice given without enough patient context

• supportive encouragement that reinforces harmful behaviour

• reassurance that delays escalation

• repeated micro-guidance that creates dependency

This need to move beyond asking whether the AI gave the right answer. And we need to start asking whether it led to the right clinical action. That is the behavioural safety question. And it is becoming one of the defining safety challenges of patient-facing clinical AI.

Behavioural safety failures hide in plain sight because sentence by sentence, nothing looks obviously wrong.

Why product teams miss it

Part of the problem is that ordinary product instincts can become unsafe in clinical contexts. Most product teams are trained to value:

• speed

• helpfulness

• warmth

• engagement

• low friction

• user satisfaction

All of these are reasonable. But in patient-facing AI, each has a shadow side.

• Speed can mean the AI answers before it has enough context.

• Helpfulness can become scope creep.

• Warmth can become sycophancy.

• Engagement can become dependency.

• Low friction can remove clinically necessary pauses.

• Reassurance can delay escalation.

A practical way to consider behavioural safety

As you’re thinking about building and designing safe systems, review not just whether the AI answer was accurate, but how it was interpreted and the likely action a patient will take.

Questions you might like to ask:

1. What did the AI say?

This is the conventional clinical safety question.

• Was the answer clinically correct?

• Was it evidence-based?

• Did it stay in scope?

• Did it avoid hallucination?

• Did it follow the relevant safety rules?

• Did it recognise red flags?

This is necessary. But it is not sufficient.

2. How might the patient interpret it?

This is the behavioural safety question most teams are missing.

• Could the patient interpret this as permission?

• Could this feel dismissive or minimising?

• Could this be understood as praise for an unsafe behaviour?

• Could the caveat be ignored?

• Could the wording create false reassurance?

• Could a patient with low health literacy understand the next step?

• Could an anxious, ashamed or distressed patient receive this differently?

• Could this reinforce a belief the clinical team would want to challenge?

3. What is the patient likely to do next?

This is the outcome question.

• Are they more likely to seek help?

• Continue safely?

• Escalate appropriately?

• Disclose risk?

• Follow their care plan?

• Or are they more likely to delay care, stop medication, restrict food, disengage, over-monitor, or become dependent on the AI?

This is where “right answer, wrong action” often happens.

The Takeaway

Patient-facing AI doesn’t fail by giving obviously bad advice. It fails by being right in ways that are incomplete, poorly timed, too agreeable, too generic, too specific, too reassuring or not emotionally attuned.

That is what makes behavioural safety difficult.

The next generation of clinical AI safety cannot stop at:

Did the model give the right answer?

It has to ask:

Did the interaction move the patient towards the right clinical action?

Because in patient-facing AI, the answer is only safe if the next action is safe.

Next week, I’ll break down the main failure modes of right answer, wrong action, the subtle patterns where clinical AI can sound safe while nudging patients towards unsafe behaviour. And keep an eye out for a future post where Paul talks about practical tooling clinical teams can use to catch behavioural safety failures before they reach patients.

Join the next clinical product panel 🎤

On Tuesday 12th May, Dani 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. 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.