The Three Overlooked Seeds of Innovation Adoption DNA

By Shervin Majd, Ph.D., CPO and VP of AI at Footura Inc.

Note: This is an edited transcript from the MedTech Summit talk Shervin presented on July 8, 2025.

Introduction

I've been in healthcare innovation for the past 20 years. I've done work in biomedical research and medical devices, and the past 15 years have been formally working at the interface of software and healthcare—both as an investor, corporate VC, and angel working with a group in the Bay Area called Life Sense Angels. On the full-time side, I've been doing work more as a product lead for digital health solutions across a number of groups for seven to eight years.

I also try to push for scaling innovation, which is the challenge, especially for me, in large enterprises. I had a chance to work for a large health system and test some of the ideas to fight the odds of scaling innovation. That was followed by another experience with a mid-size company, selling software solutions in this domain to different entities—from state and county to government—trying to test some of those ideas.

Today, I'm sharing three of those critical learnings.

Why Adoption and Scale DNA Matters

Most startups hit a tipping point where early design decisions start to look like technical debt. Think about four stages of growth for your journey as a startup: ideation, MVP launch, commercial launch, and growth and scale.

We should think about where exactly ideation and MVP growth begin and end for our own products. When we think about the first two stages, pre-MVP, how fast is truly agile? We've been getting a lot of teachings about agile being important. I'm a firm believer of that—I've been using Scrum for the past 15 years myself. But at the same time, what is the right speed? Where do you need to mix it with other strategic elements, and how does that balance change? How early should you bake in launch and scale requirements?

The word "balance" is something that, as I work more and more on the startup or enterprise side, I've come to see as a critical point. The balance between agile and scale is something that you have to keep monitoring as you start to work.

Early on, you have to be heavily focused on agile, but you still have some room to pay attention to scalability. You might start at 90% agile and 10% scale, then move to 70/30, and later maybe 50/50. With your scaling growth, agile plays probably a smaller role as you get slower by nature, and other components start driving growth from the scale side.

I'm sure you know about the elements of agile—most of you have dealt with this in the startup world. But on the scale side, elements such as modular architecture design, security foundations, performance monitoring, overall data monitoring, and measurement of the system at each step of the way are critical.

The high-level suggestion is to ensure that you do a quarterly check on this balance to make sure you're not missing a major point on scalability. The question is not just "Are we being agile enough?"—that's a valid question you should ask every day. There's another question that's also important: "Are we being strategically agile for our next growth phase?" One way or another, you have to be ahead of your game.

The Three Key Areas

This is not the complete list—it's a long list of actions when you want to achieve sustainable adoption. But these are the three areas that are not getting enough attention, despite the fact that on the surface everybody's talking about them. On the action side, the efforts are not at the level required.

1. Layer-Specific Communication: Avoid the Fear of Unknown

One statistic: 86% of employees and executives cite poor communication as the main cause of project failure. That's general data, even for large organizations irrespective of partnerships.

Partnership does not necessarily mean when you have your MVP or product. If you need to do some research—understanding your end users, doing UX research, running interviews—those are also the initial aspects of partnership you need to plan for and emphasize. That's what it means to pay attention to scalability from day one.

A lot of times I stumble when one of the layers of stakeholders doesn't have clarity on "What's in it for me?" That's where things can get really difficult and friction points increase. This is what I'm referring to as the "fear of unknown"—if a layer of organization doesn't understand what you're doing, they would generally assume the worst-case scenario: the product is not ready, they're going to waste my time, the learning curve is very challenging, and so on. That's going to be potentially a major blocker for your progress.

Make sure you understand the language of the stakeholder you're talking to. CEOs care about ROI, nurses care about patient outcomes, and IT cares about security. It's critical to be very mindful that all of these burdens are on the shoulders of the BDRs, CEOs, and pre-sales leads doing these conversations. You cannot expect the customer to do all of that work on their own end because they're already busy. They're bombarded with millions of ideas and a lot of free pilots, especially in healthcare. That's why you need to help them achieve the "why" component.

In terms of simple steps: make sure you map the personas of customers and stakeholders you work with, craft outcome-based message metrics, leverage short impactful videos, summaries, pamphlets, or PDFs that you want to share with them to ensure they get the point quickly. Try to do some pulse surveys on clarity as you move on to work with these groups to see if your approach is working. If not, make the adjustments to improve the situation.

2. Cross-Layer Engagement: Beyond Executive Buy-In

