The Meteoric Rise of Twitter's Senior Director of Product, Jeff Seibert

So I'm currently at Twitter, and Mobile Platform is basically our way of talking with developers all around the world. So the way you can think about it is, yes, Twitter's mobile. The company's always been mobile. They started with an SMS product. And so now they're big on apps and smartphones, of course. And I'm not focused on those. I'm focused on everything else developers around the world are doing on mobile and how hopefully they can leverage not only just Twitter, but some of the tools that we've built to hopefully make their apps better. So who here has used one of our mobile apps? Cool, okay, almost everyone, a little more than half. Awesome, so at least everyone here is familiar with Twitter, yes?

Yeah.

Cool, okay, so that's great news because I'm not gonna talk about it. So let's talk about something much more interesting. So I wanna 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? 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? 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. All right. And so over the past 2 years, we've been very privileged to at this point work with most of the top apps in the App Store. So I can almost guarantee you that apps on your phone are running Crashlytics. It's been a hugely fun journey. And we were excited enough to be acquired by Twitter in January to keep building it. So I'll talk about that a little bit later. But what I really wanted to talk about today was my entrepreneurial journey, as I talked about. Are you familiar with ETL? Has Tim already talked about this?

No.

How do you know it?

I've been there. My brother is a Stanford student, and I've been actually Tim gave the lecture that I participated in.

Awesome, awesome. So my entrepreneurship journey started, I was a freshman at Stanford in 2004, and I found about— I found out about Entrepreneurial Thought Leaders, which is a lecture series the school puts on every single Wednesday. They bring in a CEO or investor or founder or lawyer, someone in the startup sphere of influence to come speak to the students and tell their story. The better news for you guys is this is available online at etl.stanford. It's a podcast on iTunes. You can watch it. They've been watched millions of times by people around the world. And this is literally how I learned about startups.

Awesome.

And what's even crazier is that the full name of this lecture series is called the DFJ, Draper Fisher Jurvetson Entrepreneurial Thought Leaders Lecture Series. So Tim gets a ton of credit for sponsoring this and bringing it to Stanford. So that's where I was, basically sitting there every single Wednesday listening to these amazing speakers. This happens to be Carly Fiorina right after she left Hewlett-Packard. And 2 years into this, started getting a little bit frustrated with it. There were all these people with such incredible stories, And here I was sort of stuck in this lecture series every day watching these. And so I put together a group of 5 friends from school and we decided, okay, well, let's meet and let's just discuss things. Like, what would happen— oh, sorry.

All right.

