DJ Kleinbaum: Contrarian Truths Empowering Innovation [Entire Talk]

Thank you all for the warm introduction. I'm honored and humbled to be standing in front of you today because when I was here as a graduate student, it was very common for me to plan my experiments on Wednesdays around being able to sneak out of lab in the late afternoon to come to these talks, so it's a little surreal to be standing up here instead of sitting back there, but I hope to share with you some of my experiences from the last 5.5 years or so with Emerald. So I'm gonna do that, I'm gonna just tell you stories about the founding of this company and the work that we've done and how we think about the future and just sort of go from there. Before I get into all of that, I just wanted to lay out to begin with the two themes that I'm gonna touch on probably over and over again. The first is that startups are hard. They're not necessarily glamorous or temporal. If you look at the history of Silicon Valley, the companies that have really changed things, the Intels, the Varians, the HPs, did so not over weeks or months, they did so over decades. And I think that that's something that isn't always appreciated if you just look at these recent history of this area. So taking a much longer view is something that we've always tried to do at Emerald and something that I'm gonna try to reinforce at a number of different points in my talk today. The other theme that I'm gonna come back to several times is the focus not on ideas but on execution. I think that we all sort of love this idea of these sort of brilliant individual who's just like generating ideas and that's where everything comes from, but really if you're gonna do anything significant, it's much more about execution. And you can sort of think of ideas as just a multiplier on top of your team's ability to execute. So I would be remiss if I didn't start by acknowledging the amazing team that we have at Emerald, and a lot of the things that you're going to see today are a result of their hard work. With any company that has any sort of significant length story arc, it's only the first few chapters that really are about the founders. Every one of our team members that we've had during the company's history deserves a chapter in the story of this company. As it happens, the first chapter or two are about my co-founder and I, and that's where we'll start. So our company is called Emerald because in the summer of 1991, my family moved to a house on Emerald Drive that happened to be 2 houses away from where my now co-founder Brian and his family lived. So we've known each other since we were 9 years old and have grown up together, and so one of the reasons that we have such a great working relationship is we've been doing this for the better part of 2.5 decades. As we, when we were growing up, we heard all of these stories about the history of Silicon Valley, and stories about the Trader Estate, and Fairchild, and these companies that were using technology to really change what our day-to-day lives were like. And also during this time, when we were in high school especially, we got very interested at this, about this intersection between computer science and the life sciences. but when we applied to colleges, most places that we went where we told them that we wanted to study at this interface, we wanted to double major in computer science and biology, they looked at us like we were crazy, like why would you study those two things, they don't really go together. So I feel very vindicated that the last two decades or so have more or less proven us right about the importance of that interface. but needless to say, we decided to both go to Carnegie Mellon because at the time, it was one of only two schools in the country that had an undergraduate program in computational biology. So we went to college thinking that we would use this time to learn more about this field and then start a company right when we left. And we had, as we got toward graduation, we had an idea for a company which in retrospect was a really bad idea, but nevertheless we were talking to investors and entrepreneurs, mostly on the East Coast, and just sort of trying to figure out what we could do to get this company off the ground. And the thing that we heard over and over again was that no one will fund, let alone let you run a biotech company, unless you have 3 letters after your name. So after hearing that once or twice or, I don't know, 27 times, we were just like, alright, screw it, we'll go get PhDs. So Brian went to Scripps Research in San Diego, and I came here to Stanford, and I was not a particularly, I did not have a particularly fantastic graduate career, I think my research advisor would agree with me on that, I was a pretty middling graduate student, But the thing that graduate school gave us was the better part of 5 years to vet dozens of different ideas for what our company would do. And not just what we would do, but how we would do it. We spent a lot of time thinking about what a research and development organization in the life sciences would look like if you were starting from scratch in the 21st century. It was really useful during this time to be able to pick up the phone and call someone else, especially after a particularly bad day, and just say, I don't think the emperor's wearing any clothes, and have the person on the other line say, you know what, I think you're right, I do think it's ridiculous that we're using instrumentation that costs hundreds of thousands of dollars and the way that we save the data that comes off of this incredibly complex instrument is we print it out and we glue stick it into a paper lab notebook. Having someone who would tell you that you're not the crazy one, everyone else is the crazy one, is incredibly validating. There's a big difference between being an individual in the room screaming that the world is mad and having someone else going like, No, I think he is right. So that was a really valuable experience for us, and it can't be understated how important, it can't be overstated how important it was to have someone there to have those discussions with. So we got toward the end of graduate school, and again, had an idea for a company, and so we started talking to investors. And the thing that we found out very quickly was that it takes money to get lab space and lab space to get money, and we didn't have either of those things. So we ended up working out a deal in principle with our alma mater, Carnegie Mellon, because somehow there were still people there who remembered us fondly, and we had worked out a deal in principle for access to lab space and some shared facilities and equipment in exchange for what at the time was a trivial percentage of the company. And so we were all set to sort of go back and start this company in Pittsburgh. So Brian wrapped up at Scripps, I still had a couple weeks left, final signatures to get and things like that here, and so he came up, crashed on my couch for as long as he could, but eventually my lease ran out, and so we moved into a Motel 6 on El Camino, which has actually since been demolished, so you can't go find this building anymore, I think it's, something else now. So we were living at this motel, and at this point we had sold or thrown out or given away anything we owned that wouldn't fit into our cars. And so we're just sort of like killing time while we're waiting to go back to Pittsburgh, and literally on the day that we were scheduled to go back, through one of our advisors, we got a meeting with Peter Thiel. And we went, and we were at this point, you have to understand, this is the summer of 2010, and so this was long before Peter and his venture firm Founders Fund published their manifesto. Peter was mostly known as the co-founder of PayPal, and for being the first investor in Facebook. SpaceX had been successfully launching rockets for a couple years at that point, but were not certainly did not have the public profile that they have now, and so we were just kind of excited to meet him and to tell him about what we were working on and to get his feedback, and then we were gonna leave for Pittsburgh that day. So we had this meeting with him at 4 o'clock, and we were hoping to be on the road for Pittsburgh by 8. My goal was to get out of California that night. It was like, if we can get out of California tonight, that'll be a good start to our road trip back to Pittsburgh, That'll be good, that's what we're going to do. And the idea that we were pitching to Peter is not the cloud laboratory aspect that you're probably familiar with. The name of our company is Emerald Therapeutics, and the original idea was this completely novel antiviral platform for curing persistent viral infections, and that probably sounds extremely audacious and ambitious, and it certainly was, and I'm not gonna go into the details of how it works, but needless to say, the work on it is going well. And so we're pitching this antiviral company to Peter, and we get partway through the pitch and he stops us and he says, I think that this is a Silicon Valley company, and I want you to give me a week to convince you that you should stay here instead of going back east. And so we said, okay, and we went back to the Motel 6 and we booked another week, and a week became 2 weeks, and we ended up spending that entire summer living out of our cars in every cheap motel from San Jose to San Francisco while we went through diligence with Peter and Founders Fund, we pitched the deal to other VCs in the area, and we we sort of generally just sort of started to map out what it would be like to be based out here. So it was definitely, this was a, it was definitely a bit of a stressful time. So remember that we were right out of graduate school, it's not like we had a lot of savings, so we're doing this all on credit card debt and moving around from motel to motel every week. I'm sort of an operational efficiency nutcase, I think is the technical term, and the way that we would do things was we would live, we would book a motel for a week, we would, at the end of a week we would move out, we would go to the Stanford Coin Wash, which still exists on El Camino, and we would do a week's worth of laundry, and we would use Hotwire to book the next week's motel, because we had figured out that a week was sort of the optimal time, 'cause if you did longer than that the prices started to go up, If you did less than that, then you were just moving all the time, and that was not really sustainable. This laundromat was actually also our only real, this and Starbucks really were our only reliable sources of internet at the time, so it was not uncommon for us to do video conferences with potential investors or potential hires from this laundromat, and we learned after this, and it was, also pretty common, at least on the weekends, for people to go there and literally wash almost everything they had on. So probably the second time that some half-naked person walked behind us on one of these conference calls, we decided that we should probably just save these for Starbucks. So we're going through this, we're sort of living out of these motels, and I would be lying if I told you, like, this is a very fun story to tell now. But at the time, it was really stressful. I mean, I literally had friends from high school and college calling me saying, hey, I heard you finished up at Stanford, what are you up to now? And the only honest response I could give them was, I'm homeless and unemployed. So this is a picture that, the reason that this picture exists is because one of my mantras during this time was, I'll buy new socks when we raise funding. So my clothes got pretty threadbare during this time, and at some point, Brian's car got broken into and they stole a bunch of his stuff, and it was just a very stressful time, both from a sort of professional standpoint and also from a financial standpoint, really. I mean, I made myself every day go onto my bank's website and check my credit card balance just so I never lost touch with that reality of exactly what this is costing us. But it does have, there is a happy ending to this part of the story. At the end of 3 months, we ended up closing around a financing with Founders Fund as the lead investor, and one of the terms in the term sheet was that the company had to be based between San Jose and San Francisco, so it was sort of decided that we would be a Silicon Valley company at that point. So when we started, I still consider it a minor miracle that we were able to raise funding at all, but the amount that we raised was substantially less than you would normally raise for a biotech company as ambitious as what we were planning with Emerald. It was something like 4 to 5 times less than what you would typically do for a project like this. And we were kind of fine with that, because remember, we had spent the better part of 5 years thinking about how we could more efficiently run a research organization. So there were 2 aspects to this initial lab that we built, and the way that we were going to organize our company. So the first was automation, we were going to, take every experiment and automate it to the point that it was push a button, walk away. And so for you engineers out there, that may not seem that revolutionary, but you have to understand that historically, scientific equipment is designed to have a person standing in front of the instrument while it's running. And so we decided, none of that for us, we're going to make sure that the people that we hire are actually spending their time thinking about the science rather than babysitting machines. And we were helped in this endeavor by a lot of advances in the scientific instrumentation hardware business around something called high-throughput screening. So high-throughput screening is something that pharmaceutical companies do to test literally millions of compounds to see which ones are good leads for new drugs. The problem for us was that most of these instruments are meant, and more specifically, the software on most of these instruments is meant to do the same experiment a million times. But we weren't doing screening, we were gonna use these for one-off experiments, which meant instead of having an instrument do the same thing a million times, we wanted that instrument to do a million different things once each. So that involved a lot of sort of fine tuning fighting with and working around the instrumentation software. So, and that dovetailed nicely with the second sort of key tenet of how we were going to run our company differently, which is that we were gonna teach all of our scientists how to write software. And the reason that we wanted to do that, we were sort of, of course, trained in both of these things, but over about 10 years, we had seen this growing divide as the datasets from scientific experiments got bigger and bigger. There started to be this divide between the people who generated data and the people who could analyze data, and that seemed like a really scary place to be, and it seems like the key sort of breakpoint was once your data got too big to fit in Excel and it had to go into a database, and now you need to write SQL queries, all of a sudden it went over the fence to a bioinformatics expert. And we knew that we certainly wouldn't have the headcount to have a totally separate department for that. And it just seemed both inefficient and just wrong to have the people who were designing and running the experiments not be the people who were analyzing them. So we taught everyone how to write software in a very high-level language. We weren't teaching them how to do memory management or anything like that. We used what was then called Mathematica, what is now called the Wolfram Language, which is sort of like the Cadillac of data processing languages, and it enables you to do some really powerful stuff in just a couple lines of code. So that was the, we had and actually still have a 2 to 3 week training class to sort of get people up and running in using this for analyzing data and doing other things that make people efficient scientists, more efficient scientists. So one of the, the first thing that we did, so we had this team of molecular biologists and chemists and geneticists, and we had taught them how to write software and just sort of like let them loose to build tools to not only do the research, but also build tools to make themselves more efficient. And so the first thing we did was we just built, a database where you could push and pull data from any instrument in the lab. So that's, in most labs where I worked, the data from an instrument just lived on the hard drive where it was generated. And so now everything was pushed to a central database and then anyone could pull down and look at that data. But that wasn't enough. So we expanded that and we built this linked data system pieces of data were linked to the analysis that was done on them. And then over the course of about 2 or 2.5 years, that just expanded to sort of consume all aspects of the lab. So that included inventory management, sample tracking, instrumentation diagnostics, and sort of the last piece of the puzzle to fall was protocols. So we started thinking of protocols as just more data, so our scientists would sit at their computers, they would design experiments, and they would design the experiment that they wanted to run, and then that would generate a machine-readable file that would get loaded onto the instrument in our lab, and then the only time you had to go into the lab at all was to make sure that that instrument had the, the samples were in the right place, and it had enough consumables, and the buffers were hooked up, and that was it, the instrument would then just run by itself and you could actually focus on analyzing data from previous days or what your next experiments would be. And we started to see efficiency gains, because our scientists weren't really spending time in the lab, we started to see efficiency gains, like people running 5 to 7 times the number of experiments that I could run on a given day as a graduate student. They were routinely doing that using this system. So at that point, we kind of looked around and said, there's way more value in this system than we can capture just by using it as an internal tool. We should make this available for all scientists, so people anywhere in the world can use software to enter commands for experiments that will then get run at our central facility, and then we'll just send them back the data along with a whole suite of tools for doing data analysis and visualization. So we, at that point, we actually reorganized the company, so it's very important to point out that we did not pivot, so we didn't go away from the therapeutic, we just added on, we branched. So we added another mission to the company and reorganized things such that we have our, and that exists to this day, we have our research team, and we have our cloud laboratory team. And in many ways the research team is sort of customer zero for the cloud laboratory. So we were really sort of like pushing at the limits of what we could fit into this small lab space, and so last year we expanded into a much larger facility in South San Francisco that we are still in the process of expanding both in terms of capabilities and capacity, and trying to get to the point where we can actually run experiments for larger and larger fractions of scientists. So that sort of takes us up to now. And so what I'd like to do in the second part here is just tell you some stories from both about building culture and around and around just sort of more present-day aspects of Emerald. So there are 3 things that I'm going to touch on. The first is the benefit of having a co-founder. The second is something that I call our contrarian truths, and the third is our fresh eyes journal. So before, to sort of understand the value of a co-founder, You have to understand risk. So every startup that's doing anything remotely innovative is inherently risky, because there are a lot of smart people in the world, and there are a lot of smart companies in the world. So just be, I think it's wrong to think that large companies are not innovative, or somehow not as open to change as startups, as others because there are really smart people that work at these companies, and so there's probably no idea that you'll have that someone else, probably someone at one of these giant companies, hasn't already had. The difference between you as a startup founder, as an employee at a young startup, and them is that you said, I think that's a good idea, I think we should do that, whereas they said, no way, like that'll never work, or that's a dumb idea, or it's like, it's not time for that. So that's really the difference, is that you decided like, where everyone else said no, you said yes. And so that means, just by its very nature, that you're gonna be faced with some suboptimal sets of choices in your decision making, because there's no sort of prescriptive path to startup success. And that's very weird for people, it was kind of weird for me. So you go through high school, you do these things, that will make you a successful high school student. Same thing in college, kind of same thing in graduate school. But with a startup, there is no formula that you can follow that will guarantee you success. And oftentimes that means that you're faced with a set of decisions, you have option A and B, and what you really want is option C, but option C doesn't exist. And so, it's really valuable to have someone who could say, listen, both of these options are bad, but which one is the least bad? And to be okay with, to have someone tell you that it's okay to take a path that you know isn't great, but, that you just sort of have to, it's sort of the reality of the situation that you have to take this sort of like route that you know is not optimal. So that's one of the really valuable things about having a co-founder, just someone who can sort of share that burden with you. And similarly, there's a time, and if any of you are thinking about or have started companies and you're lucky enough to have a good co-founder, I promise you will have this interaction where you will go to your co-founder and you will say, we are screwed. For reasons X, Y, and Z, we are totally screwed, and the sky is falling, and this is it for us. And they have one job in that situation, is to say, it's gonna be all right, don't worry about it, here are the things that we're going to do, we'll get through this, 'cause that happens a lot, and all these things that seem like dire situations end up not being, but when you're so invested in the company yourself, it really feels like everything is a crisis, especially early on. So again, your job as a co-founder is to say, it's going to be all right. One of the other things that I wanted to touch on is something that we call our contrarian truths at Emerald, and this sort of relates back to that idea of risk. So this is not sort of novel to me, I actually think this is something that Peter has talked about publicly before, but it's very important for your company to define the things that make you different from the rest of the world. So by definition, you're clearly thinking about things differently, or else someone else would have probably already done this idea. You've already said, I actually think this is a good idea. So that's sort of the first thing that makes you contrarian. But the other, it's important to establish what those things are for your company and to get buy-in from everyone on those things. So I'm just gonna list the things that are our contrarian truths at Emerald, and you'll notice that there aren't any things here like, quality first, because quality first is, that's a great mission statement to have or a great thing to hold up for your company, but it doesn't actually make you unique. The point of this exercise of sitting down with your early employees and saying, what are the things that we believe in these four walls that everyone else outside of them thinks we're crazy for thinking? And that's a, it's a really valuable exercise, and it's an important thing to point to as your company grows and matures, to have this as sort of a cornerstone of culture. So the last thing that I wanna talk to you about in terms of the sort of present day stuff is something that we call our Fresh Eyes Journal. And this is something that came out of the idea that we have all of these amazing employees and we wanted a way to capture their sort of initial feedback on the company. Because when you're in something and you're working at something for years, things that seem bizarre and unusual to other people just begin to seem commonplace to you. And so it becomes very easy to sort of to become immune to things about the way your organization operates that are strange or maybe incorrect. So one of the things that we do is every employee who joins Emerald gets one of these journals and they keep it for their first quarter at the company. And so anytime they see something that seems weird to them, some issue, something that we do that seems unusual, They write it down, and then they're tasked with going and talking to other people at the company and saying, why do we do things this way? What's our reasoning for doing this? And then once they do that, then they have to say, okay, I understand that, I've reframed that in my own words, but are there still remaining issues given that rationale? And if there are, they have to come up with some potential solutions. So what are some ways that we could fix this? What are some things that we could do better? And then after 3 months, that gets sent to me and my co-founder, and also their manager, and we read them. And reading these things is painful, and the reason it's painful is because, when you're building a company, you grow to love it, and so you sort of apologize to yourself for its faults, and you make excuses for it, and so having people point out to you the things that you can see are actually wrong with that thing you love is a very strenuous and stressful process, but it's also a really healthy one, because it stops us from drinking our own Kool-Aid and from getting to this point where we're sort of in this echo chamber because everyone has just bought into everything or has sort of been bullied into the way that we do things. So we found this to be an incredibly useful exercise. The one thing I will say is, so my co-founder insists that if you decide to do this, that reading a fresh eyes journal has a 2-drink minimum. So you've been warned. So the last thing that I want to talk to you about is a little bit forward-looking. So I assume that all of you have heard of Moore's Law, right? Anyone not heard of Moore's Law? All right, so Moore's Law is about the density of transistors on microchips, but really you can think of it as describing the reduction in cost of these chips over time, of computing over time. Has anyone heard of Eroom's Law? All right, we have a couple. So Eroom's Law is something that we have in the life sciences, and this comes from a paper that was published in 2012, but actually we've sort of known about this for longer. Brian and I used to talk about this all the time in graduate school. And Eroom's Law is essentially the opposite. Eroom's Law says that the cost of getting a pharmaceutical approved doubles every 9 years. That's kind of scary. So, just to give you a sense, this has been happening since 1950, And now we're at the point where getting a drug developed costs on the order of $2 billion, depending on what study you read. So, how can this have happened for 60 years? How has the industry not collapsed under its own weight? Well, it's because our spending on healthcare has also increased exponentially during that time. And the pharmaceutical companies can correctly say that they're only a tiny fraction of this problem, and they're right. But in 2004, our per capita spending on healthcare in this country was $9,500 per person. That, so the spending on healthcare, that's not an infinite resource. At some point, we can't spend more per person on healthcare, we'll just be spending all of our money on healthcare. And the point at which that happens, and that intersects with this exponential from Eroom's law, means that it could become financially infeasible to make new drugs. And just to give you a sense, this is not something that's gonna be your children's problem, or your children's children's problem. In 1943, I'll be 6, 1943, in 2043, I'll be 60 years old, and hopefully will still be alive. If Eroom's Law continues, it'll cost $16 billion to develop a drug at that point. That means that only the most valuable drugs are worth making. There are whole swaths of things that just aren't worth discovering at that price point. And so that's a really scary thing, and that's a problem that we have to solve. So just to show you that I'm not all like gloom and doom, there is actually a sort of silver lining hiding here. So if you look from basically the late '80s through the late '90s, you see the only point in this graph where things kind of level out, and that's where the first wave of biotech drugs sort of came through the market. And biotech drugs like antibody-based drugs are different in that they, it's a completely different mode of action, it's a completely different platform from traditional small molecule pharmaceuticals. And so that's really a key to solving this problem, is new platforms for drugs, and that's what That's what we wanted to do, that's what we are doing with Emerald's therapeutic platform, and our goal with the ECL is to actually make it easier for people to focus on running the world's most efficient laboratory so we can make it easier and cheaper for scientists to do research, to discover new platforms, so that we can help reverse this trend. So it's kind of a, still kind of a downer note to end on, end a talk on, but I really want to, I hope that you've gotten the point from this that startups are hard, they are hard emotionally, they can be hard financially, and there are much more sort of like pleasant ways to live your life. But there are really difficult and really important problems out there that you can help solve, and if you think that you can contribute to fixing this or other problems like this, then it is absolutely worth it. Thanks. I'll ask the first question. Sure.

