The Skill Every Successful Clinical Product Manager Needs to Know
Why clinical expertise alone doesn’t build better products
This is Clinical Product Thinking 🧠, a weekly newsletter featuring practical tips, frameworks and strategies from the frontlines of clinical product.
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.
