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.

Subscribe now

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

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

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

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

I asked them all one simple question:

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

Together they point to a larger picture:

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

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

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

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

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

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

1. Regulation vs innovation (the dominant tension)

This is the single most consistent theme.

CPMs are struggling with:

• Balancing regulatory compliance with speed and experimentation

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

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

This shows up as:

• ‘Regulation vs innovation’

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

• ‘Engineering approaches to facilitate regulation’

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

2. Influence without authority

A close second.

Many CPMs describe difficulty:

• Getting buy-in from engineering, commercial or leadership

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

• Being listened to without being perceived as the blocker

• Operating in ambiguous roles where decision rights are unclear

This includes:

• ‘Communicating clinical needs to other stakeholders’

• ‘Influencing roadmap decisions’

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

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

3. Translating clinical reality into product systems

Another strong theme.

CPMs struggle with:

• Turning messy, contextual clinical practice into clean product logic

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

• Avoiding over-simplification without building unusable complexity

• Making products safe and usable in the real world

This often shows up as:

• ‘Product touches many clinicians’

• ‘How to represent clinical nuance in software’

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

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

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

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

Challenges include:

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

• Unclear ownership between product, clinical and governance teams

• Difficulty embedding safety thinking into agile development

• Friction between delivery timelines and safety assurance processes

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

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

A quieter but important thread.

CPMs raised:

• Uncertainty around what level of evidence is proportionate

• Tension between real-world evidence and formal validation

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

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

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

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

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

CPMs are operating in:

• Poorly defined roles

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

• Career paths without clear progression or peer benchmarks

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

The underlying pattern

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

Clinical Product Managers are often:

• Holding risk, safety, evidence and user impact

• Moving at startup speed

• Operating without shared frameworks, organisational backing or clear authority

In short:

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

This is Clinical Product as per 2025.

Section 2: The Hiring Market

What UK and US Clinical Product Roles Reveal

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

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

🇬🇧 The UK Market

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

1. Clinical background is expected, not optional

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

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

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

UK Clinical Product roles routinely include responsibility for:

• clinical risk identification and mitigation

• incident investigation and follow-up

• integration of clinical governance into delivery

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

• supporting or leading regulatory activity

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

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

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

• clinical pathways and decision logic

• operating models, SOPs and training

• escalation and safety mechanisms

• internal tools for clinicians and operations

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

4. Evidence beats engagement

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

Instead, CPMs are being measured on:

• pathway performance and quality indicators

• outcomes and evaluation

• real-world data and evidence generation

• credibility with regulators, partners and the NHS

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

5. Scope is wide and often stretched

Many UK roles combine responsibilities across:

• product strategy and delivery

• clinical operations

• safety and risk management

• regulatory coordination

• evidence and evaluation

• partnerships and due diligence

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

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

🇺🇸 The US Market

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

1. Clinical Product does not consistently require clinical training

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

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

• the outcomes being targeted

—not necessarily the professional background of the product leader.

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

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

• collaboration with medical, quality or compliance teams

• consultation on validation, human factors or regulatory pathways

Rather than direct ownership.

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

3. Greater emphasis on scale and business impact

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

• measurable health outcomes at scale

• provider or member efficiency

• adoption and operational performance

• ROI for employers, payers or customers

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

The key contrast

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

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

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

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

Section 3: Predictions for 2026

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

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

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

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

• hold explicit accountability for clinical risk at product level

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

• sit alongside engineering, commercial and medical leadership as peers

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

2. AI becomes core infrastructure for clinical product work

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

Expect AI to be used for:

• assisted clinical risk identification and hazard surfacing

• supporting workflow and pathway modelling across complex care systems

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

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

3. Clinical Product formalises as a function

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

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

• clearer decision rights

• explicit ownership boundaries

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

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

4. The first widely recognised Clinical Product career framework emerges

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

We’ll see early convergence around:

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

• emerging levelling, competency expectations and salary banding

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

• more realistic job scopes aligned to authority and support

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

Conclusion: Clinical Product at a Turning Point

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

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

• Compliance → Design

• Reactive → Proactive

• Clinical translator → Clinical strategist

• Feature delivery → Outcome delivery

• Supporting role → Core function

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

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

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

Your Turn

If you work in or around clinical product:

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

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

Hiring Spotlight x 5 🚀🚀🚀🚀🚀

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

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

Join Us at HLTH Europe 🇪🇺

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

👉 Register your interest for the panel here.

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

Clinical Product Drinks ✨

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

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

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

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

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

Made with 💜 for better, safer HealthTech.

Subscribe now

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

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

Said to me by a healthtech CEO.

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

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

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

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

Convergent Thinking: The Clinical Mode

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

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

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

You can see clinicians are trained to:

• recognise patterns quickly

• rule out danger

• make defensible decisions with incomplete information

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

Divergent Thinking: The Product Mode

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

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

• Why do parents struggle with managing fever at home?

• What was their experience in the GP surgery?

• Why did they decide to seek care?

• Why aren’t existing resources helping them?

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

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

The Misdiagnosis

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

“Clinicians make bad product managers.”

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

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

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

The Real Skill: Switching Modes

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

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

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

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

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

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

The real skill is knowing when to switch between them.

Join Us at HLTH Europe 🇪🇺

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

👉 Register your interest for the panel here.

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

Clinical Product Drinks ✨

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

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

Hiring Spotlight 🚀

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

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

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

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

Made with 💜 for better, safer HealthTech.

Subscribe now

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

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

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

The Problem

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

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

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

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

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

The Grey Zones

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

