The a16z Show - a16z Podcast: So You Wanna Build a Software Company in Healthcare?

Episode Date: April 25, 2019

with Jorge Conde (@JorgeCondeBio), Julie Yoo (@julesyoo), and Hanne Tidnam (@omnivorousread) Building a software company in healthcare is hard -- and comes along with unique challenges no other entrepreneurs face. In this conversation, a16z bio general partner -- and previous founder of genomics company Knome -- Jorge Conde; and a16z bio partner and former founder Julie Yoo (of patient provider matching system, Kyruus) share their mistakes and hard earned lessons learned with a16z partner Hanne Tidnam. Why is this so damn hard? How should founders think about this space differently? What are the specific things that healthcare founders can do -- when, where, and why? You'll wish you only knew this when you started your own company! Stay Updated:Find a16z on YouTube: YouTubeFind a16z on XFind a16z on LinkedInListen to the a16z Show on SpotifyListen to the a16z Show on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Hi and welcome to the A16Z podcast. I'm Hannah, and this episode is all about building a software company in healthcare. In this conversation, Jorge Kande, A16Z general partner in bio and healthcare, previous founder of the genomics company, Nome, and Julie Yu, partner on the deal team for the bio fund, and previous founder of the patient provider matching system, Kairus, explain what it is that makes building a company in the healthcare space so fundamentally different from in other sectors. And why exactly it's so damn hard? So let's start with basic. just the very fundamental difference between building a software company, full

stop, and building a software company in the healthcare space. What are the most foundational crucial differences? Well, historically at least, software had two very important sort of qualities in health care. The first one, the actual quality of software deployed in healthcare system historically has not been great.

User interface wise and experience wise. Bad track record. Bad track record there. And the second one is that it was usually not highly valued. So at least a lot of times it was considered either free or cheap. And why was that? From the very beginning, there was not a lot of value attached to this.

On the healthcare system, a lot of things still have a very human component to them, automating things and sort of creating frictionless experiences or delightful experiences, the things that software is really good at doing, it's just really hard to do in the healthcare system. The second one is, I'm going to generalize for a second, but I think a lot of times in the healthcare system,

software is sold as a component of a broader service or of a broader offering. and so therefore it's the piece that tends to get sort of devalued first because it obviously has the lowest marginal cost. It's going to create this weird dynamic for software companies that are trying to build in healthcare. There's a higher degree of sensitivity in this particular market for things that get in the way of the patient provider experience.

One of the challenges slash opportunities within healthcare is that it tends to be much more risk-averse when it comes to adoption of new technologies. One meaningful difference in introducing a software product to this market versus other markets is the level of scrutiny and the bar that you need to hit from a, you know, not even usability perspective, but just utility and actually having validation of if you are going to introduce something new into the care delivery flow, it better work because the stakes are so high, right?

If you get it wrong, you could either send a patient in the wrong direction or they might not get the care that they need or could actually harm the individuals involved. So not just higher barrier to entry, but higher stakes immediately. And you have a reticent buyer, generally speaking. they're running on very thin margins if we're like selling into the healthcare system into provider space and it needs to work

because if it doesn't obviously there can be patient harm and so you know the probability that a newcomer an upstart can come in and sort of make that case in a convincing way is a very very difficult challenge so does that mean you have to have certain prerequisites that you may not need to have

in other spaces if you know you have these challenges and you know that you're entering this space with a lot more barrier to entry and a lot higher stakes like are there certain things you need in place, you know, a certain kind of proof of concept that you might not have to have otherwise. Well, first of all, I think you're touching on a very important thing, which is in the space, and I'm going to specifically focus on sort of the health care system. So let's call it provider systems, payers, and the like. You have to really understand what the workflows are,

what the problem space is, you know, and how to actually address any of those things. And so one of the biggest challenges I think that companies have when they want to build software products here is to really understand what problem they're going to solve. Because I think you have this weird sort of intersection between it's very non-intuitive. It's still very human-driven and centric. They're regulatory barriers. You don't want to get in between, say, a provider and a patient. You know, most people aren't born with the ability to say, like, I know I can insert a piece of software into this part of the workflow and I will solve an acute pain point for the system. Like, that's not obvious. Yeah. And some of that is actually lack of standardization. You would

