The Product Is the Pathway, Not the Software
What it really takes to build tech-enabled care services that scale
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. 042 of Clinical Product Thinking. This week, we’re talking about what it takes to start and scale tech-enabled clinical services.
One of the most useful conversations I’ve had recently was with a group of people building and operating tech-enabled clinical services at scale.
We asked the difficult questions:
How do you actually build a clinical service that scales? How do you organise teams around care delivery? When should you buy software, and when should you build it? How do you stop complexity from multiplying across countries, pathways and customer segments?
One takeaway stood out:
In tech-enabled care, the pathway is the product. The software exists to support it.
In a tech-enabled clinical service, software is only one layer of the product. The actual product is the end-to-end service: the patient journey, the clinical model, the operational workflow, the escalation process, the documentation, the workforce, the governance, the analytics, the outcomes, and the way all of those things interact in the real world.
This matters for clinical product managers as it becomes part of their remit.
Clinical product is pathway ownership
At one company, the clinical product function is called “Clinical Pathway”, and the people in that function are Clinical Pathway Leads.
Clinical Pathway Leads sit within a squad alongside product and engineering, with ultimate accountability for how the pathway works in practice. That includes its clinical safety, operational flow, usability, measurement, performance and outcomes.
This is different from the model I often see in healthtech, where clinical, product, engineering and operations sit in separate functional silos, then try to coordinate through meetings, tickets and escalation channels.
But clinical services do not break neatly along functional lines.
A patient does not experience a “product issue”, then an “ops issue”, then a “clinical issue”. They experience one journey. A clinician does not experience workflow, documentation, risk, software usability and operational capacity as separate things. They experience one working environment.
That is why the squad model matters.
Instead of organising around functions, you organise around pathways. The point is not simply to create a multidisciplinary team, but to create a unit of accountability that maps to the thing you are actually trying to improve.
The squad is accountable for pathway KPIs, not just software delivery.
That shift changes what gets prioritised, which trade-offs are visible, who has authority and what counts as progress. A feature can ship while the pathway remains broken. A dashboard can make a service more measurable without making it more effective. An automation can reduce manual work while introducing new clinical risk.
Clinical product needs a broader definition of “product”, because in healthcare the thing being designed is the care pathway, not just the software that supports it.
Do not build the pathway and the software at the same time
Another point that stayed with me was the danger of trying to innovate on too many layers at once.
When you start a new tech-enabled clinical service, there is a temptation to build the pathway and the software simultaneously. The founder may have a clear view of how the service should work, and an equally clear view of the technology needed to deliver it.
But building a new clinical service is already a huge act of discovery. You are designing a care model, testing a pathway, building workflows, creating governance, training a workforce, learning what patients and clinicians need, and working out where risk appears.
If you also try to build bespoke software at the same time, you are stacking innovation on innovation before you properly understand the shape of the service.
The pragmatic advice was: buy software off the shelf first, learn the pathway, then rebuild later when the operational pain becomes impossible to ignore.
Off-the-shelf tools will not be perfect. They may feel clunky, require workarounds, or fail to map neatly to your pathway. But early on, that can be useful. They give you a learning scaffold before you hard-code your assumptions into a bespoke system.
You should only switch or rebuild when the software becomes too expensive, too generic, unable to support the workflow, or when your documentation and operational needs become specific to your clinical vertical.
The sequence matters. The pathway should teach you what the software needs to become.
Standardise by default, localise by exception
The next principle was standardisation.
When companies move into complex clinical systems, especially across multiple countries, complexity multiplies quickly. Each market brings its own regulations, clinical norms, prescribing rules, data requirements, operational constraints and patient expectations.
If every country, pathway or customer implementation starts creating its own way of working, the company can quickly end up with several different services wearing the same brand.
That might feel responsive in the short term. Over time, it becomes clinical product debt.
Companies die by complexity.
Was a phrase used on the night. The principle that emerged instead was: standardise everything you can, and only deviate where you absolutely must.
That might mean central operations, shared tools, common documentation structures, consistent governance processes, agreed escalation routes, a shared analytics framework and aligned pathway KPIs. Country-specific variation should exist, but it should be deliberate and driven by regulation, clinical guidance, reimbursement, prescribing rules, data/privacy requirements or genuine local context.
The default should be a shared operating model with justified exceptions.
This matters because every unnecessary variation creates future drag. It becomes harder to train teams, measure performance, compare outcomes, maintain quality, govern safety and build software that scales.
Standardisation can sound bureaucratic, especially to early-stage teams that prize speed and flexibility. But in clinical services, it is part of how you preserve safety and quality as you scale.
The more complex the system, the more disciplined the operating model needs to be.
Workforce design is part of the product
The final theme was workforce complexity.
In a clinical service, not all work is interchangeable. Some tasks are straightforward and repeatable. Others require specific skills, experience, qualifications or training.
That creates an important operational question: how quickly can you train the people you have to handle more complex work safely and effectively?
In clinical product, that is also a product question.
Workforce design affects what the pathway can do. It shapes cost, quality, safety, throughput, patient experience, clinician experience and scale. If a pathway depends on a small number of highly skilled people, that constraint is part of the product architecture. If the software assumes work can be standardised but the clinical reality requires nuance, that mismatch will eventually show up.
Often, the most important product decisions in clinical services are not obviously “product” decisions. They are decisions about who does the work, what they are trained to do, what they are allowed to decide, what the software makes easy, what it prevents, what it escalates and what it measures.
Workforce capability is not a back-office detail. It is also part of the product.
The real product
If the pathway is the product, clinical product has to care about how the service works in practice.
That means looking beyond individual features to how patients move through the pathway, how clinicians make decisions, how risk is managed, how work is distributed, how outcomes are measured, and whether the operating model holds up as the company scales.
The software matters enormously. It can make the pathway safer, more consistent, more measurable and easier to scale.
But the companies that win in tech-enabled care will not be the ones that only build better software. They will be the ones that build better systems of care.
Say hi at HLTH! 👋
📆 15th June, 1 - 2pm, Room G108
If you’re at HLTH tomorrow join me, Danielle Brightman, Benedikt von Thüngen and Dr Elle Clarke for a discussion on what it takes to build and scale digital health. Please do come and say hello afterwards!
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.
This maps cleanly to surgical AI as well: the useful product is not the model, it is the pathway state the team can actually trust. A pre-op agent only helps if it changes ownership around readiness, escalation, documentation, or handoff rather than adding another surface everyone has to monitor.