1. The AI Analysis Line

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

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

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

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

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

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

👉 Navigation approach:

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

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

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

2. The Educational Content Edge

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

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

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

• ✅ Not SaMD: General health and wellness resources

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

• 🔴 Potentially SaMD: Educational content framed as delivering therapy

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

👉 Navigation approach:

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

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

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

3. The Behaviour Change Boundary

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

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

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

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

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

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

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

4. The Clinician Dashboard Dilemma

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

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

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

• ✅ Not SaMD: Exchange secure messages with clinical staff

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

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

The Clinical Product Thinking Takeaway

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

Before you build, ask yourself the question:

Could this feature drive a clinical action?

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

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

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

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

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

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

Made with 💜 for better, safer HealthTech.

[NEW] Want to Go Deeper? 👇 Join Paid

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

Limited to 30 members only.

Read more

Subscribe now

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

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

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

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

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

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

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

What Are Technology Readiness Levels?

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

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

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

In simplified terms:

• TRL 1–3 → Early concepts and prototypes

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

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

• TRL 9 → Fully operational with post-market surveillance

They answer one question:

How mature is this technology, really?

Not:

Is it legally approved?

That’s regulation.

TRL is about engineering and operational maturity.

The Vibe Coding Distortion

Large language models have changed the visual and experiential bar.

You can now:

• Generate polished user interfaces

• Create clinically coherent-seeming logic

• Draft documentation in minutes

• Simulate a security posture

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

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

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

What’s dangerous is mistaking:

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

What TRL 1–3 Usually Means in Practice

At TRL 1–3 you typically still lack:

• Robust, production-grade software architecture

• Deterministic behaviour under edge cases

• Validated and tested risk controls

• Traceability from requirements → hazards → mitigations

• A defensible clinical safety case

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

“But It’s Just a Simple Tool…”

A common response is:

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

Even then, the bar is high.

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

TRL ≠ Certification Readiness

This is the distinction many teams miss.

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

At TRL 1–3 you should be asking:

• Is this problem worth solving?

• Does this intervention make clinical sense?

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

You should not be expecting:

• CE or UKCA marking

• FDA clearance

• Or serious regulatory engagement beyond exploratory conversations

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

The Refactoring Fantasy

There’s another myth:

“We’ll just refactor it later.”

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

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

• Rewriting large parts of the codebase

• Untangling logic never designed for audit

• Retrofitting safety and maintainability

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

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

Why This Matters for Clinical Product Managers

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

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

A strong CPM can say:

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

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

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

That clarity protects:

• Patients

• Teams

• Founders

• And your own credibility

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

The Bottom Line

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

Technology Readiness Levels give us a language to separate:

What looks real
from
What is ready

And in healthcare, that distinction matters a lot.

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

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

Join Us at HLTH Europe 🇪🇺

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

👉 Register your interest for the panel here.

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

Clinical Product Drinks ✨

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

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

Hiring Spotlight x 2 🚀🚀🚀

1️⃣ CareADHD

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

2️⃣ AIBody:

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

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

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

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

Made with 💜 for better, safer HealthTech.

[NEW] Want to Go Deeper? 👇 Join Paid

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

Read more

Subscribe now

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

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

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

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

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

One side prizes speed. The other prizes certainty.

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

Why Going Fast in HealthTech Can Feel Impossible

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

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

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

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

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

Examples I see constantly:

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

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

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

The CPM Approach: Measured Speed

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

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

This might look like:

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

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

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

Why "Slow is Smooth" Wins Every Time

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

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

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

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

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

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

The Compound Effect of Smooth

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

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

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

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

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

Over to You

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

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

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

Hiring Spotlight x 3 🚀🚀🚀

1️⃣ Dyad

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

2️⃣ Semble:

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

3️⃣ Hesta Health

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

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

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

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

Made with 💜 for better, safer HealthTech.

[NEW] Want to Go Deeper? 👇 Join Paid

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

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

Read more

Subscribe now

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

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

Move fast and break things.

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

In healthtech, the things that break are different.

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

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

That difference shaped much of my conversation with Karim:

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

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

Where teams go wrong: design without a safety lens

Most healthtech teams use some form of design thinking:

• researching real user problems

• prototyping and testing solutions

• iterating towards better experiences

On paper, this should reduce risk.

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

Safety tends to appear:

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

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

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

This is where an important distinction gets blurred:

Clinical input ≠ clinical safety input

A clinician might help you answer:

• Is this clinically sensible?

• Is this aligned with guidelines?

• Would this fit into a real workflow?

A clinical safety lens asks different questions:

• How could this be misunderstood?

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

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

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

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

A concrete example: when UI decisions become safety decisions

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

The interface used:

• green, yellow, and red zones

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

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

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

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

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

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

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

• clinical input exists

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

The “house you can’t move” problem

Karim used an analogy that captures this perfectly.

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

You can move it.
But the cost is enormous.

In product development, early decisions harden quickly:

• data models

• escalation logic

• defaults and thresholds

• information architecture

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

Late safety review often means:

• rework

• scope reduction

• significant delays

• or uncomfortable compromises

So what does this mean day to day?

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

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

In practice, that means safety needs to be present:

• when success metrics are defined

• when defaults, thresholds and visual cues are chosen

• when workflows are simplified or steps removed

• when disclaimers are added instead of design constraints

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

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

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

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

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

Clinical Product Dinner ✨

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

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

Hiring Spotlight 🚀

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

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

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

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

Made with 💜 for better, safer HealthTech.

[NEW] Want to Go Deeper? 👇 Join Paid

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

Read more