Before I get there, what we'll talk about today is sort of 5 very practical tips that I've learned in going through this. And so we put this group of friends together and we're talking about, so what if? What if this existed? Like, would this be a cool business? And our goal with these discussions wasn't to start a company, but to train ourselves to evaluate what we thought would be good companies to start. And so we ended up meeting twice a week for like 2 hours. And every single time we'd come up with these ideas that we thought were amazing, that like, this is going to kill Google, because that was the stated goal in '06. And so we're like, yes, this is the greatest idea ever. And so, all right, we brainstorm, we come up with this great idea. We'd go back home to our dorm rooms and do a little more research, look at the competition, look at the space more, and come back at the next meeting and realize that that was perhaps the stupidest idea that had ever been described. And either it was not technically feasible, there were already way too many people doing it, we weren't the team for it, whatever the reason was, this was absolutely terrible. And so 2 months into this process, we got a little bit more frustrated. Okay, now we had just all these brilliantly terrible ideas. And nothing really to show for it. And so we decided, all right, well, let's take a step back and just build something. And so we ended up building an idea sharing site to share all of these bad ideas. Because we figured out, well, that— all we have is ideas at the end of this process. Let's do something with those. And so we did this as part of actually our senior project computer science class. A few of us were CS majors. And built it as part of the class. You were supposed to come into the class with a team and an idea. So that worked. And then at the end there was a competition. And much to our surprise, we built this basically idea-sharing website where it's a super simple forum. You post an idea, people can respond and give their feedback. And there was a way to star ideas, and then our technically complex portion was, all right, well, let's do some natural language processing, let's do some clustering, so then we could intelligently pick out related ideas and maybe have a network of ideas in the system. Much to our surprise, we actually ended up winning the class competition. And so that started us thinking, like, well, is this a business? How could we do something with this? And this now, fast-forwarding, this was the spring of 2007. And so we started working on the project through that summer. And as things progressed, we started realizing you could sort of see the US housing market teetering. Like, the economy was not doing great at that time. And as we looked at the idea-sharing space, which To our surprise, there was actually an idea sharing space. Companies like Intel and HP and Hewlett-Packard and IBM pay massive amounts of money for innovation idea sharing software, which we had no idea. As we looked at that space, we got worried that if the economy tipped over, well, maybe they— the first budget they'd cut is this sort of fluffy innovation budget. It's not really directly aligned with their business. And so we started thinking, okay, how could we make this— how could we stay true to our vision But how could we make this a little bit more concrete, a little bit more likely to succeed as a company? And so we shifted gears and tweaked the idea slightly and decided, okay, well, in enterprise, in these big companies that are paying for this software, every idea eventually takes the form of a document. It has to become a presentation that you're going to present to some sort of exec at some point. And so what if we sort of ignored the idea side and focused on the document side? What if we sort of pivoted a little bit and created a product to let you easily get feedback on documents? And so that's what we decided to go off and build. This is the first screenshot of the first prototype. Feedbackr was our real code name because this was in '07 when Flickr was hot and it was cool to put an R as the last letter of everything. And so it was super simple. You upload your image, you write sort of what you wanted feedback on, and then people could talk about it on the other side. And that was it. It was like the most minimum of MVPs ever. And all right, well, this is interesting. How can we go forward on this? And so we actually ended up, fast-forwarding a little bit, pitching DFJ on it and raising money from Tim. He got very excited about the concept of helping innovation within companies on the idea side and later on the document side, and so started working with DFJ. And we made it. We kept going a little bit and got the prototype working, got it up live online. And the spring of our senior year, we ended up launching on TechCrunch. And we thought like, oh, this is amazing. We've succeeded, right? Like, all you want to do is ever launch on TechCrunch. This is fantastic. And what's great looking back at it is, wasn't TechCrunch like easy to read and free of ads in 2008?

It was.