think that medicine is an industry that has a tremendous amount of standardization and protocols around how people make decisions and do things. But it actually turns out that healthcare is an industry that actually is characterized by a tremendous amount of variation. And variation in what kinds of ways? It could be variation in terms of actually literally the decision that if you have 10 doctors who are all presented with the same patient, you might see 10 different decisions about how to treat that patient. Some physicians might be more aggressive about using invasive surgical techniques versus others who are are more holistic, even just how I was brought up religiously or culturally might impact the way

I think about that problem. From a product perspective, you could have multiple drugs that all treat the same condition, that all have different implications and whatnot. So even there, even though you have a patient population that is characterized by the same diagnosis, you could have dozens of different ways that those patients play out. And so it makes it very hard for a technology company to come in and sort of generalize and say, you know, there is one single method for, you know, manufacturing this thing or for making this decision and managing this patient population, ultimately that reflects as differences in the financial profile of different patients.

Healthcare, it's like politics. It's very local. Thinking that you're going to have an out-of-the-box, one-and-done solution, even in systems that look similar from either a size standpoint or a reach standpoint or even a geographic standpoint, these are all kind of end-of-ones. So what does that mean? So we have kind of knowledge of workflow, the knowledge of variety and spectrum, and that you are ultimately working in weirdly an N-Equels-1 scenario. I want to bring it back to like actual

practicalities of this sort of company building. In your experiences, you both founded companies, what do you wish you had known or done differently from the very beginning, given the complexity of that space and the unique challenges that building a company in healthcare presents? With Chiris, one of the products that we had was a product that was used by call center agents in hospitals. And our thesis when we first launched the product was, oh, well, we're just going to go after every hospital that has a call center, and they probably all operate similarly.

And what constitutes the job of a call center agent is probably relatively homogenous. And so we can make all sorts of assumptions about how it's built, how it's deployed, and how it's managed over time. The thing that strikes me already is that feels like a reasonable assessment of the lay of the land. Yeah, and especially, I think it's very easy to get fooled in health care by looking at other industries and seeing how. how it works in the rest of the world. And then you pull up the...

Yeah, and then you pull up the wool and it's like, oh, it's completely opposite. Call centers, I mean, that's definitely an industry that if you look at retail or even, you know, all the airline companies and how they operate their customer service operations tend to be pretty standardized and pretty sophisticated in a lot of cases. When did you start to realize this wasn't maybe your average call center? Like on day one. First of all, there's heterogeneity in the actual scope of services of pretty much every call center

that we encountered. Some call centers might be fully centralized, and they're like a central 800 number that receives every call that comes into the hospital versus others that are decentralized that only serve the primary care line versus the cardiology line versus the dermatology line. And because of that, they will have just fundamentally different starting points of where they have to be in the workflow for the thing to work. The other aspect is the scope of functions that the call center plays. It could be everything from just a general marketing service where a customer might call in and say, do you provide the. kinds of services, can you give me directions to the clinic, all the way to, I need a prescription refill, I've been diagnosed with this thing, I need to figure out what kind of surgery I need. So again, much bigger range of possibilities, basically.

When you boil that down to like, I'm a call center agent and how do you define my job so that when I give you another piece of software to use to do that job, it's going to be seamless. And when you have that kind of heterogeneity around, even the sheer definition of what the job is, it makes it very hard to design a scalable solution that can kind of fit into all those different environments. So day one, we actually were fortunate to get a customer that did have a pretty robust, centralized call center group that was hundreds of people who literally were answering

every call that was coming into the health system. And so, you know, the immediate sort of leap that we made was, oh, they must all look like this, even if 80% of it was the same and there was 20% sort of buffer that needed to be modified, we can deal with that. Yes, they all had central call centers, but the fundamental scope of jobs that they were doing were completely different across the board.

And some were more clinical in nature, some were more marketing in nature, some were more financial in nature, et cetera. So what were the knock-on effects of that? Yeah, it probably had an impact on, like, go-to-market product design and product strategy, most importantly, the service model of, you could either say we're going to design our software

