Why Crashlytics was Acquired by Twitter | Twitter's Jeff Seibert

So I want to step back and talk you guys through sort of my career in entrepreneurship and some of the lessons I've learned over the past 5 years. And the most recent project I was working on was a company called Crashlytics. And we got started because we realized in 2011 that there were tons of mobile apps out there, hundreds of thousands, now millions of mobile applications out there, and they had a tendency to crash. Who here has noticed one of their apps on their phone crash? Me. All right, see, almost everyone. So it turns out that mobile apps crash over a billion times every single day. Cool. And everyone knows this sort of. They know a piece of this. But the bigger problem was the developers of these apps did not know this. They had no idea. And they had no way to fix the problem because they didn't even know it was happening. And so all they saw, if you were using Apple's iTunes Connect thing or if you were using Google's Play Store, is you periodically see some of these. And so this is a default Apple crash report. This is actually from the Twitter app. Yes, the Twitter app does tend to crash at times. And I don't know how many of you are familiar with looking at these, but all of the important data is right in these numbers right here. Doesn't that make it just incredibly easy to fix the problem? Doesn't that tell you exactly what's going on? Yeah. So that's exactly what we hit up against. This is what developers all around the world were struggling with. They got these in their inbox. They got tons of these in their inbox. And they literally had no idea what they meant. And so we're like, okay, we can do something a lot better here. So we built an SDK originally for iOS, now for both iOS and Android, that sits in your app. You put it in your app. It's a chunk of code. And it does nothing. It sits there silently. It doesn't impact performance. It doesn't start any threads. It really literally sleeps until your app crashes. And that's when our code wakes up and as quickly as possible tries to figure out what happened. Dump that to disk on the device, and then the next time the user launches the app, which tends to be immediately because you're like, ah, it crashed, and start it again, then we send the data off to our server. And so we're able to take that data and convert it into hopefully beautiful issues aggregated into the bugs in your app that you need to fix. And so this is just a quick preview of our dashboard, but basically for a demo app, here would be all the issues in your app, here are how many times the crashes have happened, and we rank them of course. You can fix the top ones first. And we found actually that if developers fix their top 10 bugs, that usually represents about 90% of the crashes in their app. So there's a really high impact to knowing this data and fixing these bugs. And you can make your customers radically happier. So right when we were getting started, we came up with our iOS SDK. That part was actually pretty straightforward. We started the company in May of 2011. And we had the product working. Within the first like 30 days. The SDK worked, our backend processed the crashes, it showed them in a very hideous dashboard. Like the product worked. And my co-founder was not excited to launch. And it made a lot of sense. So this is why. So if you look at how SDKs get installed in apps, it tends to be relatively painful. And so we picked the cream of the crop. What's the best company in the world doing at the time? And that was Facebook, of course. And okay, how do you install the Facebook SDK? Well, if you've checked out their website, this is literally how. You could like actually get a coffee while trying to read the instructions. And finally I can start coding. And that's like half an hour later. And so as we looked at this, we're like, okay, we are never launching until we can be radically better than this. I never want to launch a product that is this difficult to use. And so Wayne, my co-founder, challenged me, how many of these steps could we actually remove if we put a lot of work in and spent the time? 4 or 5. Sorry? 4 or 5. Exactly. So as I looked at it, pretty much all of them. And so what did we do instead? We spent the next 8 months— remember, we'd built the product in about 30 days. We spent the next 8 months building the installer. And we came up with this. So when you sign up for Crashlytics, you actually don't get an SDK. You get a Mac desktop app. And it's an Xcode plugin. It integrates with your IDE. That's how everyone builds iOS apps around the world. And it is literally a drag-and-drop install. When you launch this, we present you the list of your Xcode projects because we've scraped Xcode's data files. We know what projects you have open. And we show you the list. You select the one. We open that project for you. And you drag and drop our icon into your project. And that drag and drop action gives us all the information we need to, in the background, go and inject it into your project as necessary. And so we've literally taken it from a 30-step process to 30 seconds. And our goal was, how can we deliver you value? How can we prove that Crashlytics is worth your time within the first minute? And this was a critical piece of that. And so what did this result in? Here's just a sampling. We've gotten thousands of tweets over the past 3 years. This last guy, Danilo, is awesome. He was the lead developer at Hipmunk, if you're familiar with them, an awesome travel booking app. And as you can see, these tweets just started to catch like wildfire and were retweeted by developers. And this was substantially all of our inbound leads. So people would tweet because they were blown away by our install process. They'd never seen anything like this. They'd tweet about it, and developers love checking out awesome implementations. They would go see that tweet and go sign up. And it just kept going and going and going. So this was pretty much our viral loop. Our product didn't have much innate virality, like much forced virality where you had to invite other people to use it. It was all word-of-mouth virality because they were so blown away by the first 30 seconds. And so huge thanks to my co-founder Wayne for teaching me this lesson. Maximize your FTE, which is your first-time experience. I think we've entered a world where a lot of tech startups are pretty commoditized in terms of the technology. Like realistically, it's not that hard to build a website these days versus in '98, '99 it was. And so you need to set yourself apart with something else. And for this, it was design. Like it was experience. It was how can you totally blow people's mind. And I think design is still an area that's been very hard for people to replicate, is you definitely need some skilled designers on board to make this happen. Again, fast forwarding. December of 2012, which is crazy that it's now over a year. So we'd been going along. We had, as I'd shown earlier, gotten quite a bit of traction. We were working with many, most of the top apps. And out of the blue in mid-December, we get a call from Twitter. And they said— and they were one of our customers. They were, I guess, technically our largest customer. But it still sort of surprised us. And they said, hey, have you guys ever considered working for Twitter? No. And I was like, no, why would I do that? And they persuaded us to come out and meet them. And so this is actually us projecting in Jack Dorsey's conference room at Twitter headquarters. And begged us to come out there. We based the company in Boston, we'd started the company in Boston. And so we flew out here and met with them. And they ended up presenting this deeply strategic vision of why they thought we should join forces, they thought we should join Twitter. And I was like, and bring our roadmap and build it internally. And unfortunately, I still can't go quite into the full vision because we're still in the process of launching it. But this really, I guess, surprised us because we had zero interest in being acquired. We had raised 2 rounds of funding. We had only spent about half the money we had. We thought we had a great roadmap. We were about to launch on Android. We could see a great future for this tool. And so then you have to think about, okay, well, if I'm considering an acquisition, Why? What's the goal? And so I'll jump forward, and as you know, we went through with it. We ended up signing the term sheet on Christmas morning at 10 AM after being up with them negotiating till 2 AM Christmas Eve, or I guess Christmas morning, which I'm sure their exec team loved. And so why? Why would we do this? And so a lot of people, when you start a company, ask you, Okay, what's your goal? Are you building this to sell or are you building this to IPO? Have you guys heard that question before? Yeah. Okay, so everyone asks this. I hate this question. I think it's the wrong question because I think what they're actually trying to get at is what they really mean by that is, oh, what's your definition of success? What are you aiming for? But then they presented 2 options and neither of those are success for me. Like, why would you ever start a company in order to exit it, in order to IPO it? get acquired or IPO or something. You're cheapening the mission of the company. And so when I start a company, we started this company to help every app developer on the planet make their apps better. That's the only definition of success. Like if we do something else, then we've failed. And so I think like an IPO or an acquisition may be a means to the end, but it's never the end itself. It's never the success of what you started out to do. So you're saying that the success of the company is not the acquisition or the IPO? And so as we were thinking about this, the reason we ended up going through with it is because we did believe in their strategic vision. We believed that Twitter and being a part of that brand would make us the de facto tool in the market, and substantially every app would use us. And so I think that has been proven out to a degree. A lot of our competition has sort of faded away, which has been great. But we're still very on, very early on. Yeah. Like, our acquisition a year and a month ago certainly did not make us successful. Twitter's IPO certainly did not make Twitter successful. Their goal is to serve every person on Earth and let them communicate. And so I think when you're asked this question, try to reframe it as like, what do you want to do with the company? What problem are you trying to solve? Because if it's only pictured in terms of some exit, I think that very much cheapens all the years of hard work and strategy that That you've put into this. Otherwise, just go into banking or something. And so the other big lesson we learned is the culture fit is absolutely paramount. Is make sure that when you're talking with a potential acquirer, in the same way you talk with investors, that you really, really like who you're working with, that you think your teams will gel, that you'll be able to be productive working together. Because I think a lot of people tend to focus on, oh, the exit. Oh, we just got paid. And then they forget the next 4 years they're going to have to work at this company. And so that was a huge force. And again, the only reason we did the deal is we felt that Twitter's culture was incredible, very similar to ours insofar as people were very laid back and chill, but also incredibly bright and sort of passionate about what their dream was, what their goal was. And then I just threw this last point on. I don't have a specific story, but everything is negotiable. It sort of surprised me. What is totally up in the air. And when you start a company and you worry about all the incorporation documents, there's all these weird minutiae that you have to discuss on like, will there be acceleration on change of control and all these things that get written into the documents? None of it really matters. It's the— like, yes, it informs the default case, but basically when you go through an acquisition process, they can rewrite any document in the history of the company. So don't worry if there's something not quite right, and make sure you bring it up when the time is right.