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. 63 of Clinical Product Thinking. This week, we’re looking at the signs a healthtech company has outgrown clinicians giving input off the side of the desk.
Most healthtech companies start without a clinical product function. Instead, there are clinicians delivering care, a product team moving at speed, and a lot of goodwill holding the two together. And that works for a while.
Then as the company grows, clinical decisions become more complicated, more teams are involved, and changes to one part of the product have complex side effects elsewhere in the patient journey.
That can mean decisions slow down. Clinical requirements emerge late in development, the roadmap becomes reactive, and gaps in care only become apparent when a patient complains, or an incident occurs.
These might look like separate problems. But they often share the same underlying cause: clinical and product teams are making decisions about different parts of the same patient journey, without anyone consistently connecting the two.
As Dani Brightman of Numan put it at one of our panels:
“In health tech, a product decision is a clinical decision when that product is shaping patient care.”
This is where clinical product comes in. It brings clinical and product expertise together to help teams design, build and improve healthcare products.
Here are five signs I see repeatedly in companies that could benefit from their first clinical product hire:
1. Decisions get stuck between teams
As a company grows, more people start to contribute to product decisions that affect patient care.
A change goes through one review, then another. Clinical input arrives late in the process, raising concerns about decisions the team thought had already been made.
The difficulty isn’t simply having too many stakeholders. It’s knowing which decisions need specialist clinical input, which require formal clinical approval and which can be made by the product team independently.
Without that clarity, even relatively straightforward changes can end up passing through multiple rounds of review.
A clinical product function gives the product team someone with the expertise to make day-to-day clinical product decisions, recognise when specialist input is needed and navigate formal approval requirements.
Instead of every decision passing through multiple clinicians contributing a few hours a week, many can be made within the team, with the right people involved when necessary.
2. Everything feels urgent
A clinician raises a concern and describes something as high clinical risk.
The product manager isn’t necessarily a clinical risk expert. They can’t easily judge the potential harm, how likely it is or whether other solutions could address the concern. At the same time, it’s incredibly difficult for a non-clinician to challenge a clinician’s assessment of patient safety.
So the request is treated as urgent. Engineering gets pulled onto the work and other priorities move down the list. Over time, this can mean the roadmap becomes reactive, with priorities changing frequently.
This isn’t a failure of the product manager. They can’t be expected to make clinical judgements they’re not qualified to make.
Clinical product has the expertise to challenge clinical concerns where appropriate, giving product teams a better basis for prioritisation.
3. The patient journey is designed part-by-part
Product teams design the software, clinical teams develop the protocols and operations teams organise how care is delivered.
Each has its own responsibilities, but the connections between them can be overlooked.
Imagine a company builds a digital triage tool that correctly identifies which patients need specialist clinical review.
The software works. The clinical criteria are appropriate. But only a small number of clinicians are qualified to handle those cases, and the team hasn’t accounted for the additional demand.
Patients end up waiting longer than expected, despite the technology working exactly as intended.
The problem isn’t necessarily with any individual component. It’s that the software, clinical pathway and operational capacity weren’t considered together.
As I explored in a previous article, patients don’t experience product, clinical and operational processes separately. They experience one care journey.
A clinical product function helps bring these different perspectives together during development. Working alongside clinical and operational leaders, it considers how technology, clinical workflows, workforce requirements and patient needs fit together.
The healthcare provider remains responsible for the care it delivers, but clinical product can help ensure the technology is designed around how that care actually works.
I’ve written more about this in The Product Is the Pathway, Not the Software.
4. Clinical requirements arrive late
Imagine a product team spends weeks designing and building an online prescribing consultation. The questionnaire, eligibility criteria and prescribing process are all in place.
Then it goes to clinical review.
The clinician identifies a missing requirement: patients need ongoing monitoring after starting treatment.
Suddenly, something that was almost finished needs redesigning. The team may need to introduce new questions, clinician workflows, patient communications and operational processes, alongside additional engineering work.
The team has followed its process. Clinical review happened before launch. But clinical expertise was brought in after many of the important design decisions had already been made.
This is what happens when clinicians are treated primarily as reviewers of proposed solutions rather than contributors throughout product development.
Involving clinical product during discovery means these requirements can shape the solution before development begins. Clinicians are still involved in reviewing and approving the product, but they’re less likely to be asked to identify fundamental requirements after the design is largely complete.
5. What happens in clinical care doesn’t inform what gets built
A patient repeatedly misunderstands an instruction. A clinician develops a workaround for an alert that fires too often. An incident investigation identifies a confusing step in the patient journey.
These problems emerge in different places: patient complaints, clinical governance meetings, operational reports and conversations with frontline clinicians.
Each might be addressed individually, while the underlying product problem remains.
For safety-related findings, clinical governance and clinical safety have established responsibilities for assessing risks and ensuring necessary corrective actions are taken.
But there’s also a broader opportunity to use what happens in clinical practice to improve the product.
A confusing instruction might need a redesigned consultation. A recurring operational workaround might reveal a missing feature. Patterns in patient complaints might highlight a part of the journey that isn’t working as intended.
Clinical product helps bring this information into product development. It works with clinical and operational teams to understand recurring problems, translate them into product requirements and evaluate whether subsequent changes improve care.
This means the product can continue to improve based on data and feedback from clinical practice.
So, do you need a clinical product function?
Not every healthtech company needs a dedicated clinical product manager.
Early on, a product manager working closely with a clinical lead may be enough. If the product and clinical pathway are relatively simple, and the right people are consistently involved in decisions, there’s no reason to create a new function for the sake of it.
But as the company grows, informal collaboration can become difficult to sustain.
You also don’t necessarily need to start with a hire. There are several practical changes you can make:
Agree clinical guardrails before development begins.
Make clinician time predictable rather than relying on ad hoc reviews.
Create a route from clinical incidents and feedback into product improvements.
Involve clinicians in defining problems, rather than only reviewing solutions.
Help clinicians understand the basics of product development so they can contribute more effectively.
I’ve explored these in 5 Lightweight Ways to Apply Clinical Product Thinking Before You Hire a CPM.
If you’re ready to hire, it’s worth being clear about what you need the person to do. Clinical product covers several different types of work, and the right role will depend on your product, clinical model and stage of growth.
Five Archetypes of the Clinical Product Manager can help you work that out.
Breaking Into Healthtech: An Introduction to BiteLabs 🧪
Paid partnership with BiteLabs | Helping clinicians develop the skills, experience and connections to build careers in healthtech.
One of the questions I get asked most is: How can I break into healthtech as a clinician?
The chicken-and-egg problem is real: you need experience to get a job, and you need a job for experience.
I’ve experienced first-hand how tricky that transition can be. It’s one of the reasons I enjoy teaching clinical product on the BiteLabs AI, Digital Health & Innovation Fellowship, which helps clinicians bridge that gap.
What is BiteLabs?
BiteLabs helps healthcare professionals explore opportunities in digital health, artificial intelligence and healthcare innovation.
Its flagship AI, Digital Health & Innovation Fellowship is an eight-week programme designed to give participants practical experience of what goes into building healthcare technology.
The fellowship covers topics including clinical product management (with yours truly), AI, product development, regulation, commercialisation and entrepreneurship, taught by people with experience working in the industry.
One of the parts I particularly like is the opportunity to work on a real healthcare problem. Participants can develop their own product ideas, apply what they’re learning and explore what it actually takes to turn an idea into a product. They leave with something tangible to show for their efforts, which is useful when trying to demonstrate relevant experience to prospective employers.
It’s also a chance to make mistakes, test assumptions and get feedback on your ideas in a supportive environment before taking them further.
More than just education
One of the biggest challenges clinicians face when moving into healthtech is understanding and communicating the value of their existing experience.
There are opportunities across clinical product, clinical safety, clinical strategy, operations and entrepreneurship, but it isn’t always obvious where to start or how to position yourself for these roles.
Alongside its educational programmes, BiteLabs provides career coaching, mentorship and access to a community of healthcare professionals working in or transitioning into the industry.
Is BiteLabs right for you?
You certainly don’t need a fellowship to break into healthtech. Many clinicians make the transition independently.
But structured learning, practical experience and the incredible connections you’ll gain can certainly make the transition easier.
If you’re curious about opportunities beyond clinical practice, considering a career in clinical product or interested in building healthcare technology yourself, BiteLabs is worth exploring.
The next UK cohort starts on Thursday 11 February 2027, with applications closing on Thursday 21 January. It runs for eight weeks, with one two-hour workshop on Zoom each Thursday evening, and finishes with a Demo Day in London.
💡 Apply with the code CPT001 and your application is treated as a referral, which means:
Priority review, with extra points on your application
A one-to-one career coaching session with the BiteLabs team
A one-to-one with a BiteLabs founder to talk through your skills, network and goals in healthtech
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.