Step 8 of 12: Operational Scalability and Deployment
- Jun 30
- 9 min read
You Sold the Hospital! Now the Real Work Begins.
One of my favorite memories from my time as a clinical specialist went something like this.
My phone would ring.
"Hey Rob, good news. We sold a robot."
"Awesome. Where?"
"Hospital X."
"Nice. When do they want to launch?"
"Tomorrow."
"...Tomorrow?"
"Yep."
That was usually the extent of the handoff.
Maybe I'd get the surgeon's name. Maybe I'd get the hospital address. If I was really lucky, I'd have the truck driver's phone number.
Everything else? Figure it out when you get there.
Now I had less than twenty-four hours to begin to coordinate receiving a six-figure surgical robot, meet with biomedical engineering, work with hospital IT, get the network configured, train the surgeons, onboard the OR staff, run SPD in-services, support the first procedures, and somehow make it all look like this had been carefully planned for weeks.
No pressure.
Looking back, it's amazing we launched as many systems as we did.
Survival of the fittest...or at least the one who could roll with the punches for the longest.
This is Step 8 of the MedTech Recovery Program. It's the part almost nobody talks about because closing the deal is more exciting than talking about implementation playbooks and training schedules. Unfortunately, hospitals don't care how exciting your sales process was. They care whether your technology actually works inside their environment without creating unnecessary headaches.
A signed contract doesn't mean you've won.
It simply means you've been invited to prove you deserve the next one.
Selling the Product Isn't the Hard Part
Founders spend years building technology, raising money, getting through FDA, generating clinical evidence, and finally convincing a hospital to buy.
Then they celebrate. Fair enough.
But from the hospital's perspective, the purchase order isn't the finish line. It's permission for the real work to begin.
Hospitals aren't buying your software.
They aren't buying your robot.
They aren't even buying your technology.
They're buying your ability to deploy it without disrupting patient care, overwhelming their staff, breaking their IT environment, or creating another problem someone has to own.
That's a much bigger promise than most realize. Your product is only one piece of the offering. Everything surrounding it is what hospitals actually experience.
Implementation.
Training.
Clinical support.
Documentation.
Troubleshooting.
Customer success.
Response times.
If those systems don't exist, you're not commercially ready.
You're just optimistic with a purchase order.
The Four Myths of Launching a New Product
Every company believes some version of these before reality inevitably proves otherwise.
Myth 1: "Every Hospital Is Basically the Same."
Not even close.
Every hospital has different IT requirements.
Different procurement processes.
Different cybersecurity standards.
Different workflows.
Different personalities.
Some hospitals can approve software updates in a week.
Others need three committees, two security reviews, and what feels like permission from the United Nations.
I've done onboarding at 5AM on a Saturday because that was the only time SPD was available...well I can say that this is pretty consistent across hospitals.
I've trained OR teams before sunrise.
I've waited until nine at night because cases kept running behind to train physicians, only for them to sneak out the back door.
Hospitals don't schedule around your calendar. They schedule around patient care as they respectfully should.
Your deployment model has to survive that reality. Key word: Flexibility.
Myth 2: "Our Engineers Can Handle Training."
They probably can't, or at least not at scale.
Understanding how a product works internally and teaching busy clinicians how to use it are two completely different skills.
I've watched incredibly talented engineers spend twenty minutes explaining software architecture to a room full of OR nurses who just wanted to know which button to press if something stopped working.
Neither side was wrong.
They were simply having two completely different conversations.
Clinical training isn't a product demonstration.
It's understanding your audience and teaching to how they learn and interact.
That's an entirely different skill set.
Hint: Never come to an inservice without food or your product will never be used.
Myth 3: "If We Can Support One Hospital, We Can Support Ten."
One implementation is easy.
You throw people at the problem.
You answer every phone call.
You solve every issue immediately.
Everyone feels supported.
Now try doing that across ten hospitals simultaneously.
Suddenly your best clinical specialist is in Boston while your biggest customer in Dallas needs immediate support.
Your implementation lead is already booked.
Your engineers are getting pulled into customer training.
Your founder is troubleshooting software from an airport lounge.
This is where companies discover the difference between working hard and having an actual operating model.
Scaling doesn't expose product problems.
It exposes process problems.
Myth 4: "We'll Figure It Out."
This one is my favorite.
Mostly because it's responsible for so many preventable disasters.
"We'll figure it out."
Translation?
"We haven't built a process yet."
Hospitals don't reward improvisation.
They reward consistency.
If your field team is making up the deployment process at every site, your customers know it.
Usually before you've finished introducing yourself.
Now, you might be thinking, "Hold on...didn't you just spend the first part of this article describing a deployment model that sounded suspiciously like 'we'll figure it out'?"
Fair question.
To an extent, I did live in that world. When a capital rep calls and tells you a robot is showing up tomorrow with little more than the truck driver's phone number, there's always going to be some improvisation.
But here's the important distinction.
I wasn't improvising because there wasn't a system. I was improvising within a system.
There were standardized onboarding workflows, established clinical training programs, technical documentation, experienced field support, escalation pathways, and people I could call when something inevitably went sideways. The hospital might have been different every time, but the foundation wasn't.
That's the difference between adapting to a customer's environment and making up your entire deployment model on the fly. One is part of the job. The other is a business model that doesn't survive growth.
What Actually Scales
The companies that consistently grow aren't necessarily the ones with the best technology.
They're the ones that make implementation feel almost boring.
Everything is documented.
Everyone knows their role.
Problems have owners.
Escalations have a process.
Customers know exactly what happens next.
Ironically, boring is exactly what hospitals want.
Predictable beats impressive almost every time.
That starts with having a repeatable deployment workflow.
Every implementation should follow the same basic sequence, even if the details change from hospital to hospital.
That includes IT onboarding, cybersecurity documentation, environment validation, installation, user training, workflow verification, first-case support, and post-launch follow-up.
The more standardized your process becomes, the easier it is to scale.
The less every launch depends on one person's memory, the healthier your company becomes.
The goal isn't eliminating customization.
It's eliminating unnecessary chaos.
Your Training Program Shouldn't Live Inside One Employee's Brain
This happens constantly.
There's one incredible clinical specialist who somehow knows everything.
They know every surgeon.
Every workflow.
Every troubleshooting trick.
Every implementation shortcut.
They're amazing.
They're also a massive operational risk.
Because the moment they're on vacation, out sick, or leave the company, your deployment model leaves with them.
Training should be documented, repeatable, and modular.
Different stakeholders need different education.
A surgeon doesn't need the same training as SPD.
IT doesn't need the same information as circulating nurses.
Clinical engineering doesn't care about the same things procurement does.
If everyone receives the exact same presentation, chances are nobody gets what they actually need.
More importantly, your training should be something another qualified employee can deliver with confidence.
If your implementation process depends on heroes, it doesn't scale.
Your Field Team Is Your Brand
For most hospitals, the field team is the first real interaction they'll have with your company.
Your field team becomes your brand.
If they're organized, confident, and prepared, customers assume your company is too.
If they're improvising, missing documentation, making promises they can't keep, or constantly calling headquarters for help, customers assume your company is held together with duct tape and optimism.
That first impression is incredibly difficult to undo.
Your field team shouldn't just know the product. They should have everything they need before they walk through the hospital doors:
Deployment checklists
Training materials
Troubleshooting guides
Escalation pathways
Version documentation
Customer handoff procedures
Nobody should be figuring things out in front of the customer.
Because customers can tell.
They always can.
The U.S. Commercial Reality Nobody Talks About
One thing that's become obvious after working with international MedTech companies is how differently hospitals operate around the world.
Many European hospitals, particularly in robotics and enabling technologies, expect to become relatively self-sufficient. The goal is to train the team well enough that they don't need a company representative standing in the room every time the technology is used.
The U.S. often looks very different.
American physicians and hospital staff generally prefer to stay within their defined responsibilities. They don't necessarily want to troubleshoot your technology or become experts on your software. They expect your clinical specialist to be there, especially during the early cases.
Neither model is right or wrong.
They simply create different business models.
If every case requires one of your clinical specialists in the room, your ability to grow is directly tied to how many clinical specialists you can hire.
You stop scaling based on demand.
You start scaling based on headcount.
That's an expensive realization to have after you've already signed ten hospitals.
Your deployment strategy needs to account for that before your sales team starts accelerating.
Otherwise, you'll build a commercial engine that can sell faster than your operations can deliver.
That's a frustrating problem to explain to investors.
Strong vs. Weak Deployment Models
A scalable deployment model doesn't have to be complicated.
It just has to be intentional.
Strong operating models look like this:
Documented implementation workflows
Standardized IT onboarding packages
Role-specific training programs
Clearly defined response times
Escalation pathways everyone understands
Consistent customer experiences across every site
Continuous feedback into product and training improvements
Weak operating models usually sound like this:
"We'll figure it out when we get there."
"Ask Sarah. She knows how to do that."
"I think IT already has that document."
"I'm not sure who's handling training."
"We'll make something work."
One scales.
The other creates burnout.
Build the System Before You Need It
One of the biggest differences between successful MedTech companies and struggling ones is that successful companies build infrastructure before they desperately need it.
Document every step of your implementation process.
Create training materials for every stakeholder group.
Build IT onboarding kits.
Write troubleshooting guides.
Define ownership for every stage of deployment.
Measure implementation timelines, training completion, support tickets, and customer satisfaction.
Then review those metrics after every launch.
The goal isn't perfection.
Hospitals are messy.
Things will always go wrong.
The goal is making sure the next implementation benefits from what you learned during the last one.
That's how organizations scale.
Not by working harder.
By getting smarter.
The Bottom Line
Operational scalability isn't about hiring more people.
It isn't about having a larger support team.
And it definitely isn't about hoping your best employee never takes a vacation.
It's about building a deployment engine that produces the same high-quality customer experience whether you're launching your first hospital or your hundredth.
Hospitals don't reward companies that promise the most.
They reward companies that consistently make implementation feel easy.
Because easy feels low risk.
Low risk builds trust.
And trust is what turns one successful implementation into ten more.
Great technology might get you the meeting.
Great commercialization might get you the contract.
But great operations are what turn customers into references, references into new customers, and early traction into a business that actually scales.
Build the engine before you need it.
Because once your sales team starts doing its job, the last thing you want is your operations becoming the bottleneck.
Next Week: Step 9 - Customer Success, Expansion, and Retention
Signing the contract is only the beginning. Next week we'll talk about what happens after go-live, why your first customer is your most valuable marketing asset, and how the best MedTech companies turn one successful hospital into five without adding another dollar to their acquisition budget.
Want to know how operationally ready your company really is?
👉 Take the U.S. Commercial Readiness Self-Assessment and see whether your deployment model is built to scale... or just built to survive.
Curious about the other 11 steps to recovering your medtech business? Click here to learn more!
About the author
Robert Law is the founder of Metamorph MedTech, a go-to-market consulting practice built for medical device and healthcare AI companies that have cleared the FDA and now have to figure out what comes next. With a Kellogg MBA and hands-on experience across surgical robotics, implantable devices, and AI-powered platforms, Robert works in the space where great technology meets commercial reality: health economics, hospital sales strategy, VAC navigation, reimbursement positioning, and the kind of go-to-market infrastructure that turns pilots into revenue. He started Metamorph because too many good technologies were losing to bad commercial strategies, and that bothered him more than he could ignore. Learn more here.
Comments