Rockin' HIT Sales Podcast

Podcast / Barry Katzen, M.D.


Why Health IT Pilots Fail to Scale and How to Design Ones That Do


Barry T. Katzen, M.D. is the Chief Medical Innovation Officer for Baptist Health South Florida and the founder and Emeritus Chief Medical Executive of Baptist Health Miami Cardiac & Vascular Institute.

Release Date:

Hosted by David Hacker, CPHIMS | Director, Elevate HIT Sales | MEDDPICC® Certified Trainer

Watch or Listen

Choose your preferred platform:

Also available on all major podcast platforms.

Episode Summary

In this episode of Rockin’ HIT Sales, David Hacker sits down with Dr. Barry Katzen of Baptist Health of South Florida for a practical conversation on why Health IT pilots often fail to scale — and what vendors can do differently.

Dr. Katzen explains why a pilot must begin with a clearly defined unmet need, measurable outcomes, and a realistic understanding of what the health system will need to prove before broader adoption is possible.

The discussion also explores the difference between early-stage innovation, co-creation, supply chain adoption, proof of concept, clinical proof, proof of value, and the organizational realities that can determine whether a pilot becomes scalable.

Why This Matters for Health IT Companies

A pilot should not begin simply because a health system is willing to try a new technology. It needs to start with a clearly defined unmet need, agreed-upon outcomes, measurable success criteria, and an understanding of what the organization will require before it can make a decision about broader adoption.

For Health IT companies, that means pilot-to-scale planning should begin before implementation—not after the pilot produces positive results. Vendors need to understand what the pilot is intended to prove, which clinical or operational metrics matter, who will evaluate the outcome, and what additional organizational, contractual, or commercial barriers could still prevent expansion even when the technology works. Barry specifically separates proving efficacy and value from organizational acceptance and dissemination, describing them as two different problems.

What You’ll Hear in This Episode

  • Why many Health IT pilots never move beyond the pilot stage
  • What health systems need to see before seriously evaluating a new technology
  • Why unmet need, clinical value, and operational relevance matter from the start
  • How startups often underestimate IRB, research, and proof requirements
  • What separates proof of concept from broader organizational adoption
  • When co-development with a health system makes sense
  • Why vendors should involve clinical and health system input earlier in product development

Questions This Episode Answers

Why do so many Health IT pilots fail to scale?

Because a successful pilot does not automatically create organizational adoption. A pilot can demonstrate that a product works and delivers value while broader expansion is still blocked by competing priorities, existing contracts, supply-chain considerations, workflow differences, or other organizational factors.

What should be defined before a Health IT pilot begins?

The unmet need, desired outcomes, success metrics, target users, and the conclusion the pilot is intended to support should all be clear on the front end. Barry emphasizes that pilots should be tightly focused and designed to lead to a determination when they end.

What makes a new technology worth serious evaluation by a health system?

It needs to address an unmet need that matters to the organization, either operationally or through a direct benefit to patient care. Novelty alone is not enough to justify evaluation.

What do early-stage Health IT companies commonly underestimate about pilots?

They often underestimate the work, rigor, and resources required. Depending on the product and development stage, a pilot may involve research requirements, IRB review, clinical evidence, and a much more structured evaluation process than simply placing the technology into use and observing what happens.

What is the difference between proof of concept and proof of value?

Proof of concept demonstrates that the product or idea can work. A health system may also require clinical, operational, or financial evidence showing that the solution produces meaningful value in its environment before considering broader adoption.

Can a pilot deliver strong results and still not be scaled?

Yes. Barry describes a co-created surgical optimization solution that proved useful and commercializable but was not adopted throughout the health system because of competitive considerations. The example illustrates why technical or clinical success and organizational adoption must be treated as separate milestones.

When does co-development with a health system make sense?

Co-development makes sense when the organization is trying to create something that does not already exist and both parties have the patience, resources, and tolerance for failure required by true innovation. Other parts of a health system may prefer technologies that are already proven elsewhere and supported by established evidence.

What does a health system look for in a long-term innovation partner?

Beyond the product itself, the company needs enough financial support, resources, and commitment to sustain the innovation process through setbacks and uncertainty. A promising idea is not enough if the vendor cannot remain engaged through the full development process.

What should Health IT vendors stop doing when approaching health systems?

They should stop trying to market products before those products are sufficiently proven. Barry specifically warns against assuming regulatory approval means the commercial evidence is complete; health systems may still need proof of concept, clinical proof, and proof of value.

What should vendors start doing earlier?

Bring health systems and clinicians into product development earlier. Barry argues that early provider involvement can improve the likelihood that the product ultimately succeeds commercially because the company is validating the need and development path with the environment where the technology will actually be used.

David’s GTM Takeaways for Health IT Vendors

1. Design the scale decision before you design the pilot. Before the pilot begins, the vendor and provider should understand what the pilot needs to prove, which metrics will determine success, who will evaluate the results, and what outcome would justify the next commercial step. “Let’s try it and see” is not a scale strategy.

2. Pilot success and enterprise adoption are two different milestones. A product can produce excellent clinical or operational results and still fail to expand because of contracts, competing solutions, supply-chain considerations, organizational priorities, or differences between sites. Your GTM plan needs to address the adoption decision that comes after proof of value.

3. Provider involvement should start before commercialization. Getting clinical and health-system input early can help validate the unmet need, shape the product, clarify the evidence requirements, and reduce the risk of trying to commercialize something the provider environment is not prepared to adopt. Barry’s strongest advice to vendors is to involve healthcare systems earlier in development.

About the Guest

Dr. Barry Katzen is Chief Medical Innovation Officer at Baptist Health of South Florida, where he leads the Baptist Health Innovations program.

In this conversation, Dr. Katzen brings the inside view of a health system innovation leader who evaluates new ideas, pilots, co-creation opportunities, and commercialization pathways. His perspective is especially relevant for Health IT companies trying to understand what it really takes to move from an interesting pilot to a solution that can earn trust, prove value, and scale inside a provider organization.

Transcript

Prefer to read or download the conversation?