Scale Does Not Create Clinical Risk. It Reveals It.
How to scale digital health products safely
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. 043 of Clinical Product Thinking. This week, weâre talking about scaling, safety and how to spot risks before they become incidents.
Last week I hosted an event at HLTH Europe on how to safely scale digital health. One of the big takeaways from the panel; Dani Brightman, Numan, Benedikt von ThĂźngen, Sanome and Dr Elle Clarke, Heim was this:
Scale doesnât create risk. it reveals where it was already hiding.
Or more precisely: scale exposes weak points that were being silently patched by people, process and clinical judgement.
Scale doesnât create risk. It reveals it.
As products scale, youâre not just handling more patients or more data.
Youâre stress-testing whether your system actually works or whether it only looked like it worked because people were quietly holding it together.
At small scale, that gap is invisible.
You find:
clinicians making judgement calls because SOPs arenât fully clear
ops teams fixing broken workflows in real time
support repeatedly explaining things the product should have made obvious
manual reviews catching errors the system itself is generating
This is the âinvisible layerâ of early success.
The hidden work behind early success
Early products almost always depend on invisible labour. And thatâs not a mistake, itâs how to learn incredibly quickly.
But there is a catch.
At small scale, teams sit close to users. They absorb problems quickly. That can create the illusion that the product is more robust than it actually is.
Because:
A workaround can solve a problem without solving the underlying cause.
A manual review process can catch errors without improving the system that creates them.
A person stepping in can protect patients without revealing that the product needs redesign.
The risk is not that teams do this.
The risk is not being aware that these workarounds exists.
Scaling safely requires changing the way you think about problems
In early-stage clinical products, clinicians are often operating at maximum capacity.
That makes it understandable that workarounds emerge without much time being spent stepping back to redesign the system itself.
But thereâs an important shift that happens as you move towards scale:
Investigating problems properly and building better solutions takes time. Itâs an upfront investment for a later payoff and it rarely happens by default.
Thatâs why teams either need to be:
explicitly incentivised and supported to do this work, or
structured with a dedicated function (like clinical product) whose job is to translate clinical friction into system improvements
Otherwise, the same people who are holding the system together day-to-day never get the space to redesign it.
Scaling safely means redesigning where work happens
When something breaks at scale, the instinct is often to add process.
But what actually matters is shifting where work sits:
From:
human judgement under pressure
manual interpretation
repeated explanations
To:
product design
system logic
clear escalation paths
monitoring and feedback loops
This is the shift that determines whether scaling creates fragility or removes it.
Finding the risks before you scale
If youâre on the precipice of scale some useful exercises for you:
1. Find the workarounds
Ask your users:
What do you check manually?
What questions do people repeatedly ask?
Where do you use spreadsheets, notes or other tools?
What do you do outside the product to complete this task?
What problems do you message team members about repeatedly to try to solve?
These workarounds are evidence of where the system can be optimised.
2. Run a 10x stress test
Take one important workflow and ask:
âWhat breaks if volume increases 10x tomorrow?â
Look at:
response times
manual reviews
escalation processes
points where a person has to intervene
decisions that depend on individual judgement
Most fragility shows up here immediately.
3. Watch the real workflow, not ideal one
Spend time observing how people use the product in their normal environment.
Look for:
where people pause
where they create shortcuts
where they ask colleagues for help
where they interpret information differently
where they leave the product to do something else
These often show where the product needs to change.
4. Track emerging operational risk explicitly
Teams usually track features they want to build.
They should also track areas that may become difficult as usage increases.
Examples:
manual processes
unclear escalation routes
customer-specific variations
inconsistent patient journeys
data that is difficult to monitor
features that create complexity without improving care
These are the areas most likely to become problems later.
A final reframing
Scaling a clinical product is often framed as an engineering or regulatory challenge.
But the panel made a different point: Itâs actually a visibility problem.
At small scale, you can miss whatâs broken because people are quietly fixing it.
At large scale, you canât.
Which means the real work of scaling safely is not just building more product.
Itâs removing dependence on invisible heroics and replacing them with systems that behave the same way at 10 patients as they do at 10,000.
Hiring spotlight đ
đŹđ§ Manual are hiring a Medical Director. I caught up with Earim, CMO, on the role and this an incredible opportunity for a visionary clinician. đ Apply here.
đşđ¸ Hinge Health are hiring a Clinical Product Consultant to help them transform MSK care. đ Apply here.
HLTH you were a vibe đ
So great to see many of you in Amsterdam.
Join the next clinical product panel đ¤
đ 14th July, 7pm, online
The next clinical product panel is on 14th July and weâll be covering the âclinical product gapâ or why healthtech needs a new kind of product leader. đ 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.