It's so simple. And so we were like, yes, okay, we've totally succeeded, we've won. Not really. So we launched on May 14th, you can see the spike, and 2 weeks later our traffic was back down to zero. And we were like, oh no, what happened? But the product was so easy to use, it was so simple, it was so powerful, it was great. And it turned out that we really, yes, we had created a product that was usable, We hadn't thought about how people would actually find out about it. And so yes, a bunch of people found out about it from TechCrunch, but as soon as that article went off the front page, no more traffic really came. And so this was our first big lesson learned, is we had failed to balance our team. We were a bunch of CS majors who coded a product that looked somewhat attractive, that we thought was very easy to use. And yet we didn't understand, or we didn't overestimate enough the importance of the skills we lacked. We totally lacked anyone on the team who knew anything about marketing. And not only that, we lacked anyone on the team who cared in the slightest about marketing. Because even if we didn't know anything, then we could at least have gone and learned it, but we weren't interested. We would much rather code. And so that was our big mistake early on. And following on to that, distribution, you might have heard this saying already, distribution is truly king. If you do not figure out how someone's gonna find out about your product, it's going to fail. It's no longer the case that, oh, build it and they will come. Definitely not true. There's too many websites, there's too much going on, people don't have enough time to just sort of stumble upon and find your thing. Don't build a distribution strategy based on stumble upon either. So you're saying that the best way to do distribution is to build a product that's So any questions about that before I move on? All right, so we thought, as a team, we thought marketing was black magic. We thought we had to go out and hire somebody that had this marketing brilliance that we could bring in and help us. And so the second sort of mistake we made was we spent months trying to find this marketing person, interviewing a bunch of people, trying to find someone who would work well with the team, and what we really came to realize is, as Rand Fishkin has written, there is no black magic to successfully attracting customers via the web. All it takes is a lot of work and a lot of thought and a lot of discipline and a lot of strategy. And think very carefully about why someone is going to find your product, how they're going to find it, who's going to tell them, and once they're using your product, how do they spread the word about it? Because otherwise I feel your marketing costs are just going to be absurd. And so we did push through this. We ended up spending a lot of time ourselves on forums talking with people, doing research, interviewing customers. And the traffic did slowly start to pick up and climb. And so let's fast forward a little bit, another 6 months, and we had made the product a lot better, gotten a lot of feedback. We converted it into a fully real-time document collaboration tool. So now just instead of images, we actually supported 100 different file formats in the web browser, anything from Word docs and PDFs to native Photoshop files and native Illustrator files. We displayed them in Flash because This was 2008. And what was actually pretty cool for the time was it was all real time. So if you had multiple people typing and adding comments to the document, they could all see it wherever they were in the world. And so started working on this, started getting interesting traction among the freelancer community. And we started thinking, well, how else could we support the business? How could we become profitable? And one of the ideas we had was, well, what if we ended up powering document display In another big company. What if— so let's imagine Box had a lot of files. They do. What if they needed to display them? What if we could take our player, and if you notice, despite the light gray coloring instead of the dark gray, this is exactly the— oops, didn't work. This is exactly the same document viewer. What if we were able to just sort of offer this as a product to other companies and they would pay us a very low amount per document to power this capability. And so we started looking at that, we engaged 4 different big document startups in the Valley, Box being one of them, and they were all universally interested. That was fascinating to us. And so we started going down the road of, well, okay, how would these partnership deals look like, what would the revenue share be, and so on. And they all were interested except for 2 caveats. They wanted it to be exclusive because they didn't want their competitor to have the same thing. And they wanted to host the technology so they didn't have to change their end-user license agreements and their terms to allow them to share the private documents with a third party, us, in order to view them. And so both make perfect sense. The problem was we really needed more than one partner to be profitable, and we really needed to own our technology, otherwise what did we have left as a company? And so what ended up happening is we said, well, that sounds far more like an acquisition. Than a partnership. And so we quickly turned the discussions around, and in September 2009, we ended up being acquired by Box, as that screenshot probably gave away, and have been powering their document preview ever since, which has been a lot of fun. And it actually stayed the same, it stayed identical until 2 months ago when Box rolled out another solution that they had bought from a company called Crocodoc. So for 4 years, Increo's tech was exactly how people in Box viewed their files. Which was a lot of fun. So the next thing, next topic I wanted to talk about was fundraising, because over the past 5 years I'd say most of the questions I've ever gotten have been about fundraising. And I think this is another area where you can be very logical and meticulous about how you go about it to increase your chances of success. So the most common intuition I've seen is this. You're going along, building your product, trying to figure out what's going on. You shape the company, you get a team together, you get a prototype working, you launch your beta, and you're like, oh man, okay, that was a lot of work. Finally we have some time, the beta's out there, now it's time for me to go raise. Does this sound familiar? Does this sound intuitive?

Yes.

Cool. So this, I would argue, is exactly the wrong way to go about it. Here's why. So broadly, and I'm going to make some generalizations, of course there's exceptions, but I think this is broadly helpful. I'd say investors fall into one of two camps. I believe there tends to be investors who are more vision-driven, who care much more about the dream, about the end goal, about how this is going to change the world. And there are investors who are more momentum-driven. Like, I want to see your graphs up and to the right. I want to see your revenue plan. I want to see your servers melting and catching on fire. I want to see everyone loving you right now, and that's how I know that this is on the right path and I should invest. And for both of these, raising money right after you launch just doesn't work. So let's talk about momentum first. Alright, they want to see numbers and graphs up and to the right. Well, you just launched. You don't have any data. You don't have any traction. How would they be impressed with your first month's numbers? They don't see any slopes. On the dream side, I can guarantee you that your MVP half-baked beta prototype that you just launched is not exactly meeting the grand dream that you just tried to pitch them on. And so now you've gone and sort of burst their bubble. They were envisioning this perfect magnificent thing, and you've burst their bubble with your prototype. So that's probably not great. Really you want to say, oh no, it'll be better, we haven't launched yet, don't worry. it's still going to approach that vision. And so this does not work. Now it depends, okay, what type of pitch you want to do on what round you're raising. Obviously earlier rounds, seed rounds, A rounds, you can target more vision-driven investors because your potential is unrealized. By the time you get to a B or a C round, you probably need some revenue traction. You probably need someone who's going to invest based on the momentum because it's hard to say, oh, 4 or 3 rounds in, The dream still hasn't materialized. And again, focus on what type of investor you're pitching. People always ask me, how do I know what type of investor they are? You can talk to or look at the companies they've invested in. And have these companies, like, do they have traction now, or are they pitching a big thing down the road? Talk with the entrepreneurs at those companies. What type of pitch did they use? Or just go for it and meet with the investor. And pick the style of pitch that's best for your business, and it'll either be attractive to them or it won't. And if it doesn't, that's fine, just move on. And yes, and of course, what type of pitch does your business currently lend itself to? If you don't have traction up and to the right, I really hope you can make a very strong vision argument. Does that make sense?

