Step 4 of 12: Productization & Technical Readiness

There's a sentence I hear from founders that tells me almost everything about how their U.S. launch is going to go.

"We're FDA-cleared. We're ready to scale."

That's usually the moment I know the next six months are going to hurt.

Clearance means your product is safe and effective under controlled conditions. It does not mean it's usable, integrated, supportable, deployable, or anything a hospital IT director would describe as "ready." Those are different problems entirely, and the FDA was never grading you on them.

Most post-clearance failures aren't because the product doesn't work. They're because the product was never productized.

Steps 1 through 3 dealt with your evidence, your documentation, and your economics. This one is simpler and somehow more painful. Does the thing actually work in the building?

What Productization Actually Means

Productization is the messy middle between "we built something impressive" and "a health system can run this at scale without calling you every Tuesday."

It's the unglamorous stuff:

• Real-world usability

• Reliability under load

• Integration with the systems already living in the building

• A versioning strategy that doesn't involve crossing your fingers

• Documentation that survives an IT review

• A support model that doesn't depend on your lead engineer answering Slack at 11pm

Here's the part founders resist hearing. Hospitals don't adopt innovation. They adopt predictability. Stable, supported workflows of the boring kind they can trust at 2am.

Anything less becomes a pilot. Then a fond memory. Then a line item nobody renews.

The Three Truths Founders Keep Underestimating

First, your first working version is not your commercial version. Early builds are fragile by design. They were built to prove the thing works, not to survive a busy OR, a flaky network, and a scrub tech who has never seen your UI before.

Second, hospitals expect a level of reliability startups simply don't assume. In a clinical setting, downtime isn't an inconvenience. It's a liability with a paper trail. "Let me just restart this real quick" is not a phrase you want associated with your brand inside an operating room.

Third, integration and workflow fit matter more than your coolest feature. If you don't slot cleanly into the systems already running the show, you will get delayed. Not rejected. Delayed. Which, for a startup burning runway, is frequently the same thing wearing a friendlier face. That means:

• PACS

• EHR workflows

• Clinical imaging systems

• OR rhythm and procedural sequencing

• IT security and infrastructure constraints

Miss any of these and you're not stalled because the product failed. You're stalled because the product wasn't ready for the environment it was sold into.

A Story You've Seen Before, Because It Keeps Happening

A founder gets cleared. Installs at a marquee hospital. Within 48 hours:

• The UI confuses the scrub tech

• The data export breaks the second the network hiccups

• The surgeon performs a key step differently than anyone designed for

• IT won't sign off because there's no data flow diagram

• The product needs a patch, but there's no formal release process, so the fix is a developer remoting in and holding their breath

The site finishes the pilot if you're lucky. Then never buys.

That wasn't a product failure. The product worked. It was a productization failure, which is harder to see and a lot more expensive to ignore.

What "Ready" Looks Like in Practice

I'm not going to dump a checklist on you, because the checklist isn't the point. The mindset is.

Ready means:

• Real users, not your engineers and not your friendly beta tester, have run your product in a noisy, imperfect, gloriously chaotic clinical environment

• You have a release process instead of a vibe

• IT can ask for your architecture, security posture, and integration plan, and you hand it over instead of stalling for three weeks

• Your field team has a deployment playbook, so "it should work" becomes "it works every time"

Those are very different promises, and hospitals can tell which one you're actually making.

A few quiet killers worth naming:

• UX decisions made by engineers instead of clinicians

• Treating technical debt like it's a future problem

• Shipping new features while reliability quietly rots

• Using your engineering team as field support, which works right up until you have three deployments and one engineer who would like to sleep

UX debt becomes support debt. Support debt becomes the reason your sales cycle tripled.

The Bottom Line

Productization is what turns "we built something amazing" into "hospitals can actually use this." That's the entire difference between a cleared device and a commercially viable one.

The companies that win in the U.S. aren't just the most innovative. They're the most predictable. Stable, documented, integrated, supportable, and ready for the weight of real deployment.

And I'd rather help a founder get productization right early than get the call after a flagship pilot quietly flatlines. One of those conversations is strategy. The other is a postmortem.

Next week: Step 5. GTM Strategy & Infrastructure

The commercial backbone that founders ignore until it's too late

👉 Take the U.S. Commercial Readiness Self-Assessment to see how prepared you are.

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.