to be so flexible that could work in any environment, or you could say, we're going to provide services to come train your people to behave in a more standardized way relative to the rest of our book of business. And so we ultimately ended up taking a hybrid approach to both. But the latter, you know, that services approach is something that we hadn't thought about that allowed us to sort of abstract out the variation to some degree, but also provide value back to the customers in a pretty unique way because then we had the best practices for, you know, how it should work. So ultimately it was a good thing, but it was a major fork in the

road, basically. Because there is so much variability, because there's so much localization, the notion of the pure SaaS model where you're just throwing technology over the fence and assuming that it will fit into whatever environment you're deploying it into, that is a moot point in healthcare. You actually do need to think about the services component of things. There was a whole generation of companies that got started a decade ago that took these sort of tech-only approaches and failed to get scale or had to fundamentally pivot their models to actually take into account more of the human element of the service delivery model. I mean, even there's a term for it now, right?

Tech-enabled services is a way of doing things now in digital health that I think is well recognized that it's necessary to wrap the technology with a human component to essentially address and be able to accommodate all the variation that you see across different customer bases. And it changes your cost structure fundamentally. The nature of how we talked about the business and how it scales and even our fundraising strategy fundamentally changed because of that. And so we did have to raise more and give ourselves more runway and think about different ways to manage our margin. It sounds like everything that could have been changed.

It was changed by that. Let's go back to a specific example where you really put your foot in it. Well, so in our experience at NOMA, it was interesting because here this is a company, the sole purpose of the company was to provide software capability to analyze genomic information. And so when you launch that, your assumption is, well, this could be used to power all kinds of applications. It could be used for research, either in academia and industry. It can be used for clinical diagnostics. Flexible. We thought it was very flexible. And so challenge one is, you know, a solution looking for a problem is always a very, very dangerous thing. I think that's universally true.

It's especially true in the healthcare space. And challenge two was understanding exactly where, in the case of the clinical setting, where this technology would be used in the workflow. So here we wanted to go after the clinical labs. That was your initial hypothesis. Our initial hypothesis for an application in a clinical setting, you have technicians and docs that are inside of the laboratory setting, receiving samples, running a test, analyzing the results of that test, generating a report that gets signed off by a lab director that goes back to a physician. Usually it's in the form of a diagnosis, right? And it gets signed off and it goes to the physician. The physician now takes that report and basically decides what to do based on that information. So our assumption was, well, if you have the ability to sequence DNA now in a way that you couldn't before, before you'd have to do all of these specific tests, you have to know what to test, and then you'd test it, and then you'd get a report.

You have to know what street lamp the keys were under, right, like there in that case. Whereas once you had the full genome, you could just sequence everything and just run a bunch of software queries. So our thought going into this was, well, that's an incredibly powerful tool for clinical labs, because first of all, you can sequence just once and analyze over time. Right. Again, it seems like a totally legitimate assumption to make. And it turns out that there was a lot of challenges with that assumption. The first one is every lab is different.

A lot of them didn't have the budget or the willingness to basically pay the upfront piece to buy the capability to use this technology. Or they didn't have the ability to sequence everything up front. Even if all of the subsequent queries would be technically free later. Why not? The way they're reimbursed. Oh, how fascinating. Too expensive, basically.

It's two expenses. So even though theoretically there's an ROI, a return on the investment of sequencing up front, just the way the industry structure, the way reimbursement flows, the way payments flow, it just didn't make sense for a lot of labs to do this. So how was that not just a complete roadblock at that point? It was a big roadblock. So what that required us to do was to then focus on clinical labs that had the ability to make certain investments in upfront costs. And those tended to be very sophisticated labs that do a lot of research work in addition to patient care. And they tended to be on the sort of on the bleeding edge. And they wanted to incorporate new technology and they were great partners and all of that.

But then it goes back to your end of one problem. So you sell something into that lab and you go next door. And next door has a totally different set of capabilities, a totally different set of constraints, It's a totally different set of expectations. And so therefore, all of a sudden, the solution you created for Lab A is not relevant or unattainable for Lab B. Now, to just add to the stepping in it, you know, when you're analyzing genomic data, there's a massive amount of computation required. And so we went in there assuming, well, this is easy. We're just going to shoot all of this up to the cloud.