Cool.

All right, so then the other thing, The other mistake I see lots of people make is they're going along, they're building their company, they decide, okay, it's time to raise, and all right, I do a meeting, and wait, the investor didn't say yes, why not? Like, I expect I do a meeting and I get funding, right? And that's totally wrong. On average, it takes 6 months to raise money. And so how can you build this in? You can't afford 6 months of your time only spent fundraising. And the bigger issue, the reason here, is, in my view, investors don't fund dots. And a dot is just a meeting. And so you've been invisible to them before. You're going along building your company. You meet with them, and you put a dot on their radar. But that's just one point. And so you could argue, okay, well, investors don't fund dots because, who knows, it might fall off after that. They need more data points. Well, okay, you could say no, investors need at least 2 meetings. Investors fund lines. And there's a very famous blog post by Mark Suster who— that's exactly this, that investors fund lines, they don't fund dots. And so I'm going to actually respectfully disagree with Suster and say I don't think investors fund lines because they're looking for nonlinear return to the capital they invest. And if they're funding a line, then you're not going to provide that. You're just going to provide a linear return. And so I'm going to argue that investors fund curves. And we all know it takes 3 points to define a curve, so you need at least 3 meetings so they can see the ramp of your product or your dream or your traction, whatever it might be. And so this is why, on average, it takes 6 months to raise funding, because you need time to do these meetings and show them this progress. And so, okay, well, how then do we make this fit into our schedule, fit into our timeframe of when we need to raise, I can't just stop working on the product and then spend 6 months doing meetings and hope funding comes out at the end, because then I'll have a product that's 6 months obsolete. And so the key is to always be raising. And by this I mean meet with investors constantly throughout the life of the company. And that's how you get these dots, how you start forming this curve, because they're seeing you as you're progressing. And I think some of the most powerful and most helpful meetings with investors are when you don't need funding. Because then it can be clearly focused on feedback and they can give you advice. And anything they talk about with advice, you should take as signals of what they're looking for, of what's important to them. And it might not mean exactly following what they said, because you don't want to sort of take your company in every different direction possible, but you want that to be a sign of maybe what they're thinking about, of what your company causes them to worry about, and what you'll need to address better at the next meeting. And so by always raising, and like I met with a VC yesterday, I don't even have a company, I work for Twitter, but it doesn't matter. Like now, if I go and do something in the future, they'll still, you'll build the relationship, they'll know who you are, and hopefully then when the time comes to actually close your round, they'll be ready to close the deal and write the check. Does that make sense?

Yeah. Closely related, I think Steve Jurvetson a couple weeks ago said that, Like 90% of VCs are not really of a significant caliber.

Yep.

Is that— should we avoid taking most people's money if at all possible?

I would, yes. I think it's very, very important to— the most important thing is to have a good relationship with the partner. The firm, I think, is largely irrelevant. You want to find a partner you deeply trust and believe in because they're the ones that are gonna be by your side throughout the next 5 years, and you need to have a good working relationship with them. So I think that's most important. But I agree with that. I think that the value, the sort of the extra value firms add, is probably controlled largely by the top firms because they have the best networks and the best connections, the best recruits they can intro you to, simply because of their reputation. But it is true, I read that 75% of investors have never made money in their history of VC firms. And it makes sense because they raise a fund, it takes 10 years for the fund to mature, and so who knows what will happen. And they might even be able to raise a second fund before it's proven that their first fund was a failure. So it's only the top 10% of VCs repeatedly make money. So how do you know which ones to invest in? What's a good investor to take money from? You say you'll always be raising money, so— So it's— that's a great question. We're lucky in that Silicon Valley is the hotbed of top investors in the world. DFJ is certainly among them. And so if you go up and down Sand Hill, I mean, there's a ton of awesome firms. One way to look at it is look on Crunchbase. Are you familiar with Crunchbase?

