Jeff Seibert: Acquisitions: Lessons from All Sides [Entire Talk]

Awesome. Thank you so much, Tina. It is an absolute privilege to be here. I remember so fondly sitting in these seats, helping organize this lecture series. There's actually quite a few people here that I recognize from years ago when I used to help lead this. So it is amazing to be here. So I wanted to start out very briefly on the Twitter side. About a month and a half ago, I was asked to take on our consumer products. So. So the Twitter product you're familiar with and leading that effort. And who here got a chance to play with our Moments launch that happened last week? Have you heard of it? Ok. A good number. A few of you. Ok. I would highly recommend you give it a shot. This is a very cool way to see some of the best content on Twitter. And the reason you should go check it out when you have a moment is this is exactly what I'm not going to talk about. And so we're not going to talk about Twitter anymore. What I want to do is talk about startups. And I actually wanted to start by thanking Tina and Tom. Literally. They have been my entire introduction to entrepreneurship. I learned everything that I know in this room. I was fortunate enough to hear about ETL the first week of my freshman year and I went to that ETL and I literally went to every single one all four years. So I went to 96 straight. And it was fascinating. And as I was thinking about speaking here, that's part of why it's such an honor to be back. It really struck me that the most interesting ones during my time here were the ones that were very concrete, very practical, very down to earth about early stage startups and what we could do. And as a student, I was super interested in that. And so I wanted to talk as concretely as possible about startups and hopefully live up to some of the great speakers we've had over the years. This is Carly Fiorina, obviously current presidential candidate. This was shortly after she left HP and came and spoke to us. And so here, here's hoping. I probably can't, but we'll see if I can live up to some of the great talks of the past. So thank you again for having me. All right, so what I want to talk about is Lessons from Acquisitions. And I've had some incredible opportunities to see a whole bunch of these from different sides. And so I want to talk through this in three chapters. The first is selling my startup in Crayo to Box in 2009, and then in 2013 selling Crashlytics to Twitter. And then over the past two and a half to three years at Twitter, I've had an incredible opportunity to see things from the other side of the table. And so I've been involved in a number of deals on Twitter's side, most notably Periscope. And so I wanted to share some of the lessons I've learned from that side since I think it's a little bit different, and it's very different and a little interesting for someone from the startup perspective. So let's dive in. Let's talk about boxing and crayo. So first off, you're probably curious what actually was Increo. I'm sure almost none of you have heard that name. Increo was a project I started with a couple of friends here my senior year. It was about January, and we became very, very interested in the concept of idea sharing and collaboration. How could we build tools that would help people, whether they were freelancers or within companies or students, share their ideas, get feedback on their ideas, and iterate and improve the documents they were trying to put out in support of those ideas? So this was actually our first mock. It was. The code name was Feedbacker, because this was the era when Flickr had made it very cool to have an R after whatever random word you wanted for your startup. And so we had Feedbacker, and the concept was simple. You upload your file and you share it with a few people, and then they can go and give you feedback on the file. And we were fortunate enough, after a bunch of discussions, to be able to raise a seed round of funding for it that February from dfj. And so we were sort of off and running as current seniors, which was ridiculous. We were trying to still go to class and make this happen. And we ended up launching in May, a few weeks before graduation on TechCrunch. I like this photo because if you may not remember, TechCrunch at one point didn't have many ads and was very clean and easy to see and read, which was a lot of fun. And so we launched on TechCrunch. And what happened? Well, we had a great spike and then somewhat terrible to say, but about two weeks later, traffic went back down to effectively zero. And so this is to just share with everyone that you think you're doing everything. You're like, oh, my God, we built this product. It works. People are using it, people sign up. We launch on TechCrunchow. We have to be successful. No, not at all. It turns out that that is just the start of the journey. And so we didn't give up we hadn't graduated yet. And so we kept working on it, slowly built a team over the course of that summer, kept chugging on both the product and the marketing. We begged bloggers all across the Internet to write about it, finally started getting some articles, finally started getting some traction. And we kept iterating the product over the course of that year to something that was relatively complex for the time. It allowed you to sew 100 different file formats in your web browser, whether they're PowerPoints or PDF or native Photoshop or native Illustrator files. And then you could give feedback all in real time, so everyone on that page could see people drawing on the document and adding comments and so on. The problem was on the growth side. And so it turned out that the product really appealed to freelancers and freelancers loved it because they needed a way to communicate with their clients and get feedback on the design they were doing and iterate from there. But it was a real struggle to grow past that market. And so we wound up getting a great audience, a great customer base of about 20,000 freelancers, and it was a big challenge to grow it past that. And so as spring of 2009 came around, we had to go back to Sandhill Road. We needed more funding in order to keep the company operating. And for those of you who remember that period, 2009 was perhaps one of the worst times to raise funding in the past decade because the housing bubble had just burst. Actually, the previous October of 2008, Sequoia had put out this presentation that said, RIP Good Times. And everyone sort of stopped investing and pulled back and was afraid that the end times were upon us and whatever was going to happen. And so here we were as a tiny six person startup with a small product with 20,000 users, trying to raise funding. And the challenge with that is if you're going to go out for an A round, you need to present a really compelling idea and a really big opportunity in order to justify further investment. And this little freelancer project was not going to cut it. And so here's an actual slide from our actual pitch deck. We decided, hey, this could be the start of a new way of exploring file formats. What if you could actually take any file and break it down into its component pieces, add metadata on it and then render it anywhere on the web? And so you could allow different web applications to edit or mutate different parts of the file? Now, I don't know what you think about that idea, but. But the VCs pretty much were not impressed and were totally confused what we meant. And we ended up actually talking with 36 firms around Silicon Valley over the course of that spring. And all of them gave us the thumbs down. And so where do we go from there? Well, this of course, now you're sort of in a more urgent state. We have about six months of Runway left in terms of cash we had in the bank. We need to go do something with it. And so the great thing is with constraint comes tons of creativity. How can we go survive as a company? And how could we find some way, some sort of capital to get us keep going? As a quick sidebar, I can't believe there's an emoji that's money flying. I don't know why that is, but there is. And so how could we go do this? Well, we started really looking at what we had built and we quickly realized that probably the most valuable thing of the company wasn't necessarily our user base or the product as a whole, but was the technology we built. We had built this back end System to convert 100 file formats to Flash because this was 2009 and that's what you did. And so we had this conversion engine that we thought could be really powerful. There were tons of different companies on the Internet that dealt with documents, very few of them, if any of them could actually display those files in the browser. And so we started thinking, hey, this could be a path forward. And so what if we approached a bunch of those companies and offered to partner with them and maybe they pay us a penny per document or whatever it could be, and in exchange we would power their document conversion and we would give them our document player is what we called it, and this would allow them to show files within their site. And so that's exactly what we did. We went around the Valley and pitched a bunch of companies on this partnership. And here's some actual mocks we did for Box where you have a file in your Box account and then you click preview and you would see a preview of it right there within a few seconds. And that could be pretty cool. And what really blew our mind here is that where all the VCs did not like our sort of future looking vision, this was a very concrete thing, this was a very clear need to that these companies had and they could really rationalize it. It's like this is something worth doing to radically improve our product experience. And we immediately had four companies that wanted to go partner with us. The challenge was they had some interesting constraints and they were pretty much universal with these constraints. They wanted it to be exclusive so that their competitors, the other ones on this list, didn't have the same technology and they wanted to host it themselves. Because if they were to send their private documents, their user documents out to our systems, they would have to change their privacy policies. They'd have to tell their user base, it would be a whole legal mess and it would just be a lot of extra infrastructure they would have to build. That all sounded reasonable. The challenge is okay from us as the startup side. Let me get this straight. You want to host our technology and we can't give it to anyone else because it has to be exclusive? That doesn't really sound like a partnership to me. That sounds pretty aggressive. That sounds a little bit more like an acquisition. And so we actually said that point blank to these four companies and we're like, so what's your path forward? What do you propose here? Well, three of them, gray excluded, moved forward and actually made acquisition offers. And this stunned us. We were not expecting this. We were like, wow. We were just trying to find a route forward for the company, find a way to break even so that we could keep developing our technology. And now actually we had all these interesting offers on the table. And so as we're thinking through this, how do we start evaluating which path to take? And so you would do what anyone did and go through and try to make some pros and cons. And so how do we think about these companies? Well, Red was really compelling. Red had absolutely massive scale. And these were the actual code names we used. Red had actually massive scale. And so that's compelling. We wanted to be able to power this for a large number of people to sort of stay true to our vision and have help people collaborate on documents. And we got the sense that they were actually willing to pay quite a bit for this technology. They saw the need. They really understood how powerful this could be for their product. Then of course, there were some cons. It was not a great culture fit. This was an older company. They had been around a while. They had a very corporate culture and they were down in San Jose and being recent grads, we weren't certain we wanted to move down to San Jose. They also were requiring that we rewrite our whole technology stack. So we had written it in Ruby. It was a great language to iterate on it very quickly, prototype stuff, get it into production. They were all Java based. They said, oh, if you come in, you can't do Ruby. You have to rewrite this into Java. And that was a challenge because we felt this would probably take 18 months or so to rewrite. There was a lot of technology we had built there. Purple was about middle of the road, so there was a good culture fit. That's fine. But we weren't super passionate about their business. They were more focused on the wiki space and we just didn't really understand where that would go and pan out and how this would become a huge thing. Blue had a great culture fit and a really clear product need, so they had decent scale. Not quite as big as Red, but they still had a lot of scale and it could fit in the product really nicely. And we loved the team. We'd gotten to know them, actually, over the course of the prior year, but it was clear that they were not willing to pay a lot. They were a pretty small company at the time, and so that was something we would have to deal with as we weighed our options. And so as we thought about this, we very quickly ruled out Purple. It was sort of middle of the road. There wasn't anything really bad or really great about it, but we were struggling a lot between Red and Blue. And so who thinks we went with Red? Any hands? Wow. Who thinks we went with Blue? Everyone. That's exactly right. That's exactly right. And so we made the decision, ok, all things considered, we would far more value the culture and the path going forward than we did the money at the time. We weren't in this to try to make a lot of money. We were in this to build this tool and help people collaborate. And we felt if we could have a very successful integration and partnership with Box, that would be a strong way forward. And fortunately, that's exactly what we ended up doing. So here's a screenshot from Box about nine months later. And our technology directly powered all of their document preview within the product for about five years, which was pretty cool. And so I wanted to sort of step back and talk about lessons learned from this and as you reflect or do a retrograde on this moment. So even though this was our totally first time through this process, it was actually not only our first experience being acquired, we were the first company Box bought. And so Levy had never acquired anyone before and also was trying to learn this as he went through it. But we did actually manage to get a few things right. In retrospect, we did focus on the future, not on the moment. And I think this is deeply, deeply important. There are so many founders I talked to today who are looking to sell their company and everything they seem to talk about is the day the deal closes. Of, oh, we're going to make this much money and it's going to put my team in great shape, and, oh, we're going to have some great press around it, and I'm going to look brilliant and all this stuff. And that actually has almost nothing to do with your success, because when you go through an acquisition, you're going through the next three to four years of your life working for that company. And why would you value this one day, this one moment in time, more than the next four years combined of your experience of actually building out and realizing the vision of what you're going to try to go do together? And so I am fortunate we did not go with Red. We did not stay focused on the money. And I think we got this exactly right. We also optimized for Culture Fit. The more I've learned, the more critical this has become to me, is there are many great companies in the Valley, but the one that's right for you is the one that you deeply identify with on a cultural level, that you love the people there, you love what you're working on, and you have a blast working together with them on it. And so we had gotten to know the Box team over the prior months. They were also funded by dfj, and we had a really strong sense that we liked the people there and we thought we could do great stuff together. Now, we did get a lot of things wrong, and so I wanted to talk through these. We waited too long. So as I talked through, we did this fundraising process that did not pan out, and then we started thinking about partnership opportunities and then ultimately acquisition opportunities. Because of this, we had a very short Runway to pursue the acquisition, and so we couldn't fully evaluate every possible option. We basically approached the top four firms that we thought would be interesting on a partnership side. But if there had been much more time, we could have gone much deeper, been far more strategic about the partnership or acquisition that we were pitching, and gotten to be a little bit in a stronger negotiating point so that we could perhaps have come out with a better monetary outcome. Even though that wasn't important. We were also overly transparent. And this, I think, is really interesting because I am deeply for transparency within companies, but I think there's a caveat to that. I think as a founder of a startup, it is your responsibility to gauge how transparent or not to be. And your ultimate job is to reduce stress for your team. And so in many circumstances, actually being more transparent reduces stress because people see the picture, they understand where things are, and they can go do their job. But in certain cases, particularly I found in acquisitions, the stress of going through that process is immense. And it is almost certainly your job as a founder to try to reduce that stress for your team and prevent them from having to go through the same process you are. Because we started talking with Box and these other firms about three months before we ended up closing. And so even with a relatively small, relatively simple deal, it still takes quite a bit of time. And during that time, our entire team of six was visibly stressed. People didn't know what to work on. We didn't know whether to continue our roadmap or to go and build what we think Box might have wanted, or maybe we do some experimentation and we build some things that Red wanted and some things that Blue wanted so we could see the whole world. It was just a lot of confusion and ultimately lost productivity because the net result of that is we built almost nothing during those three months because we were so confused about which direction to take. And so in retrospect, we should have probably not told the team we were going through this process, and we should have brought them in when we were more certain of the direction so that we could have kept executing towards our original goal as a startup before making this transition. We also, again, because we hadn't been used to this process, we didn't know what to negotiate, and neither did Aaron Levy. We didn't get any commitment on Box's part to continue investment. And so they were excited by that technology. We came in, we built it, we integrated it into their systems, and then over time, we transitioned off and worked on different projects across the company, which was a great experience, and we learned a lot doing that. But what turned out to happen is that Box actually under invested in Document Preview over the course of those five years and a year and a half ago, had to buy Crocodoc in order to make up for that. And so Crocodoc was a company that started right after we were sold and was basically the next generation of conversion technology. And so because Box under invested in it, we didn't have the next iteration of the technology and they had to go make another acquisition in the space. So that's the first story. All right, let's talk about Crashlytics. And for that we have to talk about crash reports. So crashlytics comes from the fact that we did transition off Document Preview and conversion while at Box. And I started leading Box's SYNC project, which was effectively their answer to Dropbox. And if any of you have ever worked on Sync clients, it turns out they are horrific, they are incredibly complex to build and incredibly buggy. And maybe it was just ours, but it crashed constantly. And this was sort of the seed of the idea in my mind for Crashlytics. So we, I put some simple code into our sync client that if it crashed, detected that and uploaded a report to our server. And this is a prototypical Apple crash report. This is one I actually pulled from the Twitter app, but it is incredibly cryptic. And so we shipped this build of our sync client out to beta testers and a week later we had 6,000 reports sitting on our server. That's how many times it had crashed. And this was actually worse because now we were frustrated that we knew how bad it was, but we didn't have time to read through 6,000 of these and understand exactly what was going wrong. It struck me that this problem was actually automatable. The answer is in these numbers, these hex codes, which are the memory addresses of the call stack. When it crashed, if you could actually back out the line number of code from that instruction pointer, you could determine exactly where the crash occurred in the app. That's what I started working on as a side project. I built an SDK for iOS initially, and then we built an Android one to basically detect that crash time that the application was crashing, gather all the data it needed, and then the next time the user launched the app, upload that to our server. And Box was actually fantastic. Through this process, I had told them, hey, I'm interested in building this. I don't want to do it for Box because I think it would be broadly useful, but it's something I want to work on on the side. And to their complete credit, they said, hey, great, go for it. Work on it nights and weekends, and if it's good, maybe we'll use it one day. And so off and running and started a project called crashlytics. Crashlytics did exactly this. We were able to mirror and pair the debugging data from the device with the compiler data the developer had when they were building the app. And from that we can actually extract precise line numbers and method names of the exact line that crashed. And then we can aggregate these into issues so that you know exactly how many bugs you have and how important they are so you can fix the top ones first. And so this. The trajectory was night and day from Increo. Increo. We were struggling to find these freelancers do a lot of marketing and just begging people to try out the product and use it. And this Blew my mind. This was completely different. I started telling friends about it, they were desperate to use it. We got a few beta testers, they started telling other people, and literally within months, we had thousands of apps using Crashlytics, tons of people begging us to use the product and signing up and trying to get on the wait list and so on, and opening it up. And so it really struck me the difference between a pure need, like a real visceral need that people have in order to do their business, and something that is sort of a nice to have. And Crayo, unfortunately, as a product, wasn't a complete replacement for email. And so you could just email the document and get some comments back. And that reduced its need ultimately. And so Crashlytics really struck us as like, wow, people are desperate for this. And that's what resulted in the growth. What's interesting, of course, is among our big apps using us was Twitter. And Twitter became obsessed with the product, put it out in both their iOS and Android apps, and we were going along. They were a happy customer, Things were great. And all of a sudden, in October of 2012, so about a year after we had started, we get a call from them and they say, hey, have you guys ever thought about working for Twitter? And we were like, no. Why would we do that? And we have a great business. The product's going gangbusters. We're really happy. We have a great team. I don't see why we would go work for Twitter. That doesn't make sense to me. And they were like, ok, well, great chatting, and hung up. And that was October. In December, they call back and they're like, hey, we really want you guys to come think about working for Twitter. At the very least, come out and meet with our exec team and we'll actually fly you out there. Because we were in Boston at the time we had started Crashlytics in Boston. And we're like, okay, fine. But remembering back to the lessons learned, we had to do this very, very carefully because we had no interest in selling Crashlytics. That was not the goal. We needed the team to stay focused. We were in pursuit of our B round of funding, which was going well. We had started charging for the product. We had a ton to build in order to scale up the team in the business. And so we couldn't let this wind up being a huge distraction that didn't pan out. So we came up with a plan. This was December. We threw the team a holiday party on the 18th. We gave them all these spiffy jackets and on the 19th, my co founder and I secretly flew to San Francisco and we gave the team that week off. And so no one knew we were out here. And the 20th, we met with Twitter, and this is actually from Jack Dorsey's conference room. Ironically, he was not CEO at the time, but he did have a conference room. And so we're meeting with them there and asking them point blank, why do you want us to work for Twitter? We have this trajectory. We're building developer tools. We don't understand how that meets with a consumer product. Why would these two. And by all means, you can continue to be a happy customer. That would be great. And what really struck us was Twitter's nuanced understanding of the mobile space. They. And you gain this perspective from being one of the largest apps. They had a very clear vision of how they saw mobile developing over the next five years and the different products they would need to build in order to be a permanent factor in that ecosystem. They also were very, very conscious and aggressive at reinventing their developer platform. And so I don't know how much you remember Twitter history, but Twitter was deeply popular with developers in the early days, and there were tons of apps and tons of things built on top of Twitter. And then in 2011, the company had made the decision to sort of pull that back a little bit and discourage people from building clients. And that had frustrated, in fairness, a lot of developers. And so here in 2012, Twitter had recognized that and wanted to go and sort of reinvent their image for developers. And Twitter is an extremely. It's an incredible platform for developers to build on today. And they wanted to go and make that a reality. And so this got us more intrigued. Now we understood that this wasn't simply they needed to own a crash reporting tool because they used it. This was that they saw us as sort of a beacon of this new wave of developer tools that developers had fallen in love with at a massive scale on mobile. And maybe we could build upon that to do more things. And so they asked to see our roadmap. So we showed them a rough roadmap we had. And this is the actual slide. And so we were doing crash reporting. We wanted to build a beta distribution tool. We wanted to go into analytics. And then we, way down in the future, we wanted to do some ROI or monetization stuff. So move further up the stack from developers to product marketers to app marketers and sales and so on. And that was the long path of the company that we'd been pitching. And as we Started talking with them. What blew us away is that this was almost exactly what they wanted to build. And so we made a few tweaks to the roadmap, but largely it was identical. We inserted a Twitter SDK. Twitter didn't have an SDK at the time, and so we would have to go build that. And that was great and fine, but otherwise the roadmap was basically the same and that blew our minds. We had such complete strategic alignment that they basically had painted for us our own roadmap that we had been working on internally. And we were like, wow, this becomes deeply compelling. And we could leverage then Twitter's brand and notoriety and their willingness to build all of this and offer all of this for free instead of charging for the tools as a way to very, very quickly scale up the platform. If we look at it through the same rubric, there are actually quite a bit of pros here. They have massive scale brand. As I talked about, incredible culture Fit. Twitter actually employs seven Mayfield fellows today and a ton of Stanford students. So I also knew a bunch of people there already that I could go do background checks with and see how they liked it and were eager to work with them again. So that was fantastic. There was a very clear product need. They had this developer gap that they wanted to fill and they didn't have an SDK so we could fit right in. Clear strategic alignment. They made a commitment to continue investing in it. They wanted to double our team. They wanted to make the product free and. Yeah, and they wanted to make the product free. And so, of course, it's not all rosy. There are a few cons. And so what are these? Well, we were questioning sort of their reputation amongst developers. It's been off and on, and we ended up ultimately seeing this as an opportunity. We thought that we could really help Twitter reset its reputation with developers and build a new platform for the future for them. And so maybe that could shift over to the pros column. There was also, of course, opportunity cost. We were excited to go build our own big business and learn a lot from that. And so really what it came down to is, were they willing to do this deal? Were they willing to make a fair trade of value that made it worth our while to go work on this with Twitter instead of pursuing it on our own? And that's, of course, when you get into negotiation. And so my co founder led most of this and went back and forth over countless phone calls over the next four days and that weekend, and actually ultimately kept them up negotiating until 2am Christmas Eve, remember this was late December, and we ended up deciding to go for it and sign the turn sheet at 10am Christmas morning. And so that had been an incredible period. And in one sense you're like, wow, that's an incredible Christmas. On the other hand, it's like, okay, wow, we have way too much to do now and we need to get back and tell everyone. Because keep in mind, nobody knew. We hadn't even told the team we were in San Francisco. And so I wanted to talk through again a few things that we got right and wrong. So this I've harped on. We had complete strategic alignment and I think this is deeply essential to the long term success of the acquisition. We had credible funding alternatives, so we were negotiating from a very strong position. We actually had at least a year of Runway already left, so we had no need to sell. We already had the B round almost closed. In fact, our investors agreed to match any valuation Twitter gave us. And so we had total optionality there. And so that worked very well. We also, because only my co founder and I knew, had complete control over all sides of the story. And this became deeply important. And so the two of us knew exactly who each other talked to and what we said and what the messaging was, so we could control the message not just to Twitter and not just to our team, but to our investors, to our advisors, to our legal team, et cetera. And so this actually made the process far less stressful than I think it otherwise would have been and far less chaotic because we were able to run it with such a small core group of people. The key there is you have to live up to your team's trust. And so we had built a team of 18 people, 14 engineers, over the course of the past year and a half. And it was essential. They had basically taken the job, put their life in our hands because they believed in what we wanted to go do. They wanted to join a startup, and they didn't necessarily want to go work for Twitter. That wasn't part of their plan. And so it was on us to motivate that, to explain why we ended up making this decision and why we did it without their knowledge or buy in, and why we believed this would ultimately make all of us far more successful than if we had pursued the product individually. And to hammer this home, we also, of course, had to take care of the financial side. And so a cool thing here is actually most of our team, almost the entire team, had been with us less than a year. And so the way standard option agreements work is there's a one year cliff and then it vests over four years. And so if someone leaves in the first year, you could actually wipe the slate clean. They could get nothing. None of their equity would count. And that would have been terrible. We now would sell the company without their knowledge and then not give them anything. That's insane. And so we actually decided to do the opposite. And so my co founder and I fast forwarded their vesting all four years. And so even the people that actually only been there a month got their entire four years of equity. And that converted into equity in Twitter because that's why they put our trust in us. Put their trust in us because they believed that this was a company they wanted to be a part of and a founding team that they wanted to work for. And so I think this is an essential analog to doing this with and balancing the transparency there is. Of course, we had to get something wrong. The thing I would call out here is reporting structure. As we negotiated the deal, we came to an agreement with them that we would report directly to the VP of engineering, which seemed great at the time and that was great. Very quickly, Twitter actually did a reorg and we wound up reporting way deep in engineering for a period of months and it wasn't the end of the world. We ultimately corrected that and kept building. But it really struck me that we didn't get the support we needed and we should have been more thoughtful about this. And the context here is with Box. Box was a 40 person company at the time, didn't really matter where we reported. Twitter was much larger and I didn't fully anticipate how much reporting structure does matter in larger organizations to determine what level of support and visibility you have. And so I think we should have been a little more clear about this. But this is really, I think, the only thing we got wrong. And this has been an incredibly successful acquisition from my perspective and from our team's perspective. We kept investing in Crashlytics. We've modernized the product, we have scaled it immensely over the past year. Crashlytics has been used by over a million different apps across over a billion mobile devices. So it really is actually pervasive. We're on most mobile devices that are active today, which is pretty crazy. What I'm most proud of is that in the two and a half and coming up to three years on the acquisition, not a single person on our team has left. And so we have our entire original team. We've actually tripled the team. We now have 75 engineers and we have been building fabric. And so once you saw the roadmap, this was the ultimate goal. We joined with the mission to reinvent Twitter's developer platform and effectively went heads down for two years in order to do that. And so we expanded Crashlytics, we built that beta distribution thing, we built an analytics tool, we built Twitter's SDK and we launched that a year ago at Twitter Flight under the branding fabric. And so if you're into app development, I would check this out. There's a whole bunch of cool tools you can use and minor plug. We're on stage next week, next Wednesday for Twitter Flight again and we have the whole next generation of tools that we're launching. So super excited for that. So that's the story of Twitter and Crashlytics. And so now I want to sort of turn the tables and go to the other side of the table and talk about what it's like to be on Twitter's side, because I've had the distinct privilege over the past three years to see a lot of deals from Twitter's side and help advise them on different startups to acquire and how to go through the process. And so from my direct experience, this is the funnel I've seen. I should point out that Twitter does on average, one acquisition a month. So it's a massive operation. They've acquired a ton of companies. I've seen a sliver of that. And so from my perspective, I've seen about 50 companies evaluated, contacted to see if this is interesting. We've pretty deeply evaluated 12 of them over that time. We seriously considered six of them and started negotiating with them, and ultimately three closed. And so the key takeaway here is it is actually incredibly unlikely for a deal to happen. Only one in roughly 17 of these deals panned out. And so there's so many endless things that can go wrong along the way. I wanted to break this down a little and talk about what we look like from what we look for from Twitter's side. First, it's important to understand the different types of acquisitions. And the first one you've probably heard a lot about, this is very popular in the valley over the past couple years are acquihires. And I put this at the bottom because these are probably the simplest and in terms of monetary value, lowest deals that companies do. And the goal here is simply talent. And so this is a great team of engineers that have gotten together, they've built a product, for one reason or another, the product doesn't pan out, that's fine. Tons of Companies fail. That's great. You learn a lot from it. But ultimately they want to go and join a larger company and still work together as a team. Aqui hires are actually really interesting because you have a team that works well together, which is harder than you would expect because instead you're just sort of hiring one person after another and you have to do a lot of work to guarantee the culture fit, to make sure you're assembling a tight knit team. Here you can go and acquire a tight knit team all in one package. And so that's why this has become more popular. The next sort of level, I'd say of acquisitions are technology deals. And I would put the increo sale to box firmly in this camp. This is where the company had a clear need, they had recognized the need and they needed to go and build a whole bunch of technology in order to do that. And it's a cost benefit analysis. You could either take that on and hire a bunch of people and staff up a team and maybe it would take a year to two years to go build, or you can try to identify a smaller company that already owns that technology and you want to bring it in house. And so we do a lot of these deals as well. The most rare and the largest deals are the strategic ones. And so this is where you are augmenting your business in a deeply strategic way in order to go after a new market. And so I would put the Crashlytics deal in this bucket because Twitter didn't really have a strong developer platform. They know they needed one. They wanted to buy not just technology that wouldn't have particularly helped them. They wanted to buy an entire product and a market and a brand within the developer community in order to go pursue that space. And so we've done a whole bunch of these deals. Periscope falls into this camp. Teleport falls into this camp, Mopub falls into this camp. And so these are sort of the bigger name deals that you hear about and read about. And what's interesting is how these happen. And so on the Aqua hire and technology side, it's typically the startup approaches Twitter. So we canvass the space and we're sort of aware of what's going on. But ultimately it's the startup's decision that it's time to go look for suitors and they would approach big companies and see if there's a match. On the strategic side, it's almost entirely the opposite. And it's us on the product side of the large company thinking about where we need to go and where we should make an investment. And that's when we canvass a space, look at all the potential players, and then try to meet with them and understand who would be the best fit. And so what does this process actually look like? Starts, of course, with a call, as I talked about when they called us, goes on, if that goes well, to a strategy meeting with the founders. We really want to understand where they're coming from, what they want to build, what kind of team they build. If that goes well, we move it on to a tech talk. So we bring in a bunch of the lead engineers and really understand what they've built and how they've built it. It's fascinating understanding all the different architectures that companies are using today. And some we like better, some would match better with Twitter's infrastructure and some wouldn't. And so it's always a great discussion to understand the trade offs they've made. If that goes well, we move on to interviews. And in almost every case, we ideally want to interview the entire team. And again, it's because cultural fit is so important. And then finally it comes down to, of course, the negotiation. And so what we're looking for here is we're really looking for alignment and culture. This is not just a thing to care about from the startup side. This is a thing that the big companies, and Twitter particularly cares deeply about. And we spend most of our time making sure that we're only bringing in people who we think will be successful within Twitter and within the culture that we have. We, of course want strong technology. There are tons of different ways to solve problems, and we're looking for a really elegant, really powerful, really scalable approach to solving problems. We're looking for a great team. I'd say this is actually where most of the deals fall through, is it turns out as we interview everyone, of course there's going to be amazing people and weaker people, and it comes down to the percentages. And so ultimately we have to make a really tough call that if there's too few great people on a team, we can't justify bringing the entire team into the company. And so as you go and start your companies and build your teams, really focus on assembling the best group of people you can to put yourselves in a position of success here. And then, of course, finally, we're looking for fair value and we want to really understand what would this have taken us to build or us to win this market or whatever it might be cool. And so a few last things to Remember, almost all deals fail. And so as you go through processes like these, don't get frustrated. This is sort of the name of the game. Expect it will fail actually. And just work in a disciplined manner to talk and lay everything out on the table and be transparent. And that's probably the easiest way to very quickly judge whether it's looking like a success or a failure. Both you and the acquirer must be in 100%, you must be committed. And what I mean by that is, let's say you've been working on a company for quite a while, you're a little bit tired, you're feeling burned out. An acquisition is not the path to your vacation, it is the opposite. And so you need to be far more energized than you ever have been. And if you feel like you can't give this new chapter of your company the energy it deserves and it is not going to end well. And you have to deeply, deeply understand that the same is for the acquirer. And so it's really important to understand because they're a larger company, they have strategic initiatives. Where do you fit into their strategic priorities and their market needs? And do you see that need continuing long term or is this a hobby thing that they're experimenting with but probably won't invest in? Try to meet as many people and learn as much about that as you possibly can. And as I mentioned, this is just the start of the journey. This is going to be four years of your life and so you cannot see this as an exit. And so carefully consider strategic alignment culture fit their ability to invest going forward in your team and your product and ultimately the reporting structure if it's a larger company you're talking to. So I wanted to end just before we go into questions with two higher level things. The first is a deep thank you to Kimber, my co founder at Increo, Wayne, my co founder at Crashlytics and Jessica. It is 100% the truth that Increo would have failed without Kimber. It was incredible working with her and she led most of the negotiation with Box and so huge thanks to her for everything she did for the company and for making that happen. Same goes with Wayne. He's one of the most brilliant negotiators I've ever met. You might be catching a theme. I am horrific at negotiating. I love building products and writing code and trying to make stuff. I don't like the business side of things. And so Wayne was absolutely essential in that. And then Jess taught me everything I know about acquiring companies. From the Twitter side. And she was Mayfield with me, and we've known each other for a long time. But the opportunity to work with her and see how Twitter has gone about and very professionally and very diligently acquired so many companies over such a short period of time was fascinating and so huge thanks to them. And finally, I want to urge everyone here to stay true to your mission. It would be terrible if your takeaway from this talk was, okay, I'm going to go build something and I'm going to get acquired. That is not the goal whatsoever. And when you go out and raise funding, inevitably you're going to be asked, so, why are you building this company? Are you building it to be acquired, or are you building it to ipo? And I hate that question, because what's happening is the investor is assigning a definition of success totally independent of why I started the company. I didn't start the company to sell it. I didn't start the company to ipo. I didn't start the company to exit it. I started the company to solve a problem. Like, I started the company to stop mobile apps from crashing, because that's really annoying. And so you have to stay true to your mission. The Crashlytics did not. When was not successful the day Twitter bought us, it was not successful the day Twitter IPO'd. It wasn't successful when we launched Fabric last year. It's still not successful today because mobile apps are crashing over a billion times a day. And so when you're thinking about opportunities for your team and your company, focus on the ones that will help you achieve your mission instead of seeing it as an exit. Thank you. Can I ask you a question? You have the first.

