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. 058 of Clinical Product Thinking. Today weâre talking about one of the less comfortable parts of clinical product: saying no.
In Clinical Product Thinking, weâve covered before why Clinical Product should be embedded throughout the product lifecycle. But being embedded isnât enough.
If you identify something that you believe is clinically unsafe, what happens next?
Can the product team overrule you? Can someone decide the commercial benefit outweighs the clinical concern? Can the feature ship anyway?
Those questions get to something we donât talk about enough when defining clinical product: authority.
So this week Iâve handed Clinical Product Thinking over to my good friend Danielle Brightman, who writes about the discipline at clinicalproduct.uk, to make the case for why Clinical Product needs the power to block, and why knowing when not to use that power is equally important.
Letâs dive in.
The uncomfortable truth
As Dani describes it, one of the most uncomfortable truths about Clinical Product is that the role is blocking by default.
As much as we talk about how the role shouldnât be approached only for sign-off, or as a tick-box exercise, at its absolute core, it can block.
Why blocking matters
If Clinical Product cannot block a release, the role becomes advisory. The result is that your suggestions get weighed against speed, and speed usually wins.
Blocking is the enforcement mechanism. Itâs what transforms âplease listen to the clinical personâ into âthe clinical person has the authority to ensure patient safety.â
The discomfort of being the blocker
Nobody wants to be the person who stops things, especially in fast-moving product teams where momentum matters and delays are visible.
As a Clinical Product Manager, you are (/should ideally be) embedded in the team and understand the pressure everyone is under to ship. Because of this, youâll also be feeling pressure to let things through when you know itâs not quite right.
This is the central tension of Clinical Product roles: youâre embedded in the team, but youâre also the one who might stop the team from shipping. Navigating that tension can be tough.
What blocking actually looks like
Blocking doesnât mean saying no to everything, and it definitely doesnât mean threatening teams on a daily basis that you might block the feature. It does, however, remind teams of your role and the responsibility you hold.
Work that doesnât quite meet the bar can be handled much better than a flat ânoâ, for example:
âWe can ship this, but not with that edge case unresolved.â
âThis is fine for a limited rollout. Itâs not fine for general use.â
âI need more information before I can sign off.â
âThis doesnât meet the clinical threshold. Hereâs what would.â
Good blocking is specific. It gives teams something to work with by outlining the problem, and, where possible, points towards a solution.
The cost of not blocking
When Clinical Product doesnât block, or canât, the consequences tend to be invisible until theyâre not.
That edge case you let through, knowing it wasnât quite right, hoping it wouldnât surface? It reveals itself as an incident. Either as a single event, or through the accumulation of regulatory risk that the company is eventually pulled up for.
A delayed release is far better than a release that harms someone. Incidents are costly - not only for patients who are harmed, but also for the business. Time is spent fixing the issue, responding to the patient, to the media and to the regulator.
Building the credibility to block
Blocking only works if people trust your judgement. If they donât, theyâll go around you, or above you, to confirm your call.
Trust is earned, and it takes time. It comes from:
Being right more often than youâre wrong, and being honest when youâre uncertain.
Understanding the product, not just the clinical domain.
Picking your battles - blocking when it matters, not blocking reflexively.
Explaining your reasoning, not just asserting authority.
If you block too often, you lose credibility, but if you never block, even when you should, you lose the point of the role.
Knowing when to step back
Not every decision needs clinical product to make the final call.
Youâre part of the product conversation, shaping direction, contributing to trade-offs, understanding whatâs being built. But some decisions, like choosing between two equally safe design patterns, or prioritising one low-risk feature over another, can be left as a team decision. There may be commercial factors, or patient experience considerations, that pull one option over the other.
The question to ask yourself is: does this decision require me to exercise clinical authority, or can I contribute as part of the team without needing to be the deciding voice? If itâs the latter, step back and allow the team to own it.
This is harder than it sounds. When youâre accountable for clinical outcomes, itâs tempting to assert your position on everything, but knowing when not to block is just as important as knowing when to block.
A note on hiring
If youâre hiring for Clinical Product, ask yourself: does this role have the authority to block a release? If the answer is no, youâre not hiring for Clinical Product youâre hiring a clinical advisor.
If youâre looking for a role in Clinical Product, check with the hiring manager: does this role have the authority to block a release?
Remember: clinical accountability requires the power to stop something. Without it, youâre responsible for outcomes you canât control, and when something goes wrong, you carry the blame without having the influence to prevent it.
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 & Safety, 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.