Yeah.

So it's TechCrunch's sort of data segment. they list all the firms that have invested in all the different companies. So pick some of your favorite companies, see what firms are active. That's probably a good way to go.

Just one note to this, Crunchbase is actually curated by people, so sometimes the information is not correct. So you have to verify. And actually, I usually do verification for Crunchbase and AngelList together.

Also Gast.

Gast? Not familiar with that. No.

Well, the founder is David Rose. He's also founder of GUST.

GUST, okay.

Yeah, the founder is called David Rose, and he's also one of the co-founders of an angel group on the East Coast.

Oh, cool. New York Angels?

Yeah, exactly.

Okay, cool. Yeah.

Do you think that investors always provide real value to startups and founders?

Always? Probably not. I'd say a lot of times, yes. I mean, if you're able to, it depends what you're looking for. So if you're able to self-fund the company, certainly that would guarantee the largest monetary outcome. I don't think that's what you're going for. I think your mission is to learn as much as possible, to become the best entrepreneur you can, and that's why you bring the investors in. Because they've seen it before. They just, by simply seeing so many companies, they can identify patterns.

But sometimes it just doesn't work. You said that investors, when they come with you on board, they might be restricting you with decision-making and everything. Because before then, you were independent of taking any decisions you wanted to.

Yep.

What has been your experience with that?

Yeah, there's definitely— that's true. I mean, you are granting them some power, some control of the company. But I think it goes back to my original point where the most important aspect is the partner you work with. Because if it's the right partner, Then you'll make decisions together. They'll trust you with your perspective. They'll give you the leeway you need. I think it comes down to that.

Cool.

All right. So for the next story, back to Crashlytics for a little bit. 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 some 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 had 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 then what?

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.

Yeah.

to make this happen. So as the CEO, I believe very strongly that your sole job is to make yourself irrelevant. So whatever you are spending your time on, you should hire for. And so I had to spend 100% of my time coding, because Wayne was more on the marketing side, which was critical for us. And so we first started hiring engineers. And then we did that, we built a team of 6 engineers, I spent, I was spending all my time recruiting. So we hired a full-time recruiter as our number 8 employee. And I think that is one of the biggest decisions that made the company successful, is because we then tripled the team in the next 5 months. Because she was now full-time on recruiting, and even though I had spent most of my time on recruiting, you can never really go full-time on recruiting as the CEO. And so we just weren't doing as great of a job at it as we could. I guess the one area then, sure, I spent probably 2 months fundraising. It's hard to replace yourself there. But then we, I had to spend most of my time doing engineering management, so we hired a director of engineering. Then most of my time doing product strategy, so we hired some PMs. It's sort of a perpetual cycle. Like whatever you get shifted into, you hire and replace.

Thank you.

Cool.

All right. Last one. So again, fast forwarding. So this is 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?

Twitter.

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 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, OK, 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:00 AM after being up with them negotiating until 2:00 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 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.

Yeah.

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. 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. 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 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 huge for us. 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 are very laid back and chill, but also incredibly bright and sort of passionate about what they're 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 So don't worry if there's something not quite right, and make sure you bring it up when the time is right. And so that's all I had prepared, but I'm happy to talk about anything else and sort of the whole story that would be helpful or answer any questions. I think we have a little bit of time left.

Yep.

Perfect.

Yeah. So out of the group of the 5 guys in Stanford, have you all gone to start companies, or was it just you? That's a great question. So we had a mix of people. So 3 of us were computer science. One was an anthropology major, but we involved him because he just, he has this weird thing about him where anything he touches becomes huge. And so he went off. I don't know why. He went off and made a movie. And the movie is called Chasing Ice, and it was nominated for an Academy Award.