We'll run the analysis. We'll send the data back to the lab. The lab could verify it, generate a report, and off we go. it turns out labs weren't comfortable sending data up into the cloud, full stop. At that time, it was just completely... Arguably, even today, arguably even today in 2019, but definitely at that time, we probably should have known that earlier. That would have changed how we thought about going into the clinical lab space.

How would you have done your homework? I mean, what would that have actually looked like? It was frankly, I think just defining the specs of what would be required to bring in our technology. Because I think people intuitively know that genomic data is massive. But, you know, I don't think they know sort of the level of computation required to run the interpretation. Right. So like really running the numbers. Running the numbers for them. And by the way, we tried everything. I mean, we brought representatives from AWS that could show them that they had a HIPAA compliant cloud, that they had received all the certifications.

And it came back to risk aversion. So someone, the lab director saying, like, look, I'm sure all of that's true. But I'm not going to risk sending all of this data up into the cloud. So that was a big, big challenge for us. And it ended up being a major limitation for our ability to. expand into the clinical setting because of all of those barriers. So what did you do? We had to do a plan A and a plan B.

And so the plan A was we assumed that there would be a couple of forward-looking labs or forward-thinking labs that would be willing to work in the cloud environment, much easier to deploy there. The plan B was we had to create a box. We had to create a box, and the box had to have essentially the computation of capability. A gnome appliance. Yeah, we had a nom appliance. Yeah, I remember that. Oh, my gosh.

Because they didn't want the data to go outside. And it's for the reasons that we'd expect. There's regulatory, there's risk associated with that today in 2019. In fact, the companies that have managed to use this technology have taken the sort of full-stack service approach. So that sort of high-low strategy became the approach is get folks to deploy into the cloud when they were willing to. And in the case where folks needed an appliance, we basically had to go to labs that had

enough sample volume that an appliance made sense for them and make basically the case there from an investment standpoint. So again, multiple choice, variety and addressing in different ways. A pure software company in healthcare is a really hard thing to do. Because on the one side, you have this challenge

that it's hard to create a sort of a solution that's going to fit everyone. And therefore, you need to have some level of services around that software. That's on one extreme. So you need to have humans

in the process or in the loop. And then the other extreme, if it is pure software, then it's considered that it should be free. So it's very hard to abstract value. That's so interesting. Do you think that's shifting at all with the kind of understanding of the importance of data and some other things?

Yeah, look, I would argue it's shifting on a couple of axes. The first one is data is becoming more and more valuable. Historically, data was viewed as being either too small in terms of its impact, too narrow, too dirty, et cetera, et cetera. Too difficult. Yeah, too unstructured. So that historically has been the case. So if you have ways to ingest data and clean it and make it meaning, then I think that is valued.

Probably the most public one is what flat iron was able to do and ultimately getting acquired by Roche for $2 billion. That's viewed as using an electronic medical record to capture patient experiences, take that information, and give researchers the ability to drive valuable insights from that. That's a relatively new thing. So I think there is the ability to create value there.

So I think that's one axis. I think there's a general shift in the model that having a tech-enabled service can be a valuable thing. and if done well can be a scalable business. In other words, if you know what you're trying to build and if the software layer reduces sufficient friction in the system and allows you to add people not linearly as you scale, but in a leverageable way,

then all of a sudden you could have tech-enabled services that can grow and become large businesses. So leaning into what it is that makes it difficult almost and then scaling that, leveraging that. Exactly, finding ways to make that scalable. That's not easy to do, but I think it is now doable in a way that it probably wasn't. and say a decade ago.

Yeah. And I think we see that same trend actually happening in the consumer world where you used to have a bunch of services like the marketplaces that were purely tech and we're just matching supply and demand and then getting out of the way, whereas now you see a lot more services like in the real estate market where they're actually managing properties. We're actually going to clean the place and make sure it has good furniture and all that kind of stuff. I think the same premise holds true in health care where you realize that in order to truly make an impact, you kind of have to own certain parts of the full stack. that's what you see playing out in the rest of the world as well.

