Clinical product roles are multiplying across digital health. The problem is, most of them need to be filled by someone experienced, and there aren’t enough experienced people to go around.

This creates an uncomfortable reality: organisations are hiring Clinical Product Managers and expecting senior-level judgment from day one. They’re asking people to own clinical risk, make difficult calls, and sign off on releases, all without the structure that would normally develop those skills.

Learning without a safety net

In traditional clinical roles, you don’t get left alone with difficult decisions until you’ve had years of supervised practice. There’s always a structure: you shadow, you’re observed, you make mistakes in relatively contained environments, and then you debrief. Even upon qualification, there’s a continuous learning cycle with supervision and feedback sessions, as well as the continuing professional development (CPD) you must do as part of maintaining your clinical licence to practice.

In clinical product, that structure rarely exists.

You’ll find yourself as the only clinician on a product team, and commonly, the only clinical product person for the company. You might report to someone who has never worked clinically, for example people from a product or technology background. You might be asked to approve something that no one else fully understands, and the expectation is that you just know.

This isn’t a criticism of the people doing the hiring. It’s a reflection of how new the discipline is. There’s no established curriculum. No widely accepted competency framework. No external training that prepares you for the messy reality of clinical decision-making inside a product squad.

What this means in practice

When I started in clinical product, I didn’t have a playbook. I had clinical training, product instincts, and a lot of uncertainty about where the boundaries were.

The hardest part wasn’t the clinical knowledge - it was learning to have those clinical risk debates in your own head. The clinician vs the product manager vs the commercial manager. Then the next hurdle was how to translate all the thought that had gone behind that decision, and how to be prepared for the hard (but appropriate) push on must-haves vs nice-to-haves when it comes to clinical risk. It was also about balancing clinical priorities with real commercial priorities too. How to not kill a business with clinical safety, but still build a product that’s genuinely safe, and enjoyable, for patients. How to explain risk in terms that product teams could act on. Whether to block a release and know where the hard line was, despite knowing the consequences. How to say “I don’t know” without losing credibility.

Most of that learning happened through trial and error, in real time, with real stakes, and I’m still learning.

Why I’m writing this

This site exists because the gap between what clinical product roles require and what’s available to support them is too wide.

If you’re doing this work, whether you’re new to it or have been doing it for years, I want this to be useful and grounded in what the job actually involves.

I’ll be writing about:

• What clinical product actually is (and isn’t)
• The hidden work behind clinical sign-off
• How clinical decisions really get made inside product teams
• The tension between clinical product and other functions - and how to navigate it
• Organisational design and maturity in clinical teams

Everything here comes from lived experience. I’ll be coming at it from my personal experience of what clinical product means for me. Clinical product is a discipline that’s still being defined, and it’s time we start defining it.

If you’re building clinical product capability or working out what it should look like in your organisation, I’ll be sharing more in upcoming posts - subscribe to be notified!