Wow.

So he has continued on his path. It's a great, great film on climate change if you're interested. It's a documentary about glaciers all over the world. So I strongly recommend checking that out. And then the other guy was on the marketing side, but ended up leaving us before we started the company because he wanted to do something more consumer. Again, we had pivoted into sort of enterprise document feedback and idea sharing. And he started a company called Sharethrough.

Yeah.

Okay, you mentioned that build to succeed, not to exit, but at the same time, as an investor, because I do work in this space, I'm from the dark side. So I know that one of the questions that we usually ask is, so what is your— like, how are we going to return our money? What do you answer to this?

Definitely, definitely. And so I think you have to have a reasonable plan, right? You need to have a product that will either be attractive to potential acquirers or that could reasonably IPO. I think those eventualities still have to happen. You're certainly right. If you're building a lifestyle business, if you're starting a retail store that's just going to continue operating, you're not a target for VC money. Is that fair?

Yeah.

But I think you as the entrepreneur, your goal has to be greater than So yes, you guys have to exit, but I think the entrepreneur's goal should continue.

What about the go-to-market strategy? How did you come up with this?

For which, or just in general?

For Crashlytics.

I mean, we were brainstorming and just looked at sort of the equivalents in the space and what the experience was, and that's what we chose to focus on. I think as a company in general, we've been very disciplined. And so maybe you could tell this from like the thinking through the fundraising process, the thinking through the user experience. I'm not talking about spending a lot of time and like going back and forth and back and forth on every decision, but at least having a reason for each decision. So like we were very conscious. We knew we were targeting the onboarding because we thought that that would improve our word-of-mouth hierarchy. And at least by sort of writing those things down and remembering the reason you made every decision, and for example, I could go in depth about like the reason we brought in each investor into the company and why them and not someone else. By writing those down, you can test yourself and you can sort of prove out, are you making the right assumptions or not?

Which leads me to my next question, the advisory board. So how did you build the advisory board and how did you choose who to invite?

Great question. We actually only ended up having one person on our advisory board. So you have your board of directors, right, and those are your investors. You have your advisory board. Advisory board's a tough thing, because if you have just a lot of friends in the startup scene, you can sort of get good advice without having a formal advisory board. The benefit to a formal advisory board is they are obviously somewhat financially motivated to support the company, because you give them some stock, and you can formally use their name with customers and the press. And so the guy who joined our formal advisory board was Aaron Levy, who's the CEO of Box. And so obviously I'd known him from before, but he was also very well respected in the enterprise space. And so we had him join the advisory board, so as we were targeting the bigger companies, like as we went after Walmart and some of the banks, we had someone to point to who had sold to all of those guys before and knew them.

How easy or difficult was it for you as a startup or a company to take the decision of getting acquired by Twitter?

It's a great question.

Both.

It was very hard to decide to be acquired versus continue to go independent. Given— and so the only reason we did it was because Twitter made it easy. They presented this very compelling vision. They gave us a lot of independence in the company. We still operate relatively independently from the company today. I mean, we're still, apart from Vine, which is a few guys in New York, we're still the only team at Twitter that doesn't directly build Twitter. We build Crashlytics, and we build some other dev tools. And so I think they set up the circumstances that made it easy for us to say yes, and easy to believe them that we'd still be able to keep what was important to us.

So you're saying that the What are some situations you would say or tell us, suggest us, that we as aspiring entrepreneurs or entrepreneurs should say no?

Should, sorry?

Should say no for an acquisition offer.

Should say no to an acquisition offer. When would you say no? So if I go back, if it does not fit your measure of success. So I'm not in general a support of acquihires, of these talent acquisitions, because by definition that doesn't meet the success constraints of the team. And yeah, no, go ahead. How long lasts the negotiation process? It varies. So when we were negotiating with Box, that took 2 months. With Twitter, it took 5 days. But it was, it was far more intense. I mean, we were on the phone with them pretty much straight for 5 days.

They—

so it comes down to also to the company buying you, which I didn't realize, is Box had never bought a company before. And so they were trying to figure it out as well. Twitter buys at least one company a month. They've done 36 deals. And so they are super professional at it. They know exactly what to do, what all the stages are. They have all the documents already written. It's very easy.

