The Translation Series
Clinical product is a clinician sitting in the product team.
Wrong.
Clinical product translates between clinical and product.
Right?
It’s a reasonable shorthand to view clinical product as the function that translates clinical needs into product. And it’s not wrong, on any given day, you might be explaining to an engineer why a dosing logic matters, or helping a clinician understand why adding the correct status to a decision matters for the journey of that patient.
But the more I've done this work, the more I think 'translation' doesn't quite capture the role. Translation implies that somewhere, there's a clean clinical truth and a clean product requirement, and your job is to carry meaning from one to the other.
That's rarely what happens. More often, you're in a room where the clinical evidence is ambiguous, the product problem is half-formed, and the user need sits somewhere between the two. You're not translating a known text, you're writing the first draft. That's the part the 'translation' framing misses.
In the Foundation Series, I defined what clinical product is - embedded, blocking by default, accountable for clinical integrity. This next series is about how it actually works day to day, and a core component of that is speaking the language of the people around you.
The moment it clicked
Early in my career in clinical product, I'd walk into conversations with product managers, engineers and designers, and make the clinical case. I gave sound reasoning and clear evidence, but nothing would happen.
It took me a while to understand why. The problem wasn't that people didn't care about clinical impact, the problem was that I was speaking a different language.
The shift came when I started thinking about what the person across from me was actually being assessed against. A product manager is measured on outcomes, velocity, and impact. An engineer is measured on delivery, quality, and technical soundness. A designer is measured on user experience and clarity of flow.
Once I understood that, I realised my job wasn't just to make the right clinical call. It was to frame that call in a way that made it easy for the other person to act on it.
What happens when you don't translate
The most common failure mode in clinical product is talking only about risk.
This is a clinical risk.
We can't ship this because of risk.
I've flagged the risk.
Imagine a sat nav that only told you about closed roads. Technically accurate, completely useless for getting anywhere.
The best sat nav doesn't just tell you what to avoid, it weighs up every available route given your constraints and picks the best one for your journey. That's closer to what clinical product should be doing. You're not there to announce hazards, you're there to help the team find the best path forward given clinical, commercial, and user constraints simultaneously.
When clinical product only talks in terms of risk, product and commercial teams hear: this is something we have to do because compliance says so. You stop being someone people build with and start being someone people build around. Clinical product should shape decisions, but focusing only on risk reduces you to a box to tick.
Compare that to framing the same concern differently:
If we ship this without resolving the edge case, here's how it affects the patient experience, and here's the regulatory exposure if it scales.
You’ve used the same clinical judgement, but now the product manager can prioritise it, the commercial lead can see the cost, and the engineer can scope a fix. You've done all of that without diluting the clinical position.
Every function has its own language
Every function you work alongside has its own way of seeing the world, its own mental model, and its own priorities.
Product managers think in outcomes, velocity, and user value. Engineers think in systems, edge cases, and constraints. Commercial managers think in cost of acquisition, conversion, and retention. Designers think in user flows, friction, and clarity. Clinical operations think in caseload, triage, and escalation. Data teams think in metrics, cohorts, and measurement.
Your job is to understand all of them well enough to make your input land.
What this series is about
Over the coming articles, I'm going to write about what it's actually like to work across each of these functions as a clinical product person, including conversations with people in those roles about what it's like from their side.
I'm calling it the Translation Series because that's the skill that underpins all of it: learning to speak the other person's language, understanding what they're optimising for, and framing your clinical input in a way that makes collaboration possible rather than adversarial.
This post is part of the Translation Series on working across functions in Clinical Product. Subscribe to be notified of new posts.