So I don't know, can you go back to the slide with the contrarian truths?

Yeah.

Because those are all really interesting. Maybe you could share a couple of them and give some insights on where they came from.

Absolutely. So let's see, what are a couple of my favorites? So we'll just start with the first one. So one of the things that was very important to us when we were starting is that we were not looking for people who were, we were not starting departments or hiring people to do a singular job. We called, I think all of our first hires were, the job title was molecular engineer, which is as ambiguous as it sounds, and the idea was that you weren't like a chemist or a biologist, it was, we had to solve problems across disciplines, and so we never wanted people who were just like, I'm a biologist, I do biology, that's all I do, and we told people from the beginning that we expected them to not only come in willing to do certain work, but also to educate the other folks on the team about their particular expertise, and also to learn from others. So we had people who had backgrounds in applied mathematics, and organic chemistry, and molecular genetics, and the whole point was to bring those disciplines together, not to silo them apart, which is a pretty common thing in a lot of in a lot of companies. Let's see, another favorite one that I like is no black boxes. There are some great packages out there, especially in the bioinformatics world for solving things where you give it these inputs and you get these outputs out. We wanted to make sure that we always understood the guts of what we were doing and that there was no sort of, idea of like, oh, well, I just run things through this filter and it comes out, and who cares how it happens in the middle. So always having sort of like control of the entire intellectual pipeline was always really important for us.