The second topic is tightly relevant to the first one. It's very common for startups to find out who's paying for their product and who the main customers are. Is it the CEO? Is it the chief medical officer? Is it the chief financial officer? That's completely a fair and important task.

But at the same time, this does not mean that if the CEO of an entity—even a major entity—has full buy-in for my solution, I'm going to be successful and everybody in that organization is going to just work on this product to get successful adoption. It's actually the opposite.

A lot of examples show that basically the communication and engagement with middle management and frontline users or end users are really missing, and it's important to pay significant attention to that. Another way to simplify this: executive buy-in gets you in the door; middle management and frontline users keep you there.

It's important to think of engagement as vertical—as you go from executives to frontline and end users—but also horizontal with peer champions. This depends on the product situation and verticals as well.

To give you some starting points: identify the champions for every 10 to 15 end users you have, and within each layer, make sure you have the right champions. These are the folks that truly believe in your solution and are genuinely trying to help the cause—especially in healthcare, helping patients. Some of them could also be seeing the right angle for your product to improve ROI margins or things of that nature. Finding them, building relationships, and working together with them is critical.

To the degree that timing allows, try to co-design some workshops with end users and managers and bake it into your onboarding or pre-sales or discovery phases, depending on whatever engagement you have with them. This allows you to better understand current workflows and current pain points, and see things from their perspective. It also lets you show them and work together with them to identify how your product makes their life easier.

Finally, make sure you give credit to folks that are working on this—public kudos, making sure executive shadows and top managers understand who's really doing the work. You can also go a little further and do some micro-grants, help them with some of the challenges. If they need small tablets and that needs 6 months of approval, you can potentially provide it with the approval of the group as it's less than typical procurement levels.

3. Agility and Robustness Balance: Technical Foundations

To make sure this is not confused with my overarching point about attention to scale: here, I'm mostly pushing on technical robustness. From day one, you need to pay attention to ensure that your platform is scalable. Scalable is different than building a full-fledged scale solution from day one—it's just important to make sure you build it in a way that later you don't have to rebuild this platform from scratch and everything becomes a throwaway.

70% of healthcare digital transformations miss their objectives. A lot of these problems go back to these semi-obvious points that are not getting the right action on the field. Fast pilots, meaning you haven't done the right work around security, integration, and uptime—those are examples that need the right attention at the right time.

Overall, you need to have a rhythm of building, validating, hardening, and replicating that process every couple of months. Ensure that you're on top of the needs around technical robustness as much as you're pushing for agility.

Build your product prototype, test and validate with actual users and end users. Success metrics are very important—a lot of groups pay only half attention to that. Doing data-driven work is helpful for troubleshooting, fine-tuning, benchmarking, and improvement. It's also critical for your customers to get a sense of why you're doing this and how things are getting better.

A lot of times customers may not have the current benchmark on their own side. That's also on your shoulders to set the stage for them and show them how things are getting better with your product.

You need to make sure you do load testing and ensure that your platform is ready for the next six months ahead. You don't want to run into trouble with a great adoption that is going very fast. This is very important to build trust with the potential customer and maintain that trust—because if that trust is lost, it's very difficult to bring it back.

Key Takeaways

To simplify these three messages so that you can take them with you:

Every stakeholder should know their own "why."

Organic advocacy at every level.

Fast growth without breaking trust.

Q&A: Handling Sensitive Information During Fundraising

Question: How do you handle making sure everybody knows their role and their "why" when you're limited in what you can share—for example, during fundraising or an acquisition process? People tend to assume the worst if they don't hear from you and there's silence. The same thing can happen in clinical trials where you're trying to ramp up and there isn't a lot to share.

Answer: A lot of startups, when I wear my investor hat, are actually too concerned about this point—more concerned than they should be. Because they don't know what to share and what not to, they're also hesitant to share things that are valuable. That's a very important point because that hesitancy can actually make them lose the deal or lose a partnership.

You have to be clear on what things should stay confidential and what things should be shared and with what type of person. Sometimes if they need to sign an NDA, that's fine too. For investment conversations, at least on the West Coast side, NDAs are less common unless you're doing detailed due diligence.

The other thing I'm emphasizing is to think of this as a major component that starts from day one. Naturally, you should have a lot of content and indirect evidence that shows why your product is working. This could be things that talk about patient outcomes, or how it helps the customer. You can even potentially get permission from customers to be referenced for your investors. There are a lot of ways to do things—I don't think there's a shortage as long as you don't think about this the day you want to go after investors, because it will take some time.

If you started from day one, your question basically proves why this needs to be done early on.