I'm going to ask the first question.

All right, Tina.

So you go from being the boss, from being the founder and calling all the shots, to now working for someone else. Can you talk a little bit about that?

Yeah. It is a fascinating transition because. Yeah, that's exactly right. You go from leading this team, from making all the decisions, owning all the decisions, to all of a sudden having to work within this structure. And I think that's why the strategic alignment is so important. And you have to be very clear in setting expectations. And so we were very clear with Twitter that, like, okay, if you believe developers are a priority, then we are going to go and build you a developer platform, and you have to give us the leeway to go do that. And so it is tough because founders are used to this autonomy, and in many companies, they aren't used to groups of the company wanting or having autonomy separate from the rest. And so this is a skill that the acquirers learn. And we've, for example, been deeply intentional about letting Periscope keep their office, keep their roadmap, keep their plans, run their app and their business as they would, because that's ultimately what will make that team successful. And it's not our mission to go and merge you in and trample everything you've done and all your customs and everything. Ultimately, we're doing the deal because we want the startup to be successful, more successful than they would have been independently. And so you have to strike the right balance. The other thing I'd say is I think this is often the case. Why? Founders tend to start initiatives within companies, even if they're joining a company and maybe their product has wound down or whatever it is, instead of joining a team doing something. In many cases, I've seen founders tend to want to start a new project or a new whole area of the product or whatever for the company because they feel that degree of freedom. And there are certainly cases where it doesn't work out. Yeah. Okay. First of all, thanks so much for coming. This is a really great opportunity to learn a lot about this. So my question, I was just curious, once you signed the deal with Twitter and then you went back to Boston, how did you break the news to your team and how did they respond initially? Was there like, hesitation or some kind of backlash? Yeah, great question. Oh, sorry. So the question was, after we signed the deal with Twitter, how did we go back to Boston, the team, and how did we break the news to them? And we were stressing out about this endlessly because you sort of have one opportunity to message this correctly. And so what we decided to do, and remember, this was Christmas and we'd given everyone the week off, and so everyone was supposed to come back the Friday before New Year's, and we were going to do a 2012 year in review for the company, and that had been previously scheduled. And then obviously people would go and take more time off for New Year's and so on. And so we decided, hey, we can't change anything. We can't, like, schedule some random thing and that'll freak everyone out. And so we're going to do a 2012 year in review. And so my co founder and I spent hours making a slide deck, a photo deck where I got those photos of the year and what we'd done. And it talked about all our milestones and the new people joining the team and Our office space and everything you would possibly add to a slide deck about your year as a startup. And it ended with the holiday party, except it didn't. And there was the next slide. And so we pitched it as basically, well, you thought this was the end, but there's not, and there's more news. And so we told this whole story of flying out to Twitter and presenting in the conference room and negotiating with them and so on. And there's actually a photo that I chose not to show of Wayne and I having dinner, celebrating with champagne afterwards, except that it was overly romantic and like under a Christmas wreath because it was Christmas time. And so that got everyone laughing. And we talked through the Delta and the roadmaps, and that was very compelling. And so how similar? Like no one had their dreams shattered. We were building exactly the same thing, just under a larger mandate, and we could make the product free. And so that, I think, played well with the team. And then to bring in sort of reinforcement, we timed when our lead investor would show up with some champagne for everyone and some more words of congratulations and advice. So the goal was to message it sort of slowly and break the news and then celebrate and spend the rest of the day partying. Tom, continuing with this, some companies require the team to relocate. And so what happened with the Twitter? That's a great question. So the question was, in many acquisitions, they require the team to relocate. And so how did that pan out or play out here? That is very true. And Twitter asked us to relocate. And this is one of the things I didn't touch on, but you should cover in the negotiations. And we were very clear with them that the team was not relocating, that people moved to Boston and live in Boston for very specific reasons. And if they were willing to move to Silicon Valley, they likely would have moved to Silicon Valley. And so we in fact did offer the Entire team, all 18 people, the opportunity to move. Only two ever took us up on it. And they took us up on it about a year and a half after the fact. And so we ended up actually starting Twitter's Boston office. And so Twitter built out an office space there. It's actually the now largest remote engineering office. They've since acquired a bunch of other companies in Boston. And so we have about 140 people out there. No coincidence. You mentioned that interviews with the team is a part of the deal, is a part of the process. How would you arrange interviews without. Ah, great question. Yes. So the question was interviews are part of the process. How do you do interviews without Disclosing this to the team. Brilliant insight. The way this works is it depends on the dynamics of the deal, and it depends who has the stronger negotiating position and what the founders want. Because frankly, a lot of founders actually don't take this approach and just bring the whole team in, which puzzles me, but they do. If the founders are very set that they do not want the team to find out, and a lot of founders are. It depends on the dynamics. And so if the founders have a strong case for it and we're very bullish on the deal and we want to make it happen, then that's fine. And we'll actually go ahead and sign a term sheet that's basically conditionalized on a certain percentage of the interviews going correctly. And so you sign the term sheet and then of course, they tell the team, and then everyone comes in and talks. And in the case where maybe it's an acquihire, they have a less negotiating position. It's a condition. So it's like, sorry, if you want us to engage deeper in this deal, you have to tell them and bring them in. Yeah. Hi. The step where we spend most of the time is that are we getting the right price? So how did you ensure that you are getting the right price? Yeah, that's actually the step we spend the least amount of time on. Probably, all things considered, the price within some range really doesn't matter. And so we spend by far. Oh, sorry. The question was, how much time do you spend on negotiating the price and how do you make sure you get a fair value? And yeah, we really don't spend a lot of energy there. We spend most of the energy on the culture fit, because the thinking is it'll be either successful or if it's not. And if it's successful, the price is probably a rounding error. Like, with any luck, it's a rounding error. And so we try to offer. Make a very fair offer. We look at comparables, we look at your latest rounds of funding and where they value the company, and there's a little negotiating room, but not a lot. Yeah, you said that one of the lessons learned from the first acquisition was that you waited too long. At the same time, with the Twitter acquisition, you said you got a call, but then you kind of ignored it, and then two months later, you took it seriously. Didn't you feel like you could have acted earlier on the second acquisition coming from the first one? And the lesson learned. Great question. Yeah. So the question was the first acquisition waited too long to happen. This one we sort of took A call and ignored it and then waited. And so why did we wait too long again? And it's totally different dynamics. We had zero interest in selling Crashlytics. And so from our perspective, it was way too early. I mean, you could say it was too early even when we did do the deal, except for debate, I don't think so. I think it was 100% the right decision and the right timing to do it. But yeah, I guess it was just a different mindset. The way we looked at it is we believed that Twitter would very, very rapidly, because of their brand, legitimize us and we would become sort of the de facto crash reporting solution, which I argue has more or less happened. And that then how long would it take for us independently to achieve that same trajectory? And we as co founders sort of debated this and thought that, hey, Twitter's value add was about three years worth of execution. And at that point it became straightforward to do the deal. Ravi, you started Jeff in CREO while you were a senior at Stanford. What advice would you give to other undergrads that are thinking about starting companies while in school? Great question. So the question was, I started in CRIO as a senior, which is true. What advice would I give to current undergrads? It's really important to say that we had no intention of starting a company. That was not the goal. The goal was to start working on a project that was fun and to start training ourselves to evaluate business ideas and making decisions as if we were a business. So we built this idea sharing tool. We then recognized that, and then we did a ton of research and market research and talking to people and customer development and realized that idea sharing wasn't a great space. And so we, quote, pivoted, even though pivot wasn't a word, then over to document feedback. And we were just sort of following this path, like just doing side projects as students. And it was really only when we came and talked with you for advice that we realized that maybe this was interesting and maybe this was a path we should pursue further. And so I'd say don't like. My personal opinion is don't drop out. I think you should continue your time here. You learned so much here and it's so valuable to be here, and you can never really get that back. I certainly miss being on campus, but spend as much time as you can doing side projects and teaching yourself, working with people, meeting with people in the industry. Take advantage of the fact that you can say you're a student and anyone will meet with you. Which is crazy. And the moment that's not the case, then you can't do that. And so take advantage of that. The other thing I'd say just more tactically is take a vacation after graduation. We started in Creo full time before graduation, about a week before, and I haven't taken a vacation since. So that's been rough. Yeah.

So flashback to when you were a student here. I mean, obviously you really squeezed the juice out of your experience, especially related to entrepreneurship. Are there things you wish you had done when you were a student that you did besides taking a vacation after graduation? Things that you had would make yourself, things you would have learned, sort of things you would have classes you would have taken?

Yeah. Great question. There's really only one big one, and that's go abroad. I never thought I had time to go abroad and so never traveled anywhere. And I would have loved to do that. In retrospect, I'll say one other thing, which I did do, but I think looking back was more valuable than I understood it to be at the time, and that is try to do something that is aggressively outside of your skill set. So I was a CS major. I love coding. I still love coding. I spent literally every hour that I wasn't in class coding. And I decided my sophomore year to get a marketing job and be a campus rep. And it happened to be Apple, which was a smooth transition into marketing. But that was actually incredible in retrospect. And I didn't appreciate it at the time because it forced me to talk with people and meet people and be able to explain products and think about it from the user's point of view instead of the code point of view. And so my advice would be like, do something totally outside your comfort zone while you're a student, because you can and no one cares. And it's a great, great learning opportunity. And that will help you sort of see a broad perspective as you go forward.

I'm sure you will agree that this was totally fabulous. Please join in.

Thank you. Thank you.