June 6, 2018
Ep. #17, Security Research with The Morning Paper’s Adrian Colyer
In episode 17 of The Secure Developer, Guy meets up with Adrian Colyer, Venture Partner at Accel and author of The Morning Paper, a daily re...
I am Edith Harbaugh, I am CEO and co-founder of LaunchDarkly, and my talk tonight is about Buy vs. Build: Turning Critics into Champions.
But first, about LaunchDarkly. Everybody here at Heavybit really thinks that software powers the world, and I don't think anybody believes anymore that you can go through life without software affecting your everyday life. LaunchDarkly's thesis is that we empower all teams to deliver and control the software, and by all teams we mean we're very much developer-first and we focus on developer productivity, but then we also believe in the democratization of also allowing product managers, marketers, and even salespeople to control software and make sure it gets to the right person at the right time. I'm pretty proud that now we have 500 + customers, we have everyday names like Intuit, NBC and BMW using us. We're really everywhere that you think of as software, and we serve over 300 billion features a day. I'm very proud of all we've accomplished.
That said, where did it all start? About five years ago, my co-founder and I got into Heavybit. This is us literally holding the bits that we were given when we got into Heavybit and we were really excited. Not so much for the bits, but that we had a home. At that point we were two co-founders, two engineers and a bunch of people in beta. We were about to get kicked out of our co-working space at Yammer, so we were really happy when Heavybit accepted us because beyond that, we're just like "Where are we even going to sit? We've got nowhere to sit." This was a really early stage of the company. My background was I had been an engineer, I had been an engineering manager at Epicentric and I had a lot of patents on deployment and knew how to build stuff, I had gotten frustrated with building the wrong stuff and I had become a product manager.
I think every engineer thinks, "If only I was the product manager, everything would go perfect." Once you become the product manager you're like, "OK. I was really a jerk to my product manager."
Once you're a product manager, you realize there's the whole thing of building and then there's a whole other thing of building the right stuff. Then after being a product manager for years at Vignette, I then took this crazy step and I joined an eight person startup called PlantSense, and this was an internet-connected device where you measured plants. We launched at precisely perhaps the worst time to ever launch a thing like this, because we launched it 2008. If you're old enough to remember, we launched in November of 2008. Not only was it November when nobody in the Western Hemisphere was thinking about gardening at all, it was right after a global financial crash and everybody was worried about losing their house and not so much about the plants in the house.
From this I got really good at marketing. The first month we thought we were going to sell about 10,000 units, instead we sold twelve. Like not a rounding, literally twelve. What happened was my boss at the time said "Everything is terrible." And I said, "I think I can run some Google ads and try to dig us out of this." So I started selling, I got us up to 100 units and 1,000 units. The nice thing about starting from this point of rock bottom of selling twelve units a month is that anything you do is an improvement, it's not like you can sell less than that. I got really good at marketing and from that, I went on to join TripIt and I was a product director there and eventually I got really excited.
I decided to start a company with my co-founder John, and all along I never really thought of myself as a salesperson. I always thought of a sales person as this mythical thing, the fast talking slick person who has the pattern nailed, and that was not me. Unfortunately when you're in a four person startup and you're the CEO and founder, you do not have much of a choice. You become the salesperson, so the talk I am going to give tonight is about how I cracked sales at LaunchDarkly and how I turned a bunch of developers who really didn't want to buy our software at all into champions.
The first problem that every startup faces is that nobody knows you exist. I think everybody has this dream that they're going to come out of stealth and TechCrunch will write the article and their biggest problem will be that their servers crash because everybody came on at the same day. I think that happens to one out of 100,000 startups, to everybody else it's like you're like, "Here I am. I'm ready," and there's not even the sound of the cricket because the cricket is down the street looking at somebody else's startup. No one cares. Like really, nobody cares. You're a four person startup, nobody cares.
The good thing is, if anybody is talking to you about "Why should I use your product? I could build this in-house." It means they care just even a little bit. If they're like, "I understand your problem space. I built this in-house. I already have this, why do I need you?" That's awesome. They already understand what you're doing, and I'll say in the developer tool space, that's really hard to get. A lot of people, you try to explain what you do and they're like "I don't know."
So if you're talking to somebody and they're like, "I already have this. Five developers are working on that." That's a potential buyer, you have their attention, they understand you. There's something going on. Do not discount that person, give them a big hug and say "Thank you. Let's talk some more."
But first, a little breakdown of buy versus build. An example I like to give is roast chicken, and you might think that roast chicken is something that you always just go by.
Kirkland has made this industry a really cheap rotisserie chicken. If you go into any supermarket right by the checkout line they'll have this impulse buy, "Buy a chicken for $4 bucks." Everybody has seen this. It's like, "I could get my dinner for $4 bucks." It's like, "For $4 bucks I get a somewhat tasty dinner and it doesn't take much time."
However, there's a lot of reasons why people make roast chicken at home. You might want to have some friends over for dinner, and if you're having some friends over for dinner you want to say, "I spent three hours hand cutting these leaks and glazing the chicken and making this just so, and putting the right sauces and rubs that my great aunt taught me." There's a lot of customization and something that is very core to you and something you're proud of, and it just carries this very different weight from saying "I grabbed this thing for $4 bucks on the way home, you want to come over?" Not that there's anything wrong with that, if you just want to hang out with your friends, but there's just something very different about appealing to somebody's sense of like, "I want to cook a meal for you and this is something I've built in house."
All right, Zuni. How many people here have been to Zuni? Zuni is about a half mile from here, it is a San Francisco legend, and they have this roast chicken. It is amazing. It is not cheap, the last time I looked it cost about $40 dollars, I think it's gone up to $50 dollars. You sit down and you order it, and they put it in this wood fired oven just for you. Just for you with the special bread, and you sit and you hang out in this beautiful cafe, maybe you catch up with your friends, and it comes out. It is amazing. You've already committed an hour plus of your time, $50 or $60 dollars plus tax and tip, but this chicken is really worth it. Let's just compare these two. If you said, "Let's go to this cafe and get a $4 dollar roast chicken that I brought with me," that's not going to work.
There's a lot of different places where you can appeal to different parts of people's psychology.
If you want to impress somebody, you take them [Zuni]. If you just want to be totally casual, Costco is fine, and if you want to build something from scratch that's a different commitment. Always think about the psychology about why people buy versus build.
All right, zoom back to LaunchDarkly. We do feature management and basically what we do is we allow people to ship features on and off, and then we allow them to manage them. Before we came along this was something that was not on the market at all. If people used this, it was 100 % a homegrown system. The number one problem we faced was that the traditional means of marketing, of trying to buy Google ads or looking for search terms, just didn't work. It wasn't a solution that people were looking for because it wasn't a problem that they thought they had. I was talking to my friend Max the other day who is ex-Roku, and we sat next to each other upstairs at Heavybit three years ago, and he said "I always thought you guys were just not going to ever make it because everybody just built this in-house." Our number one problem was awareness.
I'm a big Monty Python fan, so the number one thing about awareness is just like letting people know you exist at all. The question I asked my advisors back then over and over again was like, "How do I make this work? What's the silver bullet? Just tell me what to do." I would get really frustrated because they're like, "You've got to figure it out." I would sit in advisor sessions like, "Your company is really successful. How did you make it work?" They're like, "I tried a lot of different things."
So I'm going to run through the stuff that we worked through, and this is not meant to say that these are the things that will work for you, these are just examples of "Here's all the stuff that we tried." The number one thing that didn't really work at all was we tried to get press, and we got one TechCrunch article that covered us but beyond that, nothing. I was a good writer, so I started writing blog articles. I had a whole series called Secret to Facebook's Hacker Engineering Culture , Secret to LinkedIn's Hacker Engineering Culture. What I was trying to do is think of something provocative, so I would find a friend that worked at one of these companies and whatever they would tell me that was under NDA or commonly knowable I would write a blog post about. You could be as smart as Facebook, you could be as smart as LinkedIn, you could be a smart as Netflix, you could be as smart as Google. I would write these and I would post them on our blog, and I would post them everywhere I could find.
"Show Hacker News." This was painful. This was fun for me to put together this talk, because I was literally finding the original stuff that we posted. We went on Show Hacker News, you can see this is still pretty early. We got, in my mind at the time, ripped apart. I am totally happy, we're a year into business and we have something, and then we just got "Why don't you have this? Why don't you have this?" I felt like hiding under my desk, but the desk could stand up so it was hard to hide.
"Articles," I would write thought-leader pieces about continuous delivery. This is an article I wrote for Read Write about continuous delivery. It was the most popular article I ever wrote, and it was called Kill Your Staging Server. It was just sticking about how I thought staging servers were really archaic and people needed to move on. It was a little provocative, but it got pretty good pickup. I knew that this was semi-successful when Jesse Robbins, who was one of the partners at Heavybit, wrote me and he was like "You're not really right about that article." I was like, "Yes."
People noticed and I started doing a podcast, the original story of the podcast was funny. Originally Heavybit wanted me to do one with my co-founder or engineer s about life at a startup, like a Silicon Valley reality podcast where every week they would check in with us and hear the drama and the day by day stuff. I asked my co-founder and our two engineers if they wanted to do it, sitting down at lunch somewhere like there, and they give me a firm "No." I said, "This would be really good for the business. You don't have to do anything, you just have to go in the room and talk to me." And they said, "We don't really feel comfortable being part of a podcast."
So I waited another week and I said, "How about this? It would really help the company." And they said, "We told you 'No' last week." What happened was I was good friends with a guy named Paul Biggar, the founder of CircleCI, and I asked him. He was like, "Yeah, sure. I just have to talk? I could talk." So we started doing a podcast and we've done over 50 episodes, and I think the podcast was really good because it was a really low stress way for us to talk.
It was at a time when there wasn't that much technical content out there, so I was really surprised by how many people started listening to it.
When I say "So many people," I would honestly be surprised if there's ever more than 100,000 people who've ever listened to it, but it was this niche of continuous delivery so it got a very passionate audience. It was also something I cared a lot about, so Paul and I would talk about something and we would have a lot of interesting ideas and I would turn it back into a blog post or he would turn it back into a blog post. This was a really effective way for us to get the word out.
It was also really good because one of the other really good ways to get the word out is talks, so this is advice I got from Craig who's one of the Heavybit advisors, he's like "Just put your talk in anywhere that will even think about it." The issue is, nobody wants to take an unknown speaker, so the podcast gave us a lot of legitimacy. Because I could say, "I have a podcast." It doesn't really matter that not too many people listen to it, but at least they had a feeling that I wasn't a complete stranger. This is me speaking at NDC Sydney based on the podcast, and that went really great and we got a couple of customers from it.
Things we tried were Product Hunt. I had so much hope about Product Hunt, we poured a week of work into this huge launch, we were number eight for a day and we got exactly one customer from it. This was another really brutal slap in the face about awareness in the early stages. The one customer we got was somebody who is a product director at Invision, and he said "This looks really cool. We've built an internal system, we're not sure if we can keep maintaining it. Will you talk to us?"
Of course, we said "Yes." They had built this really involved internal system and they were getting a little tired of it, so we spent a lot of time with them. I think they are our twelfth customer and now they've been an incredibly good customer because they tweet about us, they blog about us, they're happy. It was all from one Product Hunt lunch.
Reddit, people write off Reddit but it was actually good for us just for general awareness, and Quora. Here's me answering a question about feature flags. The gist of this is that if you're sitting here as a developer thinking, "Oh my gosh all I have to do is hit number one on Show Hacker News, then my life is over." It's not that easy. It was like this continued ground work of everywhere we could get our name out, we got it out. It wasn't just like, "Let's crack Reddit and then life is good." Or, "Let's crack Quora and then life is good." It's that we need this continual drumbeat of getting the word out to even get people in the door. At one point we actually, as part of our weekly sprints, had an assignment that everybody in the company had to write a blog article. That was just part of your work for the week.
Other advice I got from Craig, who again is brilliant, is just write about anything. At one point everybody knew who joined, we made them write an article about their first week. At the time there just wasn't much content out there, so these would actually SEO really well. We would try to stuff them with a lot of good words like "Feature flags," "To do it delivery," and they were actually really popular.
The one take away from this section on awareness, please, it is really hard work. It's not just one thing, it's a series of continued banging your head against a wall and then you get there.
So, this is all the talks I did on basically the first year of the conference. I actually-- Sorry, the first year of the company. I actually pulled this from our series A deck. These are all talks that literally I gave, and at the time I just literally made a list of all the conferences I wanted to go to, and this was also painful because I kept looking for the master list. I would ask the other Heavybit companies "What are the conferences I should go to?"
Eventually I realized there was no such list, it's really unique for every company, so I made a list of every conference I wanted to go to and I wrote up an abstract. I just sat and I sat with all the forms, and I applied to about 30 conferences every quarter. This was really humbling, because at the time I think I got into about two out of 30 per quarter. I went wherever they accepted me, I would go there. This was good because every conference you go to, you get another little layer of respectability. Like, "You spoke there? OK. You spoke there? OK." I'm not going to name which one, but one of these I went and four people showed up. I was like, "I get to practice my speaking."
We did a partnership with Microsoft Build, which was amazing. If Microsoft ever approaches you, just do it. From all this awareness building, what do we get a lot of feedback? "I could build that at two hours, it's booleans." We've got a ton of comments every time we posted on Reddit or Quora or Hacker News of like, "Why doesn't it have this feature I want? What I really wanted was the ability to show a temporary versus a permanent flag."
This was great, so do read the comments. Every time he posts, we posted-- We would read what people wanted and it was actually really good feedback. So he said, "OK. Here people are saying this from a place where they want to use this and they can't." We started trying to get parity with homegrown, like people would say "My homegrown system already has this. We have a way to look at what users have, what features, and this doesn't have it." We're like, "Thanks. Let's go build that." Then we started to really build the hard features, the things where people were like "We have this feature flagging system in-house and it doesn't do this," so we built real time updates and custom role based access. Then we did something that seemed crazy to a lot of people but was, I think, smart. We published the blueprint. We literally published the blueprint of how to build a feature flagging system, and I'll tell you why we did this.
I got an engineering degree from Harvey Mudd College, one of my projects when I was at Harvey Mudd College was they literally gave us a blueprint of a hammer. They gave us a blueprint of a hammer with "It has to be within these certain tolerances for the head and the handle, and that's your passing grade. Like, "Does your hammer meet these specs?"
Then they gave you a hunk of wood, some metal, and some plastic. They said, "Go down to the machine shop and do this." It took me about 80 + hours to make a hammer. Because if you're machining it and you go a little bit too small, you can't re-buff the wood out. If you're machining metal, it's fine and then always the issue would be you would have to heat treat it and metal shrinks when its heat-treated. So you have it just within tolerance and then it shrinks too much. This is not my hammer, this is my friend's hammer. After I finished that class I threw away my hammer because I was just like, "I never want to build a hammer again."
The point of the story is a good engineer realizes that they can build something, but they don't want to build that. So if you're selling a developer, you always want to convince them you absolutely could build this, but you can't, because you have better things to do. The reason why we published our blueprint was because we wanted to show people, "This is actually a lot more complicated than you think it is." At the time people had this perception that feature flags were just a database flipper. We were like, "No. It's actually a lot more." "Is it real time? Does it have audit logging? Can you trigger something within microseconds? Can you scale up to billions of feature flags per second?" What we were really trying to do is say "This is a lot harder than you thought." Again because we really wanted to say, "You could do this, but you don't want to."
Right, "Anti-tactics," things that absolutely do not work. I touched on this before but never tell a developer they're not smart enough to build something. If you tell somebody-- My co-founder has a PhD, which by the way he does, and "You can't build this." That doesn't work as a sales tactic. I think there's a school of thought that you could nag your customer, but I have never successfully done that. What we always wanted to say is "You could build this," your "Stupid buyer of software" is not a sell that worked. The religious conversion also absolutely did not work. We were in this unique situation that you had to buy into feature flagging as a whole, so if we were trying to get people who said "Feature flagging is dumb, I'm never going to use that. I'm bored." It just didn't work.
The advice I got from Javier, who is one of the Heavybit advisors when we were here, is "You want to find the converted and sell them Bibles." Find the people who already believe in feature flagging and make them successful. Another anti-tactic was if people had a working system, to try to convince them. I say all these because we tried them. One of my really good friends was at this company called Flight and they had a working system, and I would talk to him every two weeks, "Why don't you switch over?" He's like, "You don't have all these features we have." And I'd be like, "But why didn't you switch over?" Eventually I realized that if somebody has a better system, they're not going to switch.
These are all anti-tactics for going into a buy versus build situation. If you ever hear these words start to come out of your mouth, follow the advice from Monty Python and just back away from the situation.
If you're ever in a sales cycle and you hear yourself saying, "My system is almost as good, why don't you switch?" Don't and realize what you're doing. Or if you're ever in a sales situation and realize that you're lecturing or condescending to the customer, don't. You're not going to win it, and even worse they're going to have a sour taste about you and the company. This is really strong medicine for somebody in the dev tool world because we all like to think we're smarter than be else, but we're all smart about a different area. Do not lecture customers.
Which all goes back to developers have a ton of pride. You'll notice a string of Monty Python memes , I hope I'm not breaking copyright laws. This is basically somebody whose arms have been cut off and he's still too proud to give up. He's like, "Come back, I'll bite you." Don't fight with your customers. It should be a harmonious thing. So what actually works? I've said all the things that don't work when you're in the sales cycle, what actually really worked for us?
Listen to what your customers are saying for objections, and the number one thing is actually start to build them in as features. I already talked about all features that we built, the second is if you hear an objection over and over and over again, come up with content. If you hear this objection over and over and over again, it means it's a persistent thing that's not going away.
A thing that we always heard at LaunchDarkly was "Will this scale?" People were worried that because we're a critical part of their infrastructure, they're like "What happens if we have a ton of requests?" We started putting together webinars and blog articles that directly addressed this head-on. We stopped trying to say, "Just trust us." So we said, "Worried about scalability? This is a webinar, we just did scaling to 200 billion feature flags daily." We're actually at 300 now, but even in the early days once we hit about a billion we would brag about that. Whatever one person is saying, there's probably a ton of objections out there.
What you want to do is package up their objection and make a tidy little bundle so that you can forward it to them, so they can forward it to everybody else in their company. Because if one person at the company has an objection, it's probably the mouthpiece of about 10 other people behind them who also have that objection.
Technical debt, this was a huge slam against LaunchDarkly. I would look at what came up when you Googled "Feature flags," and it would be a bunch of articles like "Feature flags are the worst technical debt," "Technical debt is added by feature flags." Everything had to do with technical debt, and I said "Great. How can I turn this into an advantage?"
What I came up with is that feature flags managed poorly are the worst technical debt, so when I looked and read about all the objections they weren't really that feature flagging was bad. It was just that the people were using this technique poorly, so people would in particular point out this example of Knight Capital which lost about almost a billion dollars in 30 minutes from a poorly implemented feature flag. There was this tear down about why feature flags had caused this issue, and that was one of the main articles that came up. I went through the article and I rewrote it as "This is why this happened, because they had a bad system. Feature flags are great, it's that they had mis-implemented it. It's like saying electricity is bad, electricity is bad if you don't manage it."
Anytime you start hearing a repeated objection from customers, listen to them and listen to why they're saying that, then try to turn it into a positive.
The final thing we did about buy versus build is we heard over and over again, "Why should I buy versus build?" Again, it goes back to if one person is asking this it's probably because a lot of people at their company are asking them that too. We made explicit landing pages about buy versus build, like steps you would have to do to build your own system. Things to think about again, just publishing explicitly the blueprint. We didn't try to hide or do smoke and mirrors what it took to build it, we just said "Here's all the things you could think about." This has been one of our best pieces of content, it gets forwarded around a lot.
I know that some people have said, "We read that article and we went and built our own." My answer has been like, "Great. Now you have converted. At some point you will get really tired of maintaining your own system and you will come back to us." We just had a customer who signed up with us a year ago-- Actually, sorry. 18 months ago, canceled about a year in because they said "We don't think this is worth the value, we're just going to go build it yourself." We said, "Great. Here's the blueprint." They just came back and they are paying us 10x what they originally were paying. Because they said, "We actually realized if we cancelled that we actually really needed you a lot more than we needed, and when we spent six months of developer time trying to build it using your blueprint we realized how deep in trouble we were. Not only did we not have the system we needed, we were burning developer hours."
So if you're a developer tool, it's really tempting to be like "This is too hard for you to build." Don't, just be upfront with your customers. "Absolutely, you could build this. Don't." I'm old enough that I remember our engineering, when I was in engineering our QA manager wrote our issue tracking system out of Lotus Notes. Now if somebody said, "This is my pet project for the next year," everybody would be like "What? Why?"
Your goal as a dev tool is to get people to think of you in that same space as "Why would you build that? That's insane."
From all this what started to happen was we got this base of really happy customers, so this is actually a quote from TrueCar, which has been a longtime customer. What happened when we started a post on Hacker News, we didn't have to post anything more, our customers would post. So this is actually, I love this guy's name, it's this guy named Joshua Goh, who's a developer manager at TrueCar. He's like, "Our job is to build the best car buying site. Our job is not to build infrastructure. If feature management isn't your core business, don't build it yourself."
These are some more resources, as I said before I do a podcast with Paul Biggar on continuous delivery. A question I get a lot of is "How do you get your first 10 customers?" So I wrote that into a blog post. I hope the takeaways everybody has is that developer tools can be incredibly rewarding, your customers who are your biggest critics are usually that because they care a lot. So if somebody is taking the time to critique it, don't lash out and say "They don't understand." Listen to what they're saying and you'll come up with a better product, and perhaps a real champion. With that, thank you.
Yes. The question is re-pricing, and my theory at least in the early days was I didn't want to lock people in. For the first 10, I honestly just ask for a token $20 or $100 bucks ever, because we were incredibly risky to put in their infrastructure so I just wanted to prove value and I didn't want to lock them into a forever price.
After that we got more sophisticated about what we thought value should be, but at the beginning we really just cared about feedback. Our libraries are open source, so we have about 18 client server libraries in the popular SDK case. Our core is closed, and quite honestly it was because that was my co-founder and I's background. We didn't think we were smart enough to crack the code of open source and become a profitable company, so we went basically with what we knew. All the libraries are how you connect to us, so there was a lot of value in that.
The library is basically that we have a library for Java, Python, Go, Ruby, and that's how you connect to our core service. We saw a lot of value in those being open, so that people could see how to connect with us and also contribute back. At the time, my co-founder was really annoyed at me. He's like, "That's way too provocative." We actually still have a staging server, and I'm like, "No. Our whole point is we should get to a point where we don't need one." I don't really have the right answer for that one, about the border of provocative versus obnoxious, except for it's good to have somebody take a second look at it and be like, "Is this too edgy or not?" It was a topic I cared a lot about so I had a lot of really good examples, it wasn't just provocative for provocative's point, if that make sense.
Again, I don't mean to be too flippant. Like I said, the Kill Your Staging Server was definitely provocative. I think as long as you come from a place with justification and some rationale, people will engage. Putting together this talk, I actually found all the original pieces on Reddit and Quora, and at the time I remember a lot of the comments really stung. Now looking back with the distance of 4 years, I could see that they are really somebody who actually really wanted to use our system but just had stuff that we didn't do yet. In particular when I look at Reddit and Hacker News, people are like "Have you thought about prerequisite flags?" At the time I was like, "How dare you bring up prerequisite flags." Now I'm like, "Yeah. Actually we really need prerequisite flags to be useful."
A lot of what we tried to do was package up pieces of content so they could forward them around the org. We realized that if somebody kept asking-- Here's a good one, "What's your SOC security story?" It meant that somebody else was asking them that, so we got our SOC security clearance and then we just had a nice little thing that we could be like, "Here it is." The key is to have easily digestible things that you could just put in an email and you could send to somebody else, or a landing page that you could be like, "OK. This is solved, this is solved." The big thing about a year ago is GDPR compliance, so we just said "OK. Here's our GDPR compliance page. Done." If you find yourself writing the same reply over and over and over, make it a landing page so that you can just forward the link. Then there's also all the people who don't even bother writing and just assume you don't have it that then will probably find another room.
It was just a constant grind. I wish-- This was my thing at the time because I'm an engineer, I was like "Why are we working so hard? Can't I just do the 80 % that's going to work instead of all this work?" It was just a series of things, I remember how much work we put into Product Hunt and I mentioned this another time. Somebody was like, "I saw your Product Hunt. It just took me a while to get my org on board, we came eight months later so you actually got two users from that." But in the early days, it's just a constant grind of getting the word out. Unless somebody has a better answer, at which point please share it.
That's almost worthy of its own talk. I probably should give that separate talk. Originally we thought we were going to be self-serve, we had this nice thing where you could come with a credit card and buy, and our first real legitimate customer who was not affiliated with us-- I took Jason Lemkin's word of "Affiliated." They really wanted to sign an enterprise contract, and I kept telling them "Please go sign up on the web page. Please go sign up on the web page." They're like, "No. That's not how we buy. We need an MSA." I just had this epiphany because I've been at enterprise companies before." I was like, "OK. We need to become an enterprise sales motion." But it was just that our customers pulled us that way.
In the early days we were probably I'd say literally 100 % in bound, we tried out bounding a couple times and it flopped. In hindsight, because we do outbounding now, it was we just didn't have the machine, the flywheel and collateral around it. To do outbounding effectively you need to have somebody who will write back within 10 minutes if somebody writes in, you need to have collateral, you need to have customer names you could drop as a reference. We just didn't have that. I remember even a friend was like "What other info can you send me? I want to forward you to somebody else." I was like, "I don't have any other info. I just have-- Just go create an account." Which was not effective at all, so I think to do effective outbounding you need to have stuff. And by "Stuff," I don't mean a working product, I mean "Stuff" like web pages that explain how it works, things that make people feel good about your security, things that make people feel good about your stability.
Let me break down that question. I think I had this good background where I'd been at TripIt and then PlantSense company and I'd seen marketing at both of them, so I had this arsenal of different tactics. What had worked extremely well at TripIt did not work at all at LaunchDarkly and vice versa.
TripIt, if you've ever seen it is this pretty viral mobile app. The press loves it because they travel all the time, we've got all this press without trying at all. People love to travel and they would blog about it, and people would share about their friends. You look at a developer tool company, it is not viral unless you're GitHub. I would always get this question, "Can you make it viral?" I was like, "No. We're infrastructure, nobody wants to share their password to that." It was not interesting at all to the press, people were like "I don't even understand what you're doing at all." However, we had these strengths that TripIt did not have. When I was at TripIt we tried to do content and it failed dismally. People have been writing about travel since Marco Polo, every newspaper column has a travel section, people like blogging about their holiday. There is a ton of travel content out there, so for us to try to compete for any travel keywords did not work at all. For a developer, there's not much good content out there. We found that stuff that we would just write would get a pretty good pickup, and I'm not talking about 5 million hit pickup but pickup amongst the right people who'd be like, "This is interesting" and it would start to get shared.
My advice to backward answer, data is there is no right channel. There is just the right channel for you. Again, Google and Facebook ads worked brilliantly when I was at a plant company because it was just like "You want this thing? Doodad for your garden?" Buy it, click, buy. When it's something that is deep core in your infrastructure, and you have to go through a security review, that's not something that's going to perform very well off of a Facebook click. Just think very carefully about, "Do I understand this channel? Could I try it? Let's not write it off until I understand it."
It was pretty simple. When we were trying to name the company, we looked up Canary .io and there was a burglar alarm company that had launched six weeks before that. We were like, "We can't win the battle for Canary.io." Because we looked at being a Canary company, and there's just too much already around there around burglar alarms who were taking that up as their keyword.
Five second advice: if you're thinking about naming your company, Google it and see what comes up. You'd be really surprised how you could build yourself in a deep hole where nobody knows who you are if you pick the wrong name. Then the counter example I always hear is "Apple is Apple," and it's like, "They've been around for 50 years. They have the Beatles. Are you the Beatles? No."
That's a great question. I could have talked more about that one. For us, we never talked about our product. We never did a demo, I put together talks on things you should think about when you're feature flagging and how you could feature flag badly, why feature flagging is good, best ways to do Dark deploys. I never would dream of showing our dashboard or even talking about us, it was always about the field. Those were the ones that people accepted, and after that if somebody said "Can you show me your actual product?" I would be happy to do that, but I took it as a point of pride of "These are vendor neutral talks." That really helped when people saw that I was serious about it, and sometimes they would actually be shocked, they're like "We expected a demo."
But also it really helps to have a thick skin. Like I said, in the early days I think I got one out of 20 talks accepted and it really helped to just have "This is a process" type of-- "I'm just going to dedicate a half afternoon to just applying." To have a "Here's my abstract, here's my title," and I'm just going to sit and apply to a bunch and then see what comes back, rather than be like "Oh my gosh, if only I get into like O'Reilly SRE con my life is made." Even after you get into one, it's steady at least for a slow burn of conferences.
I feel like fundraising could be its own talk, which I will happily come back to Heavybit if they'll have me. For us, it was really revenue. I have this theory that every company gets funded on team, dream, and traction. You have this tripod of if you're the X founder of a really important company, you could just turn around and raise $10 million. We were taught that if you have a crazy traction where you went from like $10 dollars to $1 million dollars in ten days, people give you money. That's the secret app, and then there was a dream of your market.
I think every round there is some combination of the three, and I actually wrote a blog post which is not up there about how we raised our series A, it's on my Medium account if you want to look at it. I'm happy to talk more, it's just a really long topic of fundraising. Thank you.