June 14, 2016
Beta Testing for Early Developer Teams
UX designer and former Treasure Data product manager Luca Candela discusses defining your feature tests, cohorts and research experiments. H...
All right. Here's the fast background.
So, I started off as a firefighter. I moved to Amazon actually as a day job to support myself while I was testing for the Seattle Fire Department. And I had turned Amazon into a fire department so that I could improve my career. I did not plan on staying in the tech industry past around 2002.
I ended up staying at Amazon through 2006, title of "Master of Disaster." I owned website availability for every property that bore the Amazon name, which means that, in the precursor to PagerDuty, I had 167 pages in one day. So I understand ops pretty deeply.
When I had left Amazon, I had learned what actually Artur Bergman and I ended up calling "the dark arts of operations" — the thing that in the developer community and the things that we look at as people that are building companies that serve developers. It's a thing that you should all care about very deeply.
And when I went to leave Amazon they told me that I couldn't ever talk about any of the things that I had built or done, or learned, or created, and so I ended up solving that problem by creating a conference, along with a couple of other folks, including Artur, who is in this room.
What we used Velocity for was basically a way of spreading the secrets that we all learn over the years of building and running large scale infrastructure.
telling you all this so you know why you should listen to me, and also,
more importantly, why some of the lessons I'm about to share are important
and expensive if you haven't learned them before.
So, I know a lot about how conferences work because
I created one purely to
serve a sort of abused group of people's need for a community. It has gotten quite
big. Velocity now has a couple thousand people every year.
Along the way, I realized that culture and tools, the things that we use for web operations, all the big companies had built their own internal toolsets. That's really relevant to every company that's in the Heavybit program, which is, we build tools that work like the things that large companies seem to have had. GitHub being a great example of an actual functioning hosted source control repository, Heroku being a platform as a service. Then in many cases these big companies sort of hold back the tools that they have as internal proprietary " secret sauce."
One of the things that's common across every company in the program is that we're often building services that replicate, or greatly enhance, big enterprise services that only large companies can have, and without which they are sort of left where this little kid is, which is poorly prepared for the world that they need to operate in. That was especially true in 2008 and 2009 as we started teaching people these large scale web concepts.
And one of the biggest things that was missing at the time, although it's weird to think about it in a modern context, is the automation tools. At the time there was CF Engine, there was Puppet, and those weren't really quite right for the types of systems that we knew we would start building, the type of systems that you guys are all building, too, now.
So a team of us founded a company called Chef. Chef has since turned out to be quite successful, so there's now 30,000+ users, thousands of contributors to the open source projects, and it's very commercially successful. So there's Hosted Chef and Private Chef an on-prem edition. We reach over a billion people certainly every month. So, Facebook is a customer, which certainly helps lift that up. But most of the major technology providers and sort of next generation companies are building with and around Chef.
More importantly, there's a foundation that all of you need to be building on, which assumes that people are able to do things like actually deploy and manage and configure servers and systems, have those work in the Cloud, be able to migrate across a lot of different properties.
So, the point of this is that the environment shifted very quickly, both around open source, Cloud computing, data center level APIs, hosted services, all of which was crazy when we started only a few years ago, and has now become so commonplace that there can be an incubator that serves people like us. So Chef absolutely would have been a member of the program had we existed at that point. I just wanted to provide that reference.
I left Chef full time at the end of January. I joined DFJ, which is a big VC, as an EIR. I'm also an investor in Fastly and an advisor to Fastly, PagerDuty, Message Bus and Instacart. And I recently joined as part of the early group of advisers. So I am here for you guys if there are questions you have about our history or anything else.
What I wanted to do today, because I see so many companies in a variety of different roles, both as a conference organizer and across all the companies that we see at Chef, and in my roles at DFJ, I wanted to share the expensive, crappy lessons that I have learned through really ridiculous mistakes, and that I see almost every other company make, who is like us, who is trying to serve people that are not consumer applications, who don't follow consumer rules.
In general, those expenses come either at the expense of millions of dollars, which you waste of VC money, which translates to dilution, epic failure, which results in you all going home and being sad, or mostly just wasted time doing stupid things over and over again. These are pretty universal, so I distilled down the ones that I'm actually tired of having to say when I'm working with an advisory company.
My goal is that I'm going to tell you what the pattern is, I'm going to walk you through what it looks like. Hopefully it will resonate to some degree with some of you. If you find yourself reacting like, "Oh God, we're totally different than that," I promise you that every organization that I've worked through has gone through a similar awareness. So please come back and talk to me and maybe I can help map it out to your organization.
The first thing I want to introduce, though, is an idea of "stage appropriateness." You guys ever heard this? Raise hands? Show... this phrase? This is a magic phrase which will help you understand where you are in a process. So every one of us goes through seed funding. We build first projects, blah, blah, blah, on and on until we become huge successes and we have massive exits like Heroku, or IPOs like Splunk.
And the advice that people give people like us, particularly in the early days, and particularly if they're more successful, is often stage inappropriate. It's a terrible match for things that you need to do. So you'll get advice like, "You need to hire the senior most sales person from some huge organization," which has nothing to do with a 5- person startup, or a 10-person startup, trying to do CI and just reach out to a first couple of developers.
So just recognize that this is stage appropriate advice. If you talked to me and you were farther down the chain, I may give you vastly different advice. Stage equals early, c ustomer and market equal business to business (B2B).
The first thing that I'm going to say, the zero point — and I've noticed this — most of you that I see in the program have very little day to day awareness of how unique a resource Heavybit is. I'm not going to dwell on this too long, and I don't mean it as a kiss ass thing for James or any of the other Heavybit guys. This scares me, and it should scare you. Replicating an environment like this is very hard, it's very expensive. And when you graduate and move on from this program, having the resources that are available to you here will take more time and energy than you probably realize.
I say it so that as you look forward when you're hiring people, when you're building — this has been an issue for both Greg and I, our current company is not a great match for Heavybit because we're consumer focused — we don't want to leave. We don't want to actually move our consumer focused dev team out of the building, in part because I know how much frigging work it's going to be.
So, I just want you to think about that, that where you are today and the set of resources that are available, like, I've never seen anything quite like it. Most people have not. And if you haven't done this before you probably have no idea of the set of shortcuts that you get to take as a result of it. But I just want you to appreciate it and begin to plan for, hey, like if having a meal every day is important, you're going to have to start budgeting for that, as opposed to just being able to take advantage of it as part of the program.
So just realize that it's pretty awesome. Make sure you say thank you, and know that pretty soon it's going to feel like a loss when you have to move out. So enough of that point.
All right. First most expensive mistake. Real one. You think that business to developer is somehow not the same as business to business.
Basically, how many of us emotionally think of ourselves as being enterprise companies? Raise your hands. Okay. I love you all so much, and I remember that time, and I still feel that way.
So the reality is, is that we are all going to make products that people at a company are going to pay for, and they're going to use it in the context of their company. Right? Like, Heroku's customers, while they're awesome design forward developers, are developers typically at companies who are going to pay with a credit card, and eventually they're going to outgrow that. Chef, same thing. I'm selling to my people, and my business plan assumed that eventually they would pay with a credit card.
You are going to be an enterprise company, and the simplest way of thinking about that is, if you are disrupting an enterprise thing you will become that enterprise thing.
And not realizing this is actually the most expensive mistake that I have made in my arc at Chef, and it's the same thing that we see across all of the companies. It gets more expensive the longer you wait to start thinking about the ramifications of it. I actually tease Artur a lot because he is a one man singing, dancing sales machine/product engineer/customer engineer support person/community manager and band leader. It doesn't really scale well because there's only 24 hours in a day, and most of it, he should probably be building a company or doing other stuff.
So what's common between him and me and PagerDuty, and
basically every other company that we see, is that none of us want to be that
shitty enterprise organization that we certainly didn't want to work for
anymore and have probably created products to screw with.
Just realize that this is your future if you're successful. So you get to make it suck less, but you're going to have to deal with it no matter what, if you want to build a business that scales and stands alone, rather than being acquired early, because what you built was cute. And you're either acquired for talent, or you are acquired to make an ugly, dumb enterprise company sexy and neat and fun. Not that any of the ones that we've worked with or who are crucial partners of any of these organizations would be anything other than beautiful and amazing and special. I'm not talking about them. I'm talking about some other one.
Who knows what this is? Raise your hands. Awesome. I did not know what this is. So this is Crossing the Chasm in which Jeffrey Moore describes the customer adoption life cycle for essentially every technology company. There are predictable stages.
So there are innovators for whom your product not working is a feature, because they get to help you make it better. Then there's these early adopters who kind of look like that, but maybe they want to pay. Then there's this magical giant gap that will kill you if you don't anticipate it, which is the difference between what a customer needs who is an early adopter and then an early majority customer.
A great example of this is going back to any company that's building around Open Source . Having people who want to join your project and commit code to a project early on and extend features even for a product they're paying for is not something that every company forever is going to want to do.
But it's really hard when you're in the moment, and particularly when you're talking to VCs, and you're getting great early press, and you've got all these people that are telling you they love you and they love everything about your product.
It is impossible to really feel what it's going to be like when someone is like, "Dude, your documentation sucks." This was a thing that actually made me so angry I threw something once.
"Chef documentation sucks." "Like, documentation is a wiki. Why don't you improve it?" "No, you guys have a crappy product. You should improve your documentation."
It goes on and on and on. And the first time it happens it is so stunning because you're like,
"No, we're a community. We're all working together. It's for developers. I'm a dev, you're a dev. We're making this thing better. " And they're like, "No, man. You're a vendor."
That happens at the chasm.
And that is what gets you is this moment where you shift from thinking about your company as being something that's primarily serving you, people like you, your tribe, our tribe, to serving people who pay for a product and want it to work like anything else that they buy.
I have had arguments early on whether we were a vendor or whether we were a community that had a commercial interest or whatever, and I was wrong every time. There are people in this life cycle — and for the most part, for the first couple of years, none of you will worry about anything other than the early majority at max — but the reality is that it is a continuum of changes.
if you haven't read that book, read it. You'll spend, again, the first
little bit of it going, "Ah, it's not me. We're different because it's the
Cloud." You have all these little stories that you like to tell yourself,
and they're all just frickin' lies.
The truth is that it's scary and hard, and you are going to be serving a customer whose profile changes over time, their needs change over time, and your product has to shift, the way that you deliver it, the way that you talk about it, the key features that you have.
At one point when you declare that you had a real release, that's going to mean one set of things to one people and another set of things to another, who immediately want to be on the beta. Customer expectations shift and mature over time in ways that are very frustrating, particularly when you scratched your own itch, which seems to be most of the people in the program today.
The corollary of this is that developer adoption will magically turn into money. Now, first of all, it will magically turn into money in the form of venture capital dollars. So if you make a thing that developers like, the VCs have become educated enough to realize that there is business there, although they will never tell you this. What they mean is enterprise business there.
But they will be, like, "Oh, yeah. It's totally awesome. We see this big future. Everything is going to be bottom up, and it's going to be awesome." So you can absolutely turn it into VC money, which is totally different than customer money.
In the Chef original business plan there's a section, and it describes our Go-To-Market, which is we're going to offer a credit card sign up and we're going to charge for the hosted service only. Then when we figure out the enterprise, when the enterprise customers start pulling on us, we'll figure it out, and then we'll just back the truck of money up. That is actually the plan.
It was pretty cool, but it is essentially the equivalent of the underwear pants. And we're talking about 2008. If you talked to Adam Jacob, who is one of the other co founders of Chef, he has another funny way of talking about this.
But this is how we all think about it, and the truth is that it's actually okay to say, "We'll get developers to use our product. We'll get people to adopt it. We'll get people getting excited, and we'll turn it into money." But, eventually you're going to have to have a plan.
The corollary, and this is mistake number four, is person with credit card at big company is our customer, and so we won't have to deal with procurement. You're wrong. You are simply wrong, and I will explain it as follows. Actually, I'll come back around to it in one second.
But this is a huge fallacy, and it makes it worse when we meet companies like Stripe and we're, like, "Awesome. We're going to use Stripe. It's going to make developer payments really easy. Everything is going to be super great, and Jesse is totally full of shit right now because we are different." It may actually be true, but the other part of this,
How many people want that to be true? Like, that's actually true, right? Okay. How many people know that it won't be? Everybody put your hands up. It won't be true.
It's only true if the average customer value is under $100 per month or under $500 per year for the entire organization. So if you're, like, "And we're going to get a bunch of money out of a big company," eventually what's going to happen is you're going to run into a situation where you look like every single other procurement process that everyone else goes through.
Every company I've ever worked for, including Chef, eventually has a person whose job it is to yell at me for buying things and not having it part of the expensive report. That includes being the CEO. The only company I know that's different than that is Fastly, in which Artur just buys what he wants and then yells at other people for doing that.
So sometimes you can get away with it if you remain the technical founder-CEO. But, otherwise, at every organization that you work for, they're going to have a process for buying things, and if it's over about $100 a month or about $500 per year, it will be above the threshold that that accounting person comes and bugs you. Congratulations. You are now an enterprise company.
One of the companies that I talked to about this who really has a super compelling product is PagerDuty. They got away with this for much longer than almost any other company has that I know, and it's because the product they have is so critical, there's no alternative to it.
The customer values have been growing over time, but they still have to deal with, essentially, the procurement department popping up and being, like, "Hey, what's this? When can we get our discount? We should get a volume discount." We'll come back around to this in a second.
I have learned that you can get a master's degree, and in fact a PhD, in procurement. That should terrify you. That means that someone has spent years of their life learning how to procure goods and services, and consider themselves to be expert and master of the craft.
Which means that in every organization that you deal with there is a fundamental misalignment of incentives that you are going to have to deal with.
And I point out that this cop is probably really enjoying his job, and probably the protester was right before this point. But when you deal with large organizations and you're trying to get them to use your stuff, there are a slew of people who will want to get away of even the most useful, powerful, game changing, critical technology that makes businesses work, and they will do that at the direct detriment of the business at times.
That includes the IT department who is blocking Reddit so that they can
improve productivity while browsing Reddit all day long.
There's the new dev, who proved that MongoDB is web scale on his laptop, and so he doesn't want to try your crappy technology because his is so much faster. He's getting 80,000 IOPS.
There's the dev team, who is, like, "Oh, this totally works fine in this environment that I tested, so I deployed it. Now it broke in production, but that's OPs' problem now," who now hate your product because you just woke them up.
So they're going to support you by being like this, which is
actually what my job used to be.
You're going to have this awesome architect who is really glad that you've got a little tiny group inside of the big company using the product, but he's really going to look forward to evaluating the product next year as part of their architectural review board. He's going to block further adoption as best he possibly can.
My favorite one is the security team, who will keep out dangerous threats, like anything that could possibly be good. Not to pick on CircleCI, but, "Oh, you're running continuous integration in the Cloud with our critical source codes?" "Yeah. " "Okay. Well, that's totally a security risk. We're going to need to see all your certifications and everything else."
They're going to do this not because they're bad people, but because they have a fundamentally misaligned incentive. Everyone wants the organization to be safe, but they in particular want to add value by blocking something that is maybe super unsafe.
There are business people, like an army of them, who are going to get so
much satisfaction from catching you miscreants who are misusing the
purchasing system inside of an organization to buy one of all the
products that we're selling.
And then of course there are really people who are a little bit more like us, who are just so cool that even though they love what you're doing, it's not as cool as the thing that they imagined doing. This is true of sys admins.
This is one of the reasons that we actually run into trouble with Chef adoption is the tool that they build and that they have not shared with anyone, or that they're imagining building, is way cooler to install in the future and use because it will make them more awesome than anything that may solve their problem in a second.
And that issue is going to be the one that all of you see again and again and again over time, and it doesn't matter what the product is. This is life when you are dealing with organizations that depend on the tools that you're trying to build — o rganizations that have developed major resistance to trying new things for probably good reasons early on, but may have nothing to do with the value that you actually bring.
So just recognize that the procurement problem is a fundamental one that goes to the very core of technology adoption, to the success of our companies, to the funding cycles that we have to play in. Many of you couldn't have existed three years ago, or even two years ago. Like, Github needed to actually have enough commercial adoption that there was no way that you could argue that Perforce did the same thing. And you had to be able to get around all kinds of other stuff. For PaaS, Heroku had to have enough adoption. Salesforce had to have enough adoption.
So anyway, just recognize that when incentives are fundamentally misaligned in organizations, you are going to run into problems, and you're going to run into those problems at the moment when you should be succeeding. That's why these become so expensive. These lessons are so expensive.
Right at the moment when the customer is about to get the most value by adopting something organization- wide, that's when this dude shows up, and it's because you're about to change something, and there are all these people that resist.
So what do you do? You must be building: You're going to need to be building organizational capacity into your plans now. I say this somewhat emotionally.
What I'm about to tell you is what makes the difference between you getting to be founding CEO for a very long time, and not founding CEO for a very long time.
Some other person running the company and building towards a different plan.
The first is, you have to have a grown up plan for building a sales capacity within the organization.
We can talk for hours about the specifics of this, but that means you're going to have a person who runs a business unit. It's a function within the org. It takes you much longer than it should. I waited about six months too long to start it, and it cost Chef dearly in our early days. Also, it triggered our plan B for how we were going to build and grow the organization.
You're going to have to build grown up customer support.
And this goes back to the anticipating the stage appropriate transitions, and the chasm. Types of customer support that you're going to need on day one that you and the small team can do are going to be very different as the sophistication of customers changes. If you've got a group who isn't a technology leader, they're not going to get why continuous integration matters. They're not going to get why automation matters, and you're going to have to do a lot more customer education than you ever planned for.
My recommendation here is that for each of the things I'm about to describe, you're going to need to hire someone awesome into that role who is going to grow with it for a period of time. If you haven't done this and you aren't thinking about it clearly, and I mean that as in you have a plan and you're executing against that plan, this is the time to begin doing that. You will always be months behind where you should be.
All of us, because we sell to developers, we provide services to developers, end up having to care deeply about community, and there are very few companies that make this transition well. It is something that happens because we build companies to serve people like ourselves, and then over time we want someone else to do it because we get too busy, or we never get someone else to do it because we're so busy.
Over time you're also going to need professional services and solutions in most cases.
This is irritating because it's exactly what we wanted to get
away from, but basically what I'm saying is all of these people who use
your product are going to need help becoming successful with your product,
and almost none of us are good enough at this to do it — none of us have a
simple enough problem that it doesn't require help to actually transition
to being productive.
And the last is actual grown-up marketing.
We'll come back around on this, because there are some anti patterns. Making the right marketing hire early will help you talk to the other people as you make that transition to try to cross the chasm is super hard, and most of us get it wrong because most marketing people don't understand developers. Shanley, who is in the audience, does. She's probably one of the few examples where you can hire a marketing person who can help you develop an entire way of interacting with a developer community, and then the customer beyond that.
So, again, most of you will start this three to six months late.
So after I work with a startup and they get this religion and they start working on it, the tendency is to immediately try to hire the exact wrong people. Very simply, they try to over hire.
So, when I have these conversations with startups that I work with, I try to get it so they don't end up having the conversation with their VCs. But if you talk to a VC who is advising you or pressuring you, they are going to have a cadre of people who have made them a lot of money before. Who are really good at these roles, but in large companies that they grew up in.
So the advice and the introductions that you're going to get from most people for people in these roles, they're going to be way too high up. So you end up over-hiring and you bring in the wrong person.
Anyone that wants a C in their title or a VP in their title is the wrong hire in most cases for one of these first positions.
It's because they're going to be a
mismatch. They're going to expect and need a whole bunch of stuff that you
aren't ready for organizationally.
So don't take that pressure from VCs or others who are giving you that strong advice. What you want is to take that meeting, but find the person who they think is a young up and comer, new, unproven yet, but really aggressive, and hire that person in a lower level role that they're able to grow into.
Generally, people who are later stage in their career are a bad match for an early stage developer- focused startup because they're going to want to apply big company concepts to small one -on -one problems. So hire somebody who you can grow with, as opposed to somebody that comes in and is going to solve all your problems magically.
The next mistake is that they hire that person, and then they have the new VP of sales and marketing, or sales or marketing, manage community. This is so frickin' common, and you all hate when it happens. It's one that blows me away that we get wrong so consistently.
So community, and by that I mean the one to one relationship that you have and you foster between your early and most productive users, the people who believe most in you is something that as founders and as early employees of a company, you can't push it down too soon.
You probably shouldn't ever
push it into an organization that serves sales and marketing for any early
stage company. It needs to remain very close. And the reason is that those
early adopters, those people who believe most in you, are going to have the
hardest time sticking with the transitions that the company goes through.
The set of problems and the set of solutions that you have early on will not work well for the next stage of customers that come in, and it's crucial that you pay attention to that and you manage that well. So don't let them take this on.
It needs to remain something that remains
core to the senior team, and not something that gets pushed down. Because
as you make this transition you're going to start caring about money
organizationally. That's going to be the set of questions the you're
talking about as you build, as you go from seed to the next stages.
What's going to happen is you're going to spend time talking more about revenue and plans for revenue, and adoption, and a bunch of other stuff, and the community stuff becomes a line item expense.
When I work with startups who are trying to figure out how to make this transition authentically, my advice is, and I've seen it go both ways, and it consistently goes badly, my advice is, you want to keep that within the founding team as long as possible, remain engaged as long as possible. It is incredibly high return.
Do not allow it to be something that happens over there. It has got to be core to the company, and do not put it under sales and marketing too soon, or it becomes subordinate to revenue. T hen whatever you end up doing becomes, "How do we extract revenue from our community?" Which is not the same as trying to get revenue from customers.
Over time you're going to find a pretty typical transition point as you bring in more folks, and you're starting to look for identifiable traction points. You want to show, "We're winning! We're winning in the market. We don't have revenue yet, but we're going to soon." You will say some combination of blah, blah, blah, go to market, partners, revenue.
This is what that looks like — I'm going to pick on Nimbula because they're gone: "They Open Their Doors to Partners." You can see there, "Hot, private- cloud startup Nimbula is getting in on the ecosystem act, announcing this morning a partner program comprised of Chef, Puppet Labs, Scalr, enStratus and Cloud Cruiser."
So, blah, blah, blah, go to market, blah, blah, blah, partners, blah, blah, blah, revenue. I helped out with this press release. So I'm certainly not exempt. Another example, "An SDN provider's jockey for position, PLUMgrid hopes partnerships will make it stand apart."
So this is essentially stone soup. Everyone shows up. No one has any money. No one has any actual customers. But we show up and we make a partnership about how we're going to make partners, and then that gets news, which makes everyone think that we're doing well, which makes us get more news, which makes us get more partners, and the cycle continues itself. Except what actually happens is this, which is that you end up doing endless WebEx's in hopes of some day getting partner money.
And this flimsy charade demeans us both. This is, in fact, totally ridiculous. Now, you all have to do it at some point. It's going to be a thing that happens when you have a head of marketing, or a head of sales.
Oh, I didn't mention, don't hire a head of business development. No one at this stage needs that, or if you think you do, please come talk to me. Certainly if you hire a head of business development they will go and develop business, and guess what you will have? A lot, a lot of this. This is what that is going to look like.
So, basically, what it provides is validation, which will feel very important, and it will become very important for a large number of you if you are fucking up. So if you do not have revenue, this is what you're going to get. This is going to be what you do instead of getting customers. So it's a trap, and it's one that I watch for, particularly in the early stages when people are trying to figure out what they're doing.
One of you has to have a paying customer in order for it to be a
partnership. Not an evaluation. Not, like, okay, a future commit. Not in
reciprocal agreements. Someone has to have deposited money in the bank in
exchange for goods and services, and then the other one who is partnering
should also get money as a result of the partnership. That's what a
Otherwise it's PR. It's great PR if you want to get early attention, and it actually, strangely works on VCs. It works on analysts in a way that it shouldn't. So it's why it's perpetuated. Journalists are hungry for stories, so they're looking to see the next big thing, and every once in awhile there is one that actually work out.
At Chef we've had a number of partnerships that actually are really important and make a big difference. So HP, Dell, IBM, a bunch of other ones, where there was money being exchanged, there's customers, Rackspace, same thing. But that partnership, somewhere someone has to be making money.
So number one, joint paying customers.
Two, do not plan for new revenue as a result of partner activity. You're going to be tempted. Whoever is responsible for the financial plan is going to sit there, and you're going to have a bunch of shit that you put in. You're going to have a line, and it's going to make the thing go like this. It doesn't matter unless you're joining a channel of a major player, and that major player has salespeople with quotas.
Okay. So if, like, Dell or HP, or really any large organization says, "We are going to put quotas on our salespeople for this item," then you get to do that because that's how that works. But if this piece isn't here, you are screwing yourself in one of the most profound ways imaginable. I say it with this clarity because it is so tempting to believe that something else is going to happen. Everyone wants it to happen, and it will not come.
So this is the only situation where that's different. And then you should be terrified, because salespeople in a Fortune 100 organization who are quota carrying for your product in some kind of partnership suddenly results in you getting a bunch of business that you are really not prepared for, which is another problem.
But it happens so rarely that it's not a mistake that I'm putting in this. I have seen it once or twice. Usually you are so over prepared by the time it occurs because you've been screwing around on a bunch of other stuff that you are actually completely ready for what comes.
You will do ALL of the work in a partnership. So every integration that you think someone else might do, they will not. You will do. So if it requires code to be written, a connector to be built, customer things to be done, you will be doing that. So if your plan depends on them doing that, and they have the money and you don't, you're wrong.
All right. So the last thing in this is marketing and PR will secure speaking engagements. So you hire a marketing person, and what you want is to be able to talk at conferences that are good where developers go. So how do you do that?
Well, the most common way that people do it is they have a marketing person who fills out a really, really dry, terrible summary of a talk that they want to give.
It's basically, like, "Blah, blah, blah, thought leader, Artur Bergman, who is running this disruptive content disruption network, is transforming and revolutionizing the blah, blah, blah," and it just goes on and it goes on. Then they write the bio of the speaker and it's the most puffy, stupid thing.
They submit that to conference chairs and they have a spreadsheet, and you will see this for the first time it happens, it shows the conferences that they've gotten you accepted to. It happens, like, it could be a PR person. They're really proud of this. They are super excited. They will go on about how great they are, and they will charge you a lot of money.
As a conference chair, I want to tell you the first thing, which is that I really appreciate that because what I and most good conference chairs do, is
we take that entire list of talks that are submitted by anyone other than the speaker, and we decline them.
So if you ever have a thing that you want to speak about, you cannot have anyone other than you submit and manage the talk.
Is this news to anyone? Raise your hand if it's news.
It's news for some folks. So this is not how it works. You do not get attention through PR people submitting talks. The reason that I bring this up, and the reason it is an anti- pattern, the moment that a company gets a Series A done, they start looking at how they are going to spread the word. They are going to do evangelism. They are going to do all this outreach.
Conference speaking becomes a line item, and they have a budget of the number of talks they're going to give, and a whole bunch of other stuff. So there's this incentive where you're like, "Oh, shoot. I've got to get that put together." So you can't fake it, is what I want you to know.
The typical response once you're not accepted because they submitted it, is then you sponsor and you do paid talks, which you are certainly welcome to do, but they are not the type of grassroots evangelism that you need in order to spread the story and message that you have.
Number one, you have a story to share, and that people want to hear that story, and that they will want to repeat it to others. If you're looking for a metric, it needs to be a story that you yourself would want to pay to sit in a room to listen to — I'm hoping that this is that. None of you have gotten up yet, but maybe you will shortly.
You yourself propose it and you propose that story to the conference chair using whatever process they have, and then following up, if you don't know them already, to tell them that you are awesome.
More importantly, you need other people to do that for you. Again, I'm going to pick on CircleCI. There's a hajillion continuous integration companies right now all vying to be able to talk at all the different conferences.
For some reason I gave the keynote at QCon on continuous delivery and continuous deployment, and the reason that I was able to do that is I didn't talk about, in any depth, the product that I was doing, but instead about how to get people to think about how to use continuous integration and deployment.
A) want to present content that is generally useful. Product pitches do not work. So they end up getting you never invited back,
B) you need to be a good speaker in a way that is referenceable for other people, and that's what conference chairs look for.
That's it. There's no other way.
When you deliver the speech you then have to actually be awesome.
A good rule of thumb is I spend about an hour per minute of new material preparing a speech.
So if you're giving a 40 minute conference talk, that is one full uninterrupted week at the office, in addition to your other 40 hours, but whatever, that you have to spend preparing, rehearsing and delivering that, and that's if you're an already experienced speaker.
I have now given probably an excess of 70 conference talks, like, 20 keynotes, and I'm only slightly better at this point in terms of how much time it takes me to do, with the exception of, I have a lot of material ready to go because I speak so much. That's going to be your job if you're in the early stages. There will be no more authentic person to talk about the company than you.
You then repeat the cycle over and over and over again. And this is how companies are able to do grassroots evangelism to good developer conferences. This is the other thing. There are a lot of really, really bad ones.
So the metric
for your early days as you're trying to figure out how you're going to
spend money is, would you pay out of pocket to go? If you wouldn't, don't
go. Unless you need the speaking engagement for some ridiculous credibility
reason, which you probably don't.
But this is, again, why you want to be deeply involved. Because if you're not getting accepted what will happen is the conference, or your marketing team, will get you into really crappy conferences that have no one there and is far away, and expensive to travel to. At our stage you can't just afford a boondoggle like that, and they are sad and lonely and boring, and you feel bad at the end, and you're out a bunch of money, and you failed to do the thing you set out to do.
So this is how conferences actually work. There are no shortcuts. You can't pay your way around it. That's it. Okay. Yeah, one hour of prep per minute.
Number ten is not being ready for the next fundraising. I'm going to say this and probably regret it later. So in one of the rounds of fundraising that we were doing, I ended up getting really sick the night before. It was the partner meeting. It was a giant deal. There was no way that I could back out of it. And it had been a really hard deal to put together. It was crucial to the next stage of the company. I was puking and a whole bunch of other things and kind of wished that I was dying and not trying to prepare for this crucial meeting in the morning.
It's a little easier in the Bay Area, but not much. As the stakes go up for all of you and you stop being sexy, cool new startup where you're young and maybe not experienced enough, and so VCs are going to give you a little bit of leeway to where they're basically evaluating numbers and appropriateness of management team and a bunch of other stuff.
I want to impress upon you that the fundraising process, the stakes go way up. When I talk to startups and I help them, often times it's a thing that they're expecting, A, will work like their last YC round, which it will not. It will not work that way. You hear about the Series A crunch and all this other stuff. The stakes for enterprise startups are even higher, because they are expecting revenue. They are expecting a bunch of stories. They're expecting a bunch of other stuff.
So when I work with teams, and particularly the companies I advise, I
treat it like a firefighter. It is an
operational process that involves the entire team committed for a specific
amount of time.
I actually carry a little medical kit, which includes anti- nausea, anti- diarrhea, which I have needed, and if I didn't have, would have had a serious problem in a pitch. I'm saying that so that you can take that to heart and not be in that horrible situation. I'm serious. Not kidding.
I also carry a change of clothes in the car. I carry every possible converter. I carry a bunch of water. I carry food. I carry breath mints. I carry a razor, and every personal item that I might need because you never know when that moment is going to come that you're presenting. Something goes wrong, and the whim of venture capital who you are dependent on in order to achieve the dreams that you all have, is so fickle that, believe it or not, one wrong impression, like you end up being sick all over the table or worse, which, I'm not kidding, is a thing. That can kill your company deader than any other factor and it's one that gets around this very chatty place that we all live faster than you can possibly imagine.
So I have a checklist, and if you email me or just ask me, I will give you the checklist. But I won't do it tonight, because I want you to remember the talk and come back later. It's a very simple operational checklist for the steps and operational mindset going into a fundraising process.
Specifically, it's designed to get you out of the state where you have a bunch of crazy distractions, and into the state where you're making good decisions, where you're actually prepared physically, emotionally, equipment- wise, your team is prepare and understands their roles, and you conclude it successfully.
The thing that most of the time happens is that you get blindsided. You get surprised. You're not really ready. This actually happened to Greg and I a couple of weeks ago, and I find it very funny that even having just coached someone through and given them my checklist, and having a copy printed in my car — I didn't even have water in the car. Greg put water in my car, which is pretty cool. But the point is, it's easy to forget this stuff, and the stakes go up as more and more people depend on you before you figure out how to get all of the revenue out of people.
That's my other most expensive one, which is that, there's no reason to fail in the next stages of your company just because you didn't have a change of clothes, or you didn't have enough water in your car, or you had a huge headache or some other thing. It's surprising and it's not something that most of you will anticipate unless you've been through it, and then you get a little crazy about it.
So that's what I have. I hope this has been helpful. There is the email to reach me tomorrow if you want my checklist. You can feel free to come and talk to me at any time. I'm here to help you, as are all of the other folks, and I hope this is valuable. So thank you.