Can I just ask one clarifying question?

Sure.

Because I got a chance to visit.

Yes.

And I think that you didn't quite paint a full picture of how customers use your services.

Sure, so we have a software application that scientists can download, and when they, we're actually very capacity limited right now, so not anyone can download it, but when you have the software application, you design an experiment by specifying all the variables as if you were standing in front of that instrument yourself. Anything you could do if you were standing in front of the thing in your lab, Those are all variables that you can set using our software. Once you do, it goes into a queue at our facility, and once the instrumentation is available for that experiment, it gets run with every variable, every scientifically relevant variable being captured with robotics and automation, and then once that's completed, the data is sent back to you, and the software actually also has this very deep data analysis, plotting, and visualization package, so you can actually analyze that data in a more high-throughput manner. Yeah.

I have a question.

So you said at the very beginning of your talk that you went to get your PhD because they said that to run a company, you needed 3 letters after your name. Do you still think that's true?

Can you just repeat the question?

Absolutely. So the question was, Do I still think it's true that you need 3 letters after your name, that you need a PhD to run a biotech company? I didn't think it then, I just understood the sort of reality of the situation. I think that the industry is starting to change around that, but by and large, it is more or less still the case. I think the thing that I've come to understand is that, it's really much more about the types of, the places that biotech and pharma startups usually come from, is they typically get spun out of academic labs, they're not typically started by sort of like rogue graduate students or postdocs, so even if you have a PhD, trying to like start a company right out of school is relatively unusual, there are plenty of counterexamples to that, but I think it's, still more the exception than the rule. Yeah. I wanted to know if Eroom's law continues, do you think that there will be a point, say, it costs $250 billion to approve a drug, do you think at that point companies might start moving out of the United States to get it approved elsewhere because it's too expensive? Cost prohibitive with the regulation system? Sure, so the question was, if E-Rooms law continues, will pharmaceutical companies start moving out of the United States and getting approvals elsewhere? Is that a fair summary?