Okay, so we've talked about kind of knowing the workflow and the complexity of the system, running the numbers and specking it out as concretely as possible. How about in terms of team building? Are there ways that you knowing what you knew down the road that you would have changed how you thought about building the team from the very beginning? My prior experience was not in healthcare. And so a lot of my views on how to do these kind of things were informed by a company that was just a pure enterprise software company.

and one of the mantras was you want to, in the early stages of a company, hire for all-around athletes and just people who are utility players who can roll with the punches and figure it out. It doesn't matter what kind of experience they had as long as they're scrappy, intellectually motivated people, they're going to figure it out. So it certainly took that approach when we started Chiris and hired folks not necessarily from health care who maybe had some engineering experience or sales experience from elsewhere in the world and said, we're just going to go in there and figure it out. But you surely had some deep experts in the space as well.

So my co-founder is a physician by training. So we had sort of a deep clinical knowledge. But I would say actually we didn't have that many people who knew the specific market that we were going after. And that's another characteristic of healthcare startups is health care is so massive that when you talk about market segment, you have to be very specific about what you're talking about.

So like when people come and say like, oh, I have a company that sells to providers. I'm like, that's great. That's like, you know, 20 billion. Like there's 20 billion ways that you could describe providers. Like, are you selling to hospitals? Are you selling to health systems? Are you selling to individual practices?

And each of those can be multi-billion dollar markets in it of themselves. I used to work in publishing and it reminds me of people who would pitch their books to us and be like, it's for the general reader. And you're like, there is no general reader. There's like somebody who likes to read Amy Tan. There's somebody who likes to read like, you know, Dan Brown or whatever. Like these are different people. Yeah, there you go. So, yeah.

So basically, we had folks in our. company who had quote-unquote healthcare experience, but maybe it was from the pharma industry or from payer or even like a different segment of the provider market, but not the specific market that we were going after, which was like a very esoteric. We were going after the biggest health systems, like the top-down approach in the enterprise space. And there's very specific characteristics to those organizations that are very different than even smaller hospital networks. The areas of the team building exercise that I wish we had been more thoughtful about were, you know, in terms of customer-facing roles where it was the team responsible for managing the customer relationship

longer term. Just how important it is for those people to have some kind of understanding and empathy and ideally experience with the kind of people that we were servicing. There is total merit to saying, actually, we need some insiders who might not have any technical skills whatsoever, but can help us understand the culture and the politics and what it means to even talk to a physician. We had a bunch of folks who had never been in health care who walked into meetings and called doctors by their first names

and that was a complete taboo in certain cultures where you have to call them Dr. Jones or Dr. Smith. Like Stranger in a Strange Land guide of like, here's the language here. Yeah. So I think from a team building experience, one of the biggest lessons that we certainly learned was a valuing healthcare domain expertise

earlier in the evolution of a company relative to other sectors. And then also thinking about where that makes sense, what functions that makes sense? Because it's not 100% universal. statement across the board. I would say our engineering team. It was actually better that they came from outside of health care. So in specific areas of where you need the knowledge and where you don't. Why was it a bad thing for engineers to have that? Not a bad thing per se, but you wanted

people who could really think out of the box and not be sort of married to the way it's done today because actually that's exactly the point of building companies in the space is to not do it the way it's been done. And so most of the technology systems that are in place are written on super legacy technologies and don't have things like APIs and whatnot. You need to be super creative about how to get into these systems and get data out because they were fundamentally not designed to have liquidity around the data that's stored in them. And so it was helpful to have people from the financial services industry, for instance, who had figured those things out with similar banking systems and whatnot

and could kind of bring some of that creativity to the healthcare space. So engineering is definitely a space where I felt there was a positive to not having that healthcare domain knowledge, but certainly, the commercial side of the business, I think it's critically important. Making sure that the engineering team is as modern as possible is the most valuable thing you can do for your company. Because I think what's generally true and probably definitely true across the board is that healthcare, the data sets are so complex, right?

They're complex in terms of their variety. They're complex in terms of their volume. They're unstructured. There's regulatory requirements. There's so many things that are challenging from a data handling standpoint. So building the pipes in the most modern way possible, absolutely critical. Whoever's customer facing, I think, has to be from that game, has to understand the space, has to understand who the customers, has to understand the cultural norms and all of those things.

