This is Clinical Product Thinking 🧠, a weekly newsletter featuring practical tips, frameworks and strategies from the front line of clinical product.
Welcome, friends. This is issue No. 62 of Clinical Product Thinking. This week, we’re recapping some of the tools we’ve covered in the last year.
Since launching Clinical Product Thinking in August 2025, we’ve covered everything from the role of clinical product managers to scaling clinical services, designing safer workflows and evaluating clinical AI.
Along the way, we've built a growing collection of frameworks, models, and practical tools. Some are ways of thinking about a problem, others help teams make decisions or put clinical product thinking into practice.
I’ve brought them together here, with a short explanation of each, when to use it and a link to the original piece.
This is a living library. I’ll keep updating it as new ideas and tools are published, so bookmark it for future reference.
👩⚕️ 1. Making clinical product decisions
The Clinical Product Triangle 🔺
The Clinical Product Triangle is a decision-making framework built around three perspectives:
Patient: Does it help me?
Clinician: Can I trust it?
Business: Can we sustain it?
A product can be clinically excellent but too expensive to deliver. It can offer a beautiful patient experience while creating an unsustainable clinical workload. Or it can be commercially attractive while compromising the quality of care.
Clinical product management sits between these perspectives, helping teams understand the trade-offs and make decisions that work across all three.
When to use it: When comparing product options, prioritising features or making decisions where patient benefit, clinical workload and commercial viability pull in different directions.
Originally shared: The Clinical Product Triangle — Linkedin, 29th September 2026
The Fourth Amigo Model 🤠
The Fourth Amigo Model is a way of organising product teams so that clinical judgement informs decisions throughout development.
It builds on the familiar product, design and engineering team by adding clinical product as a fourth member.
Product decides what problem to solve and what to prioritise.
Design makes the right action clear and easy for users.
Engineering builds the product reliably and securely.
Clinical Product brings clinical judgement, safety and the reality of care delivery.
The model means questions like “Should this allergy alert be a hard stop or a warning?” are addressed while the product is being designed, rather than during a last-minute clinical review.
When to use it: When designing your product team, defining clinical product responsibilities or deciding how clinical expertise should contribute to development.
Originally shared: The Fourth Amigo Model — LinkedIn, 17 August 2026
The Five Translations
A clinical product manager’s most important skill is translating clinical understanding into decisions that product teams can act on.
The Five Translations describe the points where this happens:
Clinical nuance → product requirements
Safety risk → design constraints
Potential harm → prioritisation
Messy clinical pathways → usable journeys
Clinical outcomes → commercial impact
For example, a clinician might say that a particular questionnaire is essential. The translation is determining whether it should be mandatory, conditional or recommended, and how that decision should be reflected in the product.
When to use it: When defining the clinical product role, hiring or developing clinical product managers, or diagnosing why clinical and product teams struggle to communicate.
Read: The Skill Every Successful Clinical Product Manager Needs to Know — 31 May 2026
🧩 2. Bringing clinical thinking into the team
Five Lightweight Ways to Apply Clinical Product Thinking
You don’t need a dedicated clinical product manager to start bringing clinical judgement into product development.
This practical guide describes five ways teams can get started:
Agree clinical guardrails before development begins.
Make clinician time predictable and accessible.
Create a route from clinical incidents to product improvements.
Involve clinicians when defining problems, rather than reviewing finished solutions.
Help clinicians understand the basics of product development.
For instance, agreeing in advance which decisions require clinical input can prevent clinical reviews from becoming unexpected obstacles late in development.
When to use it: When building an early-stage healthtech team, introducing clinical input into an existing product function or improving collaboration before hiring a dedicated clinical product manager.
Read: 5 Lightweight Ways to Apply Clinical Product Thinking Before You Hire a CPM — 26 October 2025
The Clinical Product Influence Playbook
Clinical product managers frequently need to shape decisions without having formal authority over the people making them.
This playbook describes three habits that can help:
Speak the language of the people you’re trying to influence.
Connect clinical objectives to the company’s commercial goals.
Contribute early, without waiting to be invited into the conversation.
For example, rather than simply raising concerns about an unsafe workflow, explain the potential patient harm, the operational consequences and what could be changed to make the proposed approach safer.
When to use it: When you’re the only clinical product person in an organisation, struggling to influence prioritisation or finding that clinical input arrives after decisions have already been made.
Originally published: The CPM Playbook for Building Influence — 28 September 2025.
🛡️ 3. Designing and scaling safer clinical products
Four Checks Before You Scale
Early-stage clinical products often work because people quietly compensate for what the product cannot yet do.
Clinicians make judgement calls, operations teams resolve broken workflows and manual reviews catch problems before they reach patients.
As volume grows, these arrangements become harder to sustain.
Four practical checks can help teams identify vulnerabilities before scaling:
Find the workarounds. Identify manual checks, spreadsheets, informal escalation routes and repeated interventions.
Run a 10x stress test. Ask what would fail if patient volume increased tenfold tomorrow.
Observe the real workflow. Watch how people use the product under normal working conditions.
Track emerging operational risks. Identify dependencies and processes likely to become unsafe or unreliable as demand increases.
When to use it: Before launching into new markets, signing a major contract, expanding care delivery or significantly increasing patient volumes.
Read: Scale Does Not Create Clinical Risk. It Reveals It. — 21 June 2026
The 2am Test
The 2am Test is a simple design heuristic inspired by a conversation with Benedikt von Thüngen, CEO of Sanome, about the value of observing clinicians working night shifts.
It asks:
How would this product work at 2am?
Imagine a tired clinician, a slow computer, incomplete information and a deteriorating patient. Can the person using your product still understand what’s happening and identify the next safe action?
The test encourages teams to examine the difference between work as imagined and work as done, particularly when clinical work involves interruptions, uncertainty and adaptations that don’t appear in a workflow diagram.
When to use it: When designing or reviewing clinical workflows, particularly those involving time-sensitive decisions, alerts, escalation or use under pressure.
Read: The 2am Test: Is Your Clinical Product Designed for Real Life? — 28 June 2026
🤖 4. Building, testing and assuring clinical AI
Right Answer, Wrong Action
Developed through conversations about behavioural AI safety with Dr Paul Sacher, Right Answer, Wrong Action describes a class of clinical AI failure that conventional accuracy testing can miss.
An AI system can provide clinically correct information while making a patient more likely to take an unsafe action.
For example, a conversational AI might offer reassurance that is technically reasonable in isolation, but encourages a particular patient to delay seeking medical attention.
The framework describes four categories of failure:
Context failures: The AI responds without sufficient information about the patient.
Reception failures: The patient interprets the answer differently from how it was intended.
Reinforcement failures: The AI encourages or validates a potentially harmful behaviour.
System-boundary failures: The interaction crosses or obscures the limits of what the AI should safely do.
These are expanded into twelve named answer types to help teams recognise potential failures during evaluation.
When to use it: When designing or testing patient-facing conversational AI, particularly where patients might act on advice, seek reassurance or develop ongoing relationships with a system.
Read: The ‘Right Answer, Wrong Action’ Dangers of Clinical AI — 10 May 2026
Three Building Blocks for Pre-Deployment AI Testing
Traditional testing often evaluates AI responses one prompt at a time. But in conversational healthcare products, safety failures may only emerge after several exchanges.
This testing approach brings together three components:
Behavioural personas: Realistic and adversarial users who test how the system responds to different circumstances and behaviours.
Evaluators: Explicit criteria used to assess whether the AI behaved appropriately, including recognising risk, staying within scope and escalating when necessary.
Evidence: Conversation transcripts, evaluation results, system versions and records of what changed between tests.
The approach also requires someone to define the acceptance criteria, evaluate the evaluators and decide whether the evidence is sufficient to support deployment.
When to use it: When developing a patient-facing AI agent, designing pre-deployment evaluations or building a repeatable testing process for changes to prompts, models and workflows.
Read: Why Your AI Passed Testing and Would Still Fail a Real Patient — 16 August 2026
🚀 5. Moving into clinical product
Four Steps to Break Into Clinical Product
A practical career roadmap for clinicians moving into product roles, drawing on advice from clinical product leaders and hiring managers.
The four steps are:
Unlearn deference. Get comfortable challenging assumptions and contributing to decisions regardless of hierarchy.
Understand what hiring managers want. Demonstrate pragmatism, collaboration and commercial awareness alongside clinical expertise.
Learn to think like a product person. Develop an understanding of users, prioritisation, experimentation and how products are built.
Get your first product experience. Start with advisory work, feature testing, product critiques or small projects rather than waiting for the ideal job title.
Clinical experience gives you knowledge of patients and healthcare delivery. The challenge is showing how you can apply that knowledge to product decisions.
When to use it: When planning a move from clinical practice into healthtech, preparing for clinical product interviews or identifying the experience you need to develop.
Read: Breaking Into Clinical Product — 26 July 2026
Keep exploring
This collection brings together some of the ideas I’ve found most useful when thinking about how clinical products should be built, evaluated and improved.
Some are original models, others are practical adaptations of established approaches or lessons developed through conversations with people working across clinical product, safety and AI.
I’ll keep adding to the library as new frameworks and tools emerge.
If you’ve tried any of these approaches, or have a problem you’d like Clinical Product Thinking to tackle next, I’d love to hear about it. Reply to this email or leave a comment.
What I’m reading 📚
So many interesting papers published in the last month, I wanted to share some of the things I’ve been nerding out on:
1. The anatomy of a personal health agent — Google Research
Google’s research into AI agents combining wearable data, medical knowledge and personalised health coaching. An interesting look at multi-agent design. (Nature paper)
2. Building Medical Superintelligence — Microsoft AI
Microsoft’s diagnostic AI achieved 83% accuracy on complex cases versus 36% for physicians using reference materials. Fascinating implications for clinical reasoning, although real-world validation is still needed. (Science paper)
3. State of Clinical AI in 2026 — BMJ Digital Health & AI
A comprehensive review of where clinical AI actually stands. Particularly interesting on the gap between impressive benchmark performance and real-world evidence, clinical safety and human–AI collaboration.
That’s all for this week. See you next time! 👋
🤝 Work with me | 📅 Attend an event | ✍️ Send a message
Written by Dr Louise Rix, Clinical Product, AI, doctor and ex-VC. Passionate about all things healthcare, healthtech and clinical product (…obviously). Based in London. You can find me on LinkedIn & Instagram.
Made with 💜 for better, safer HealthTech.