Yeah.

So, I really don't think so, because the cost of the approval is only a small fraction of that. I mean, you can actually look at this and see the places where regulation got tighter, like in the late '60s with all the rulings around thalidomide, you can see a minor change in the graph there, but this is not the FDA's fault, this is not a regulation, this is not purely a regulation issue, this is an issue with our ability to develop novel and viable drugs. So I don't think that getting approval— the problem isn't that it's so expensive to get approvals here, the problem is it's so expensive to make a drug that is efficacious. Yeah.

Could you elaborate a little bit more on the time in your company when you realized you wanted to branch and create the cloud— cloud service, like, like I'm trying to imagine that like you started this new thing and you have like this idea of like where it's going to go and like how much work that's going to take. And then now you're like, oh, but we also want to do this. And like, I'm sure, did you have to like reorganize things internally? And what was that process like?

Sure. So the question was about what the internal reorganization process was like around branching the company into two missions instead of one. So it was actually a really liberating thing for a lot of our team members, because before that, everyone came in on a given day and said, like, okay, am I going today, am I going to work on pushing the research for the therapeutic forward, or am I gonna work on building the system that will make it easier to do more research tomorrow? And that was a very, it was a very sort of personal thing for people. Some people really gravitated toward the former, and others gravitated toward the latter. And it was just, but it was a point of stress for everyone, of like, what should I actually be working on today? Which of these is more important on this given day? And so when we went through that reorganization, first of all, it was relatively straightforward, like who fell on the sort of like, therapeutic side and who fell on the cloud laboratory side based on sort of where their preferences to answering that question lay, and it made it really clear to people like what they were supposed to be doing on any given day, and so it was actually a very sort of, it was sort of a relief I think for a lot of people, because we had, even if we hadn't said that we were going to turn this into a commercial product, we were still building it internally, so from that perspective not much changed except more clarity around like what your job really was.