So you need both from the get-go. You need both in the get-go. Industry-specific on the customer spacing side and domain expert from the engineering side, right? And then let's talk a little bit about the middle, the product, right? That's where the sausage gets made. Totally. I'm going to be biased because I was the chief product officer of my company. And that's where I would say it was split, where I do think it's important for the

leader of that organization to have a pretty deep understanding of the market. And so I happen to have had healthcare experience, not specifically in this particular segment per se, but I understood some of those cultural nuances and just dynamics of how the market worked to be able to set strategy. Below me, however, some of my best product managers were not healthcare people at all. And, you know, in fact, we had three products, one that was the call center product that I mentioned earlier, where, you know, the end users themselves were not health care people, right? And so these guys, some of them were like high school graduates who go home and they use their iPhone and they're used to all these modern technologies in the rest of their lives

and then they come to work and they're faced with these totally esoteric, crappy, hard-to-use systems and so I wanted someone who actually had kind of a consumer mindset. Did you find yourself doing a lot of sort of explaining and educating though to bridge that gap? Yeah. My philosophy was to throw them in the deep end. As part of the onboarding experience at Chiris, you had to visit a hospital call center and they actually let you listen in on calls. It was like a religious transformation for these team members who went.

Some came back and said, I cannot believe that this is how these organizations operate, right? Because everyone thinks of health care is very pristine. Like, I'm going to trust you with my life. And they'll come back and be horrified because, you know, they see that things are being run on paper. And just how much burden they put on the customer, right? Because part of what you hear when you're listening in on these calls is like asking the patient, what do you want to do. And the patient's like, well, why would I have understood? I'm calling you guys in the hospital.

you're supposed to tell me what to do. So that was one reaction. The other reaction was completely emotional, right? Because a lot of these patients who were calling in had just been diagnosed with cancer. And they have no idea what they're doing. And they're calling because they need help. And then the call center agents sometimes felt helpless because they didn't have the tools or the workflows or the information. It reminds me of like a 911 operator with like no training.

Somebody thrown into the middle of like I'm having a massive life crisis. Yeah. It was inspiring and motivational. And so that became part of like our training process was to just go out. there and see it versus me explaining it. That's really interesting. Okay, so what about timing? Do you think it's different in the healthcare space, how you think about what's the right moment for your product? One of the big challenges in healthcare is this idea that you can be too early. You can be too early for a couple of reasons. One is you need a lot of changes to workflows for the entire system to

become much more modern. But you think this is different from being too early with like Pets.com. That's a good question. So look, the way I would think about it, I described what was for us at the company, a very obvious evolution of where genetic testing would go. You would sequence everything first,

and you would test multiple times in silicon. You could see the light at the end of the tunnel. I mean, that's a clear future. And so the question is, when is the system ready for your particular solution to a problem that everyone agrees exists, right? Everyone agrees that we have to do a better job

at being able to diagnose folks with genetic disease. And I think everyone would agree that using genomics, the ability to do this at large scale, to query multiple times, to use software, to make intelligent queries, would be a very powerful tool,

a very powerful solution for that. But the reality was, continues to be, that just the structures of the industry are such, even though that's where I think we will end up, it's just not ready for it now. And I think this is true for any entrepreneur, right? Timing is a big part of anything you do. I think timelines are especially warped in healthcare

because it just takes a long time to adopt new technologies. There actually is a peer-reviewed study of the average number of years it takes for new technologies that are introduced into the medical setting to become mass market adopted. Oh, how fascinating. Wait, wait, let's guess. Two years. 17 years. No! Well, I mean, we saw fax machines.

That's true. We saw fax machines. We still use the same. But we're not talking about when technology leaves. But you're right, it's the same thing, really. Yeah, when it gets replaced. You can think about it as all the things that have tried to replace the fax machine or not yet mass market adopted. And it's the same. You could see it in, I think the study actually focused primarily on stethoscopes and like, you know, thermometers and things that like literally have not been redesigned for hundreds of years because it's been so hard to disrupt them. Over the last