I get the vibe that if Zuck or PG were here, they wouldn't open the door for me unless I could prove that I could code. That this whole everyone must code philosophy is important. important to some people who know a lot. Is it okay, can one still make significant contributions to the startup ecosystem if that's not their strong point? If they still know a lot about tech but don't feel a passion for that? Or should everyone know how to read and everyone should know how to code?

That's a great question. Everyone should understand just technical ideas. So you're not gonna be successful if you don't like talking about technology. You don't need to know how to build it, but you should know what JSON is, you should know what REST and AJAX are, you should know what the different terms are. Because that's how you'll communicate effectively with the rest of the team and by translating that with your customers in terms of benefits that they derive. And so what I'd encourage you, if you don't have the passion for coding, gain the passion for like absurd customer experience and design because I think those are the 2 pieces these days at least that are critically important.

Cool.

It seems like your various products have had a pretty outstanding pattern of iteration and being able to say, like, making observations of, like, oh, people are using it this way, or, like, oh, this tool could be used this way. And, like, I mean, even what was originally Feedbacker changed its name multiple times.

Yep.

Can you talk a little bit about what goes into that iteration process and, like, how you make those observations, what you What you listen to, what you look for?

Yeah, you look for patterns. Because I think you can make the mistake both ways. You can either totally ignore the market feedback and just say, no, I'm doing what I'm doing. Or you can be overreactive and you get one email complaining about something and you immediately change course, and then someone else says something different and you end up going wiggling back and forth. And that's useless. And so I think you need to keep a certain distance from it. But still be familiar with it. And so what we've done is we aggregate all the feedback that comes in. So everyone who emails us, we get back to them and we respond and we say, awesome, really appreciate the feedback. Here's another thought about it. Or yes, it's on our roadmap. Or yes, we've been thinking about that. Just to thank them. But we don't immediately act on it. We aggregate it into buckets and then try to act on those patterns. So if we're seeing a big move in one direction, then we'll explore it.

So you're saying explore that you're not necessarily looking at that the feedback more deeply.

But I think going back to the Apple versus Google thing, our team has more of a mindset of our visions driving it. And so that customer feedback tends to guide our vision, but not the exact requirements of the product. So people will want— people will say, oh, I really wish you had this small feature, or I really wish it did this. We totally disregard that. I think you need to get to the root cause of like what problem are they trying to solve, and then we'll come up with our own vision of how we think they should solve that. So you're not trying to solve the problem.

And then operationally, I mean, do you guys have like a separate person or team that does that? Or is it just—

What do you mean operationally?

Like in terms of like specific roles. Like for example, I used to work for Foursquare and we had like a community team that would put all of that stuff together. Yes.

So we have a 2-person developer relations team that talks with all our developers. Before that, they were late additions to the team. Wayne, my co-founder, personally did all of the customer support. support and customer interaction. He personally hand-invited the first 20,000 users because— so we have an email thread with every single one of our customers. To this day, you cannot sign up to use the product. Like, we launched and were acquired and the product is still private. And the reason is, it's still pretty quick to get into, you type in your email address, but you'll get an email in a few hours. You can't just start up and like sign up and start using it. And the reason is that relationship. And so by forcing us to manually reach out to everyone, we now have a thread with everyone, and if they ever have a complaint about the product, they don't tweet it. It's mind-blowing. They just respond to that thread, because they have a direct line to either our dev relations team or the chairman of the company. Yeah. When you guys first got started on FeedbackHerb, what was the work condition you guys were in? Were you paying for it out of pocket? We were, yes, we were paying for it out of pocket. Everything else was free because we were in school. So we had our computer and internet and dorm room and so on. We paid for it, and that did of course guide our decisions. We went as cheap as possible. I think we got like a $10 or $20 server on Joyent at the time. I mean, it was very, very low end. And then once we raised money, we shifted it off to Amazon. And the same thing with Crashlytics. The first thing we put up was on Heroku on their free boxes and then quickly moved to Amazon.

Yep.

All right, let's— yeah.

Okay, I'm just curious, how do you keep track with your competitors and the features that they're building? And in general, initially when you start to do an idea, how do you do the competitive analysis research? And the market research?