Yeah. Yeah. So when or if, or I suppose when, the therapeutic portion comes up with your drug that's going to be awesome, Sure, you'd like to use probably Emerald's cloud lab or that kind of techniques to do all the quantification things you need to do in order to get the approval. Do you think that you're gonna have any problems being that different with when you eventually submit to the FDA, or are they gonna be happy with how you're running your experiments and your QC?

I certainly think so. I mean, we're actually, from the cloud lab side of it, we're actually talking to a number of large pharmaceutical companies who are interested in working with us, and in terms of running their early experiments. And one of the really valuable things to them is that we have full traceability of all of our samples, all of the experiments, all of that is captured in code and in a database, which is far, which is extremely rigorous. And so we'll obviously have to have those conversations with the necessary regulatory agencies in advance of submitting anything through our system to them, but I think that the sort of trace history and the full scope of being really able to track a sample through its entire lifetime is gonna end up being valuable and not a liability in that scenario.

[Speaker] Do you think they might end up mandating or moving towards that model for everyone?

[Speaker] So the question was, Do I think that regulatory agencies will mandate moving toward the kind of tracking system that we use for everyone? I think that we're a long way away from that. I mean, these companies that have been doing this for literally over 100 years are still around for a reason, so I think that change in this industry tends to be slow, but we'd certainly like to help accelerate things however we can. Yeah. You talked very positively about having a co-founder. Would you recommend it to everyone, or were there also difficulties you had to face? Sure, so I wouldn't necessarily recommend anything to anyone. One of the things that I've purposely tried to do today is to just tell stories, not give you advice. Whenever we have some fantastic advisors and mentors, and I always find it much more valuable when people just tell stories, because advice is sort of codified scar tissue. It's sort of like, I did this and it worked, so you should do this, or I did this and it failed horribly, so don't do that. So I can only tell you what my experience was. It's certainly been helpful to me and has kept at least some of my hair, as short as it is, not gray. So I've had a very positive experience with it. I can't imagine ever starting a company without a co-founder, but that doesn't mean it's right for everyone. Yeah?