17 years, there's been like a bazillion better versions of the stethoscope that we are just not seeing. The wheel could have been reinvented but better. Absolutely. Those are like the tangible examples, but the same applies to software and technology. And that's a lot of the reason why you see the market leading companies that own the EHR space today are literally 45 years old. And by the way, those companies also didn't hit their stride until like 20 years into their journeys, right? So time functions completely differently, basically in this system. It's almost like and second of all, it's an incredible testament to like the strength of these systems that, you know, totally. Yeah. It's like once you do make it, it's totally sticky, right? The LTV, essentially,

of tech companies that actually, you know, make it and get to a certain level of scale is through the roof. There's no incentive to rip them out, right? Because if they work, they work. The switching costs because of all the human and cultural elements that we described is huge. Yeah. So the longevity of your company, if you're looking at success, is also incredibly promising. Yeah. I mean, certainly at Chira, the way we mitigated it was we thought about what our fundraising strategy would be to give ourselves enough runway to have that model play out. We needed to fund, you know, the sales cycles and the adoption cycles to create a new category of solution that didn't exist. Did it to hang out in the wormhole for a while?

It's a big oxygen tank. Yes. Nothing meaningful happens in health care in under three years. And so you kind of have to give it some runway. This is one of the things that we've spent time talking about is, you know, what does a minimum viable product in healthcare look like? Doesn't exist. Big bang, you've got to go in and you've got to create a category and you've got to get that adopted. I think in other industries you can sort of quote unquote get away with having a product that does one thing really, really well, right? And then start there and yes, expand over time, but at least you can get buy-in to prove your value with that initial use case. I think going back to a lot of the points you made earlier in healthcare, when you're in the flow of

impacting a patient encounter and saying like you're going to rip something out or change the way that you're doing something or what have you. You have to make sure that it's going to give you the right answer, so to speak. And so even if it's just one feature, it might mean, okay, yes, it could be one feature, but you have to be integrated into seven different systems to make sure that the data flowing into that one feature is enough to inform the right outcome or decision. So really fully baked. If a transaction falls through the cracks while you're doing some kind of revenue cycle type encounter, like you might not get paid for a preceptive. that could have a severe impact on your bottom line.

You need more funding, you need to think differently about your strategy for product and what that footprint looks like. You have to have the full solution. And the related point I would make to that is it's really hard to have a point solution, even if that point solution is very, very good. I think people in general in the healthcare system are looking to buy a complete solution. So if you take the problem from A to B to C to D, that's great, but someone they need A to Z.

And they can't get A to Z from you. It's very hard to get them to buy A to C from you. I'll go even further than Julie, I will say not only does MVP not exist in health care, I would argue that product market fit doesn't exist in health care. What do you mean by that? You know, the definition of product market fit is when the right product meets a good market, right? All of the things we talked about create such distortions in the marketplace that by the time you actually get through all the hoops, you have such a sort of skewed product.

It's not really product market fit. It's almost like accepted product capture. Here you have, you know, regulatory issues, you have pricing concerns, have incumbents, you have, you have so many aspects that sort of distort the market that I would argue that you don't have a normally functioning market for software in healthcare. How would you both embrace that distortion early on and not get completely sort of knocked off your path by it? Because it strikes me that a lot of what you're describing is kind of like know thyself, like know yourself very deeply.

Oh, it's a tagline. That was known by the way. Oh, was it really? That's really funny. I did not work that in for you. But also, like, know where you're going and do that kind of like deep, I want to say, like, soul searching, you know, on a company level and, like, build out accordingly. So how do you get that big center of gravity of really knowing yourself, knowing where you're going, but, like, be able to be flexible with that distortion along the way? The only North Star you can have, and this is going to sound cliche, but really understanding your value proposition truly from the customer standpoint, it becomes a critical, critical sort of guide for what you do. And this is a debate that healthcare companies have all the time, which is, should your value proposition be,