Yeah, so I think 2 separate questions. So getting started with the idea, I was decently thorough in looking at the competitors, basically checking out their websites, Googling reviews, Googling how they're talked about on Quora, how they're talked about on random forums. That I think we were pretty thorough in. Afterwards, after we launched, we basically ignored them. So again, it goes back to the vision thing. Like, we had a vision for how we'd create the product. If the competitors did something well, it would eventually funnel through the customer feedback. So that was the input cycle, but we didn't care what they did. Yeah?

So earlier on, before you had kind of established a network, in like your first stage of going through Yeah. How did you initially reach out to VCs? I mean, as a young, still student at that time, what did you do?

Yeah, so that goes back to the lecture series. I think we had a bit of an unfair advantage because the lecture series has dinners after each speech, and you could sign up to go to the dinners. And so I met a bunch of the VCs. And then I also ended up running the lecture series for 2 years. And so through that, like, we had to reach out and invite the people and so on. So I had a lot of connections. But I would be aggressive at going to startup events, and investor events for that matter. I mean, there's dozens in Silicon Valley every single night. And there's a mailing list called Startup Digest that lists a lot of the big events. But I mean, you can just Google and find other event indexes. It definitely takes time. There's no easy way. But I would just be sort of passionate and excited about what you're working on. But also don't go up to someone and just pitch them. Ask what they're doing and what they're interested in and what's the hottest thing they just saw. And try to be helpful and basically say, see if you can make an introduction, see if they need help with anything. I think it is just sort of a slow process to build trust.

Hi.

Cool.

Any last question?

Yep.

Have you fired anyone prior to being acquired by Twitter? Yes. We fired people at— I fired one person at both companies. And I fired one person at Box. No one quite yet at Twitter. It's been a good one. Poor performance is what it comes down to. It stems from all sorts of reasons. It's rarely the case, I mean, they clearly passed your interview. It's rarely the case that they're dumb or bad. It's that they're not motivated for some reason or they're not gelling with the team for some reason. And so in both cases, in pretty much all the cases, it stemmed from someone who we thought was a good cultural fit and they just ended up not being. Yeah. And so you have to make a correction. But you can't be afraid of that. Like, the second it doesn't work, you need to fire them. Yeah? Why did you move to Boston, and what are your take on the positives and negatives of the two kind of— Great question. Great question. So I moved to— I think we have a few more minutes. Is that right?

Cool.

Oh yeah, 2 more minutes. All right. I moved to Boston right after I joined Vox for sort of 2 reasons. One, my girlfriend had started at MIT, so I wanted to be out there. And 2, when we joined Box, we were a 6-person company. They were a 40-person company. And of course, it feels small now, but that was huge at the time for us. And I didn't want to be just doing engineering. I wanted to stay doing something entrepreneurial. And so I talked with Levi, and we came up with a plan that I would move to Boston and start an R&D office. And so we— then it was sort of like a mini startup within Box. So same pattern, find office space, recruit people. come up with a product direction. And so we ended up building a lot of their Box Sync stuff, their Dropbox competitor in Boston. And then in starting Crashlytics, I was there. I figured, hey, why not? Let's do this. And let's just do it here. And I think actually it turned out to be a huge advantage for us because it was radically easier to hire than I've heard friends have times with here. And we were very quickly able to establish a reputation. So So Boston has a pretty active startup scene. There's still events every night. There's hundreds of startups there. Kendall Square, Cambridge, where MIT is, is actually the densest square mile of startups in the world, mainly because they're all in that square mile. And that's a very cool ecosystem because you just go to the coffee shop or the bar or whatever, and like, you know a ton of people because it's so dense. And because of that, people quickly get to know who you are, quickly know— get to know what your company's doing.

Mm-hmm.

And so when it goes time to recruit someone, and they start telling a friend like, oh, I'm considering joining Crashlytics, their friends heard of us. And then we get sort of social reinforcement. And so that, I think, is what a lot of startups struggle with, is you go to recruit someone, not only has the candidate never heard of you, no one they know has ever heard of you. And so it's a big just social risk on their part to join that company. Whereas if some of their friends have at least heard the company's name, it becomes far easier.