Could you explain the part from 1990 to 2000, that why did the cost of making a drug actually reduce, and if the industry is actually continuing to do that?

Yeah, so that actually, so you're talking about right here, correct? Yeah, so that was actually the, I believe that one, I think that that dip in the graph was actually, there was a period where the FDA cleared a lot of pharmaceuticals much faster because many of them were early HIV drugs. So they were antivirals for preventing HIV. So there's this big push to get a lot of these through clinical trials, so there was this sort of anomalous dip in the graph from that sort of one-time or few-time event. Yeah. So how do you resolve the problem when your therapeutic side wants a new feature and your customers of your cloud want features, and how do you prioritize the work? Sure, so the question is how do we prioritize work when our therapeutic side wants certain features but external customers maybe want different features? We have a pretty holistic roadmap, and so we solicit input from all of our users, whether they be internal or external. I would say that at this point, the system for the internal users is pretty feature complete, given that they've been— it was sort of built for them from the start, and expanding to more types of experiments is something that we want to do for sort of everyone else. But the core set of experiments that we started with on the system were built so that the research team could operate in this way.

So I'm curious about pricing of this.

Sure.

Is this something that you anticipate that even a graduate student would be able to afford running their experiments this way, or is this designed for big labs that have a big budget? You're obviously trying to keep the cost of developing new treatments lower, but is this something that you can afford to make at an affordable price?