I'm going to save the system money because, you know, the healthcare system is very inefficient and it runs on very low margins generally. Should it be that I am going to result in better outcomes for patients? Is it going to be, I'm going to create some sort of a lift in terms of return on an investment. There's a bunch of different ways you can think about value proposition. If you don't have that crystal clear from the outset, the amount of obstacles that you are going to hit along the way are going to make it such that it's going to be very difficult to get to. the other side. If you don't really understand the workflow and the culture and the regulation and the governance and the politics and all of the other things, you can have a theory on what the value proposition is, but you need your customer to confirm that early on. And sadly,

the best way to confirm that is to have them to buy something, obviously. Julie and I have had this debate before, which is, you know, a lot of the software platforms that go into healthcare have been sort of predicated on, we're going to cut costs. And I don't know of any sort of solution out that has meaningfully been able to make a very, very strong case that they can cut costs. And by the way, part of it is, I think, is because it's really hard to measure costs. It's almost like a necessary evil where you have to say in some way, shape, or form you are going to reduce costs, but that can't be your primary value proposition. Because at the end of the day, it's a line in the cost structure that can get wiped out over time

and, you know, potentially get commoditized. So is the takeaway know your value proposition as early as possible and test it? That and then have the conversation of like, okay, if we were able to accomplish what we just described, Is it worth it? Is the juice worth the squeeze? Because it's so expensive to distribute product in this market because of the sales cycles and the nature of the enterprise sales motion and whatnot, that if you're not able to envision a path towards being like at least a half a million dollar kind of a year type solution in this space, it's actually not financially worth it to build a business in that area. Right, which goes back to your point of like run the numbers, basically.

At least like back of the envelope, like, you know, whiteboard kind of thing. I mean, is there anything that you can figure out as you go? It sounds like you need to know so much before you begin and be so self-aware and so kind of like have the end game insight. Like are there things that you can leave sort of more organic and like feel out as you go? Yeah, no, I mean, absolutely. There's tons of things you can be doing on a daily basis with end users and just like feedback mechanisms on like how people are, are they actually able to do their jobs, for instance, and making minor tweaks to the workflows and whatnot. So that was always, you know, a component of a more organic and dynamic aspect of how we did things. The other thing that you need to kind of think about doing in parallel is, you know, so much of success of technology in health care is predicated on integrating into other ecosystem players.

And so this is actually probably one industry where you definitely can't, like, just build in a vacuum. You actually should understand, even if it's not, you know, for another few years that you're really going to have to do this, like, who are the players? We just need to get to know so that we're on their radar when time comes for us to take the hammer and, like, try to break down the wall of integration with that vendor that we are on their good side. they know who we are so we can kind of make that happen faster. So things like that, I think you can be doing in parallel to, you know, the kind of formulation of what the footprint of the product is. If you've got the right solution, you can get very creative in how you get paid. So figuring out different pricing structures or value capture mechanisms, I think is something

that you can do pretty organically. Because if you are making a difference in the system, the system has so much cost built into it and so much revenue flowing through it that there are ways to be very imaginative there. So that's the first thing I would say. The second thing I would say is thinking about adjacencies, going from one, your core function to the next adjacent use case, not all adjacencies are created equal. One might be easier than the other.

It's almost like jumping on stones across a pond or something, right? What's the next stone I can jump on that's least likely to make me fall into the water, right? Even if it doesn't get me as far as another one. Right, always have that closer spot insights. You're creating the next thing and the next thing and the next thing, and the next thing, and you build out from there. And eventually, you cover so much surface area that you become a very sticky solution

and you hopefully become a complete solution to closer to the A to Z-type vision. Okay. Last question. Biggest takeaways, quick lightning round for your founder struggling right now. What would you say? Bullet points. Know your market segment.

Be very specific about what segment you're going after because that have major implications for your go-to-market and your product. Good one. All right. Biggest, you wish somebody had said to you. One is build the multidisciplinary. team early. Two is understanding if the person that suffers from the pain point can actually

pay for your solution because there's a lot of misand-life incentives in the healthcare system. And three, with the right technology, you can have massive impact on patient lives and the experience that we have with the healthcare system, which we will all touch in our lifetime. And if there's anything you can do to make it better, as an entrepreneur, I would say that is extraordinarily satisfying. That's fantastic. Those are some good bullets. Thank you both so much for joining us on the A16Z podcast. Thank you. Thank you.