Sure, so the question is about pricing and whether or not a graduate student can afford to run experiments on this system. And the answer is, it's really sort of up to you as the scientist. One of the things that's really important to us is that we're always goal-aligned with our users. So rather than just offering a price list, the price of running an experiment is really a function of the experiment you decide to run. So it's a function of the amount of instrument time you use, the amount of reagents that you consume, the amount of waste you generate, and the amount of setup time that your experiment takes. So you can run scientifically identical experiments that cost dramatically different things on the system. So if you're willing to take the time to actually design efficient experiments, then it's absolutely accessible to someone like a graduate student. And furthermore, the really important thing for us in terms of cost is addressing the sort of total cost of doing research. So the idea is to look at sort of your budget holistically and how much you can do, how much a single researcher can do with like a given budget, and from that standpoint, from an efficiency standpoint, I think we always win. Sure. What were your biggest lessons in recruiting and hiring? Yeah, so the question was what were the biggest lessons in recruiting and hiring? So the biggest and probably most contrarian one was to be very wary of people with 4.0 GPAs or who have an amazing publication record in graduate school, people who have sort of been unmitigated successes throughout their careers. And the reason is, and this isn't like a, it's not like we exclude anyone for this reason, but it does make us take sort of a harder look at a candidate, because as I hope you've gotten from this talk, startups are hard, and we want people who can persevere and who have grit and who aren't used to things working well for them. One of our scientists had a pretty rough go as a graduate student, I think had basically had two pretty major failed projects before the project that she actually was sort of the cornerstone of her thesis, and that was a huge plus for us, and she is not only brilliant, but also very tenacious and just does not let go of things. And so that is really a huge value in an employee in a startup. So that's probably the thing that we look for the most. Yeah?

[Speaker:AUDIENCE] So during the startup phase, before you had an actual product, what was the customer validation process like? How many people did you talk to, and at what point did you decide that this is what you should do?

Sure, so the question was what was the customer validation process like for the Cloud Lab? So we sort of had, remember this was just an internal tool, so we started just building the things that we thought that we needed to run our own research. And the idea was that you would be able to hand this to another team of 3 or 4 researchers like our current research team is, and they could use it to push a drug up into the point where it was ready for animal studies and clinical trials. So I would say that it sort of came, it was already pretty, we had a really good sense of the features that we needed because we just had to build them for ourselves, and since then the other things we've added have been pretty obvious stuff like permission systems so that you can't see everyone else's data on the system. So we've certainly had conversations with early users and with, we've had these conversations with the folks at pharmaceutical companies and that has certainly helped set some of our roadmap, but a lot of it was just from our own experience as scientists, what we would want in this product. Yeah.

Do you envision a future, and perhaps like how far into the future, when that facility that you showed, for example, like there's just nobody is there, but just like it's, you know, that it gets the— through the internet, it gets an experiment, it runs it, it streams the data back, and then it like cleans it up?

Yeah.

And like Google cars are like shipping the reagents, and you're just on a beach in Costa Rica?

I think it'll be a little while before we get to that point. The internal— so everything that's scientifically relevant is always captured in robotics and automation in our lab, but the logistics are handled by our laboratory operations team, which works 24 hours a day, 7 days a week to basically handle all those logistics that our scientists would handle before, making sure that the right buffers were hooked up to the instrument and that samples got to the right place. Because again, all of these instruments are basically built to have a person standing in front of them. And the robotics challenge of being able to get a plate of samples from any point in the lab to any other arbitrary point in the lab is extremely non-trivial, and more importantly, doesn't really add value to our user. Our goal at the end of the day is to build features that add value to scientists, and so making a lab that is totally automated and has all these robotics that are just shuttling things around might one day be economically viable. I think it'll be a very long time before that's the case. And that really, that's something that helps us, but that really doesn't help our user. It doesn't give them a better experience and make it easier for them to run more experiments or to run their experiments more efficiently. So we're much more focused on the things that improve the experience of doing science rather than making the lab sort of automated for the sake of being automated.

I'm sure you'll agree this was incredibly impressive. Please join me in thanking DJ.