What happened when my co-founder quit the night before our YC interview

People compare startups to a chess game, but they're a lot closer to Fear Factor. The hardest part isn't intellectual. It's keeping yourself from melting down amidst an inferno.

From the start, my co-founder and I knew our Y Combinator application was a long shot. On April 8, invitations to interview went out, and we didn't get one. Not unexpected. But April 9 brought a reprieve: Paul Graham emailed us to say that due to a bug, our application was overlooked, and he'd like to invite us to interview.

Miraculous!

…but also terrifying: we had 0 lines of code and two weeks to cook up a demo good enough to impress Y Combinator. The next two weeks we hacked furiously. We spewed out code, then ripped it out, twisted it, stretched it, bent it, and re-molded it until we had cobbled together a makeshift demo.

That week proved Murphy's law: everything that could go wrong, did go wrong.

Ten days before the interview, my car broke down.

Six days before the interview, my laptop crashed and we lost our entire demo.

Three days before the interview, we had hastily re-assembled a demo that worked—barely—and a FAQ covering everything we thought the YC partners could possibly ask us.

Two days before the interview, I told my boss I was resigning. I was scared that if I waited until after the interview and YC rejected us, I wouldn't have the guts to quit.

Now it's the home stretch. It's 12:26am the night before our interview and we're putting the finishing touches on the demo. Then my co-founder emails me [1]:

from: would-be co-founder
to: me
date: Wed, Apr 27, 2011 at 12:26 AM

I'm checking in the changes to demo "My Feeds."  Give it a sync and see that it works on your phone.

But I also have to say up front that after the interview, I'm out.  This just isn't what I want right now.  I'm more than happy to go to the interview with you, and even tell the YCombinator people that I'm in if you think it will help your chances of getting it, but after that, this isn't something I want to work on more, so it would probably be good if you look for someone to replace me.  Really sorry, but I'm 100% sure about it.  But I still wish you the best of luck with it!

Fuck. Sinking feeling in the pit of my stomach. There's no way now. My heart races. Fuck. Fuck. Fuck. I try to sleep but can't. Why won't the sun just fucking rise already so we can get it over with. Hours later, I finally doze off, then wake up in a cold sweat. The sun is creeping up. Finally.

The interview is at 4:15 that afternoon. I go into work. The code in front of me is a blur. I try to eat but can't keep anything down. My roommate walks by and says, "You look like a ghost." Fitting. I would like to be invisible. Finally, it's 3:30 and time to drive to YC. My hands are shaking. I use my left hand to force the right to put the keys into the ignition of the rental car.

I walk into the interview room alone, and as six YC partners stare back, Paul Graham asks the obvious question:
"Where's your co-founder?"
"I have good news and bad news…" I explain that he had quit the previous night.
Paul Graham pauses. "You'd be surprised how often that happens to you."
"It's the first time it's happened to me."
They laugh, and what follows is 10 minutes of interrogation. The questions come in rapid fire: halfway through answering the guy on the left, the guy on the right interrupts with a new question. Words pour out of my mouth. Where did those come from? Then just as fast as the interview started, it's all over. I have no idea whether it went well but I know I'm impressed: in ten minutes, they asked me every question written in a FAQ that took weeks to prepare. How on earth can did they pull out so much information in so little time? These guys should work for the CIA.

After the interview, the YC partners make a decision on the spot. If you're accepted, they call you that night. If not, they email you with a reason they're saying no. All that’s left now is to wait for the email.

That night my phone rings:
"I wasn't expecting to receive this call."
"I wasn't expecting to make it." Paul Graham continues, "But you had bulletproof answers to apparently damning questions. Would you like to be part of the summer batch?"
Yes. Absolutely!

Over the next few months, great things happen.

My college roommate packs up his whole life in a weekend to move down from Seattle and start the company with me. We change our idea to a better one. We land our first customer. We pitch the world's top expert in what we're doing—and he decides to lead our seed round. We become one of the "hot" startups at demo day, and have to turn down angel investors who want to pour money into our little company. We hire one of the best engineers I've ever worked with away from Google. My roommate's former boss quits his job to join us.

But this story could easily have stopped at 12:26am.

"Don't give up" is the oldest truism in startups. It's not even true. But it's the part that makes startups hard: managing your own psychology when it looks like everything is falling apart.

[1] email reproduced with permission

Thanks to Christine Yen, Jason Shen, and Ben Komalo for reading drafts of this.

Why is machine learning experiencing such explosive growth today?

(I answered this question on Quora but thought it was worth recording my thoughts here for any email subscribers.)

Machine learning has been around since the 1950's, but only in the last decade or two has it really taken off.

Why is machine learning experiencing such explosive growth today? Why not 60 years ago? Why not 20 years ago?

Data and computation.

The biggest unintended consequence of the shift from desktop to the web is that we now automatically collect vast amounts of data on just about everything, and we can ship improvements instantaneously. Those are the waves that push machine learning forward.

That sounds simple but it's hard to overstate the impact. If you were a brilliant AI researcher working on Microsoft Word in 1990, the only data you had was what you could collect in the lab. If you discovered a breakthrough, it would take years to ship it. Ten years later, the same researcher working at Google had access to a vast repository of search queries, clicks, page views, web pages, and links, and if she found an algorithmic improvement to boost click throughs by 5%, she could ship it instantly.

The internet companies (and folks doing scientific computing) were the first to apply machine learning to huge amounts of data, which is why technologies like MapReduce and BigTable were invented at places like Google, but we're seeing the same techniques move into every other application area: genetics (where the cost of sequencing DNA is falling faster than Moore's law), health (with electronic health records), energy, finance, security, and even the army. It's pervasive enough that "Big Data" conferences like Strata have thousands of attendees.

Likewise, computation is cheap and plentiful. Witness the rebirth of neural networks in the past few years. Has the backpropagation algorithm fundamentally changed since it was invented in 1974? Nope. But we have a million times more CPU power. (We also have algorithmic advances, like pretraining, Hessian-free optimization, etc. but the biggest change is Moore's law.)

Researchers were excited about machine learning as far back as the 1950's, and many of the implications were clear even then. But to achieve that vision required the rise and fall of giants: Intel to build the microprocessor, Apple to pioneer the PC, Microsoft to put a computer on every desktop, Cisco to network the network, AOL to bring the internet to the rest of us, Netscape to invent the web browser, Amazon to bring commerce online, Google to organize the world's information, and Facebook to digitize our friendships.

Ultimately, the reason machine learning works today is not due to any algorithmic breakthrough, but a decades-long macro-trend to digitize and network data, which is just now bearing fruit.

Startups: stop using generic form letters when you tell a candidate 'no'

Imagine you apply to a job at a startup you're jazzed about. After two hour-long phone interviews, they invite you onsite, where you pair program for a day, have lunch with the entire team, meet your potential boss, and ask a bunch of carefully-researched questions about the company. After the interview, you wait with bated breath for the response…

…which is a standard form letter: "We have reviewed your background and qualifications and find that we do not have an appropriate position for you at this time. We appreciate your interest…" [1]

That's impersonal, cold, and aloof — and also the standard in startup recruiting.


Give Personalized Feedback

Most startups don't give candidates personal feedback when saying "no." I had some initial hesitation about giving feedback. But having tried it, the results are nothing but good.

Most people are surprised and grateful to receive feedback. In one dramatic case, it actually landed us an amazing hire. We interviewed a strong student who nonetheless wasn't the right fit at the time. We sent a long message explaining our reasoning, and, surprisingly enough, the student said he understood our reasoning, but thought his roommate would be a perfect fit. Turns out he was right: we interviewed his roommate, made an offer, and he became one of the strongest engineers on the team. The world isn't always a fair place, but sometimes doing the right thing is rewarded.

The negatives are minor. Out of 100+ candidates, only one person has tried to argue with the result. The time investment is typically about 15-30 minutes, which is small compared to the time spent on a full-day on-site interview and phone interviews.


Striking the Right Tone

When writing the feedback, you have to strike a delicate tone, and that's best done by having the right attitude. You're not rejecting somebody because they're not "good enough"—even the best-run hiring processes reject lots of great people since a false positive is more costly than a false negative. And many times, especially for early stage startups, you'd say "no" to somebody as employee #3 who you'd gladly hire as employee #20. Fit with the company, and the stage of the company, matter a lot. Try to be gracious. It doesn't mean you can't also be straightforward, but acknowledge that your hiring process has noise and subjectivity.

It helps to be specific and explain why you're looking for whatever skill you're looking for. For example, "We were really impressed by your answers to the algorithms questions, and your Python code was very clean, but when it came to the questions requiring C programming, we were looking for more fluency using pointers in real-life situations, and more knowledge of operating systems implementation like page tables, inodes, and how different layers of the networking stack work. We focus a lot on those skills since we're building a memory-mapped distributed database." The details vary, but you get the impression. After getting that feedback, you can imagine somebody practicing those skills and reading up on those areas so that they do better next time.

How can you tell whether you're hitting the right tone? Look at the response rate. Most people will thank you for a gracious and helpful reply with feedback. If your response rate is below 80%, there's something wrong with the message.

As always, there are legal risks involved with anything related to hiring. This is not legal advice. Check with a lawyer.


Closing Thoughts

If you're a founder, it's easy to blow off giving candidates feedback as a waste of time. Most founders are stressed and overworked, and hiring already consumes heaps of time. But somebody who spent a day interviewing with you deserves more than a form letter. Giving them feedback on how to improve is worth the time, and might just land you your next hire.


[1] These are even more hilarious when the company includes multiple templates to cover scenarios like being rejected after the resume, phone interview, or onsite in the same email.

Advice for CS Students Considering a Startup

If you're a computer science student graduating in 2014, you have no shortage of options. Big companies like Facebook, Google, and Twitter are gobbling up smart engineers by the thousands, it's easier than ever to start a company, and there are 1000+ startups in the Bay Area alone.

When I graduated, almost nobody from my class joined startups, or, if they did, they joined as employee 50+. These days, it's the opposite: many of the best students want to join startups, and many join as employee 10 or earlier.

But how do you find the right startup? Picking a startup requires solving two hard problems: judging the startup itself, and judging whether you'd be happy. The first is what professional investors do, and most of them lose money. As for the second, people are notoriously bad at predicting their own happiness; they think status, or money, or a promotion will make them happy, but then they get it and they're miserable.

You can't solve either problem with 100% certainty. Startups are risky, after all. But what follows are some techniques for finding startups to join and questions to ask to gauge both the startup and your own happiness.


Ignore defaults

When I was graduating, most students wanted to get a PhD or join a big company like Google, and startups were considered almost like a backup plan. I didn't even interview at a company of fewer than 70 people.

I wish I had. Defaults often blind us to different alternatives. And as I met people from different schools, I found defaults varied widely. At MIT and Stanford, most of the top students want to work at startups, and some don't even bother applying to big companies. At other schools, it's the reverse.

Why the difference? No reason at all. People just mimic what they saw the previous graduating class do. Do what you want to do, and ignore defaults.


Breakout hit or infant?

There are two types of startups worth considering. One is a breakout hit—a company like Pinterest, Square, or Stripe which has hit product/market fit and is growing incredibly quickly. A breakout hit will teach you how to scale a successful product and team: what breaks when you go from 30 to 300 people? How do you re-architect your system to handle millions of users? Breakout hits often become magnets for brilliant engineers (e.g., Dropbox hiring the creator of Python), and since they're growing quickly, opportunities come easily.

The other is an infant: a startup founded recently (<3 years), small (<20 people), and in the midst of a vigorous search for product/market fit. At an infant, you're figuring out how to create a successful product from nothing. You're going to work directly with the founders and get exposed to details about fundraising, pricing, sales, marketing, and more. If you want to start a startup one day, this kind of startup will teach you things you can't learn anywhere else.

The middle ground—say, a startup was founded four years ago but isn't a breakout hit—is generally a bad deal, although there are always exceptions.


Where to find great startups

Finding great startups is still a messy process, but it's getting easier. The best place to find great startups is to ask friends or TAs who joined or founded startups the previous year for recommendations. Most of the best opportunities aren't advertised.

If you don't know many people in startups already, then I'd recommend starting with AngelList talent, which lets you filter down startups down by location, size, industry, and more. Hacker News' jobs page, which consists only of YC-backed companies, is also a good starting point. Some colleges like UC Berkeley or University of Washington are starting to have dedicated startup career fairs.

Even if a startup isn't advertising college jobs, don't be afraid to just send them a resume or GitHub link. The only rule with startups is that there are no rules, so take the initiative.


Practicing for the interview

Many startups use a variant of standard coding interviews. I'd recommend buying Programmming Interviews Exposed or Cracking the Coding Interview and spending a few days doing practice exercises. Like the SATs, test preparation hits diminishing returns rapidly, but a little focused study can still buy you a few notches of improvement.

More and more startups are starting to do pair programming, where you sit at a computer and actually code something. Pair programming takes some getting used to; it’s worth trying it for a class project so that you’re not flustered in the interview.


Happiness

Psychologists have found that the happiest people focus on just a few things: a strong sense of purpose, mastery of a skill or field, autonomy, and positive relationships. These next few sections are organized around those themes.


Idea and purpose

Predicting whether an infant startup will succeed is notoriously difficult. Most professional VCs lose money and they're supposed to be experts at picking winners. If you can’t pick winners, what can you pick? A startup with a purpose worth fighting for.

In other words, if the startup succeeds wildly, what happens? Did we cure unemployment? Did sweatshops come to an end? Was evil on the internet vanquished? Make sure it's a purpose that you can imagine yourself growing passionate about. I say "you can imagine" because, like love, passion for an idea grows with time.  At my first job, I was assigned to work on ads and I remember the feeling of disappointment. I hate ads. But over time I grew to love it as I saw that we were doing good for small businesses.

A more quantitative way to look at "who cares" is market size: what's the maximum revenue the startup could achieve, if it had 100% market share? (This isn't perfect, e.g., non-profits can have high impact with no revenue, but it works for most businesses.) You want a plausible calculation that that number will be in the billions. Don’t settle for a niche.

People are routinely under-ambitious. Little problems seem so tractable and big problems just seem impossible. But in reality, building a company is hard regardless of problem size, and problems that seem impossible often turn out to be merely difficult, so frighteningly ambitious startup ideas ideas tend to be under-valued. Don’t sell yourself short.

Still worried about success? Here's one small trick: look for top tier investors. The top quarter or so of investors make all of the money in venture capital, and they do so by picking winners. A startup that receives backing from them has a significantly better-than-random chance of being successful.


Who will you be in 5 years? Learning and mastery

You become the people you spend time with. So choose carefully. You're going to spend more time with your co-workers than just about anybody else, even your significant other or spouse! So think about who you want to be five years from now. What skills will you need to master now?

If you don't know, that's ok — I didn't know in college. My general advice is to learn something that's very hard and growing quickly. Today, machine learning, mobile, distributed systems, and computational genomics are good examples of fields that are hard and growing. But I wouldn't recommend trying to become e.g., a Rails programmer. Learning Rails is useful, but if you let that be the skill that defines you, you'll get lost in a sea of other people. Learn something hard and not only will the work itself be more rewarding, it'll open doors to opportunities you couldn't get otherwise.

Look for people on the team who are world-class experts in skills you'd like to master. For engineering teams, that generally means joining an all-star group of engineers. Did they work for highly-selective companies? Author important open-source projects? Do they have PhDs or publications in the field? Also look for good development practices, like code reviews and unit tests. If you're tempted to compromise, even a little bit, on the quality of the team—don't. Here's a heuristic to keep yourself honest: if you were competing with a somebody for a job, would you be scared? If so, you want them as a co-worker.

What if you want to start a startup one day? Should you find a startup with the very best business team? Paradoxically, no. You're best off joining a small startup with few or no business people, since in those companies, engineers will be called upon to fill in the gaps. If you take initiative, you can take on more responsibility and learn business by doing it.


Autonomy

Provided you have initiative, most startups offer tons of autonomy. But it's worth asking questions: how does the company decide which projects or tasks to work on (top-down, or does the team participate)? Are there sub-teams that set their own goals? Do junior engineers design components or implement others' designs? Is the organization "flat" or is there a high ratio of managers to doers?  In particular, be careful about startups with a lot of PMs or non-technical founders. It tends to lead to a culture where engineers make fewer decisions about the product.


People, culture, and relationships

Beyond finding people who can teach you, you should find people you like. You're going to spend a lot of time together and personal chemistry is important. Try to gauge whether people are happy at the company, and mostly ignore what they say and instead focus on how they say—tone of voice, body language, whether they joke around, etc.

Companies usually include lunch as part of the interview day, but everybody is on their "best behavior." If you get an offer, try to see if there's a way to talk with some of your co-workers (ideally not the founders—founders are often good salespeople) in an informal setting, e.g., coffee or drinks, to gauge personal fit. Use the airport test: if you saw one of your potential teammates at an airport, would you run over to talk with them? Or would you try to avoid them?

Worry about integrity, especially of the founders. You don't want to work with people who will screw you, and unfortunately there are sharks in the startup community. Evaluating integrity of somebody you met recently is very difficult. Ignore what they say and focus on what they do. People who screw others tend to have a zero-sum view of the world, so look at the equity package—did they offer you the absolute minimum they think you'd accept, or is it above-average and generous? Are they transparent? Does the team include people who have worked with them before? Con men don't get repeat business.

Also, think about your personal life. In college, making friends comes easily; in the adult world, making friends takes effort. One real disadvantage of working for an infant startup is that you meet fewer people. So if you're going to join an infant startup, make sure you have something in place to compensate: a lot of classmates who are moving to the same city or friends from previous internships. It sounds trivial but relationships affect your happiness a lot.


Negotiating the offer

Most engineers are reluctant to negotiate. In 2013, engineers are rare and precious, and that gives you more leverage in negotiation. Don't abuse it, but don't be afraid to get a fair offer for yourself.

For infant companies, equity grants vary wildly. I've heard anywhere from 0.1% to 5%. And if you're joining as the 5th (or 10th, or 15th, …) engineer, nothing is standardized, and the company probably wants you badly. So it pays—literally—to politely ask for more. One caveat: if the company radically improves its offer (e.g., doubles it), that's a bad sign. Either the company was low-balling you (in which case, can you trust them?) or they're offering you a lot more than other employees are making (in which case… can you trust them?). Negotiations are prologue to the company's behavior later on.

If you're joining a breakout hit, there are probably standardized offers, but you should still negotiate. In Silicon Valley, top companies pay new college graduates roughly 100k-120k in salary and 200-300k in stock over four years. If you negotiate, you can often (not always) get 20-50% more stock options.

It's easy to overdo it; I generally wouldn't do more than one round of negotiation, maybe a second.

This almost goes without saying, but all startups should include health care as part of their offer.


Try before you buy

If you're a freshmen or sophomore, try to do internships at companies in different stages: infant (<20 people), breakout hit, or big company. You'll learn a lot about your own preferences. If you're a senior and you haven't interned at a startup, one option is to work at a startup part time in your senior year. Most startups don't advertise part time jobs, but are glad to have the help if offered.

Making the final decision

Startups can be an exciting way to start your career, and worth the extra time spent. When evaluating an offer, it's easy to focus on peripheral aspects, like a high salary, benefits, or media hype. But remember that happiness isn't money, benefits, or hype. Focus on the core: a purpose you care about, mastery of a challenging field, autonomy in your day-to-day work, and building productive relationships with your peers. Those are the only things that matter.

When it comes down to the final decision, it’s easy to overanalyze and fret. Research shows that for complex decisions with many variables, your unconscious mind makes better decisions. So let it work. Think hard, soak in all the information, but in the end, go with your heart.


Update: HN discussion.


Thanks to David Hu and Akihiro Matsukawa for reading drafts of this post.

Enterprise Sales Tips for Hackers

When my co-founder and I were starting out, we came from an engineering background and thought of sales as black magic. Divine the customer's deepest desires, howl a few bewitching incantations, and then—abracadabra—a contract would be conjured. Magic!

Two years of selling served as a painful exorcism. There's no magic to enterprise sales, but there's a hell of a lot of zoology. LTV, field sales, inside sales, CAC, prospects, leads, consumerization, channel sales, … the array of terms is bewildering and there's no textbook that explains how it all fits together.

But there's good news. Not only can smart hackers can learn to sell, the hacker mindset is actually an asset: at its core, selling is hacking organizations.

However, it's easy to spin your wheels unless you have some orientation. What follows is a quick primer on enterprise sales for hackers. I've tried to briefly touch on the basics. To really understand the details, you'll need to follow many of the linked posts and—of course—do some sales yourself.


Finding Initial Customers

Find the hair-on-fire customers, ignore the rest. When we started out, we were heartened any time a customer expressed enthusiasm. And then we'd follow up, nothing would happen for months, and we'd get discouraged. Ignore how enthusiastic the customer seems in a meeting. Instead, look for people with hair-on-fire problems.

And expect it to take time: if you want to find 10 hair-on-fire customers, you need to pitch 100.

That means need to qualify leads ruthlessly. The worst thing a customer isn't saying "no," it's dragging you through meeting after meeting without making a firm commitment. Don't ask whether the customer is interested. Ask whether the problem you're solving is their in their top three problems.

A great trick is to ask the customer to do a trivial amount of work; for example, sign an NDA. This will weed out people who aren't yet serious. A variant of this, for customers asking you to do significant custom work, is to request a significant up-front payment.

Where do you find initial customers? Get some warm introductions. Draw up a list of 50 customers you'd like to target, search on LinkedIn for mutual connections, and ask for an introduction. Investors can be helpful here, but introductions can come from anywhere.


Inside the sales meeting

Most of the day-to-day work of sales is takes place in customer meetings. For many hackers, these feel unnatural at first—and they certainly rest on some innate qualities like personal charisma, empathy, and poise—but like any other skill, running good customer meetings can be learned with practice and guidance.

It's the ROI, stupid. Unlike consumers, companies rarely buy on emotion. They buy on ROI. If you want to close a customer, try making a spreadsheet to show them how much money they'll make if they sign up with you.

Every big deal needs to have an advocate, an economic buyer, and technical buyer. The enterprise sales process involves multiple parties, but in every big deal, you should quickly try to identify the advocate (somebody on the inside who is pushing for you), economic buyer (person who controls the budget), and technical buyer (person who evaluates/will use your software). If you can't identify these three, you probably don't have a sale. For a great sales methodology, see Mark Suster's posts on PUCCKA.

Pitch the top line, not the bottom line. An excellent product can grow revenue by 5-10%. Almost no products can cut costs by 5-10%. Figure out how you can increase your customers' top-line revenue, and build your pitch around growth rather than cost-cutting.

Ask for the order. Most hackers are too shy and flinch when asking for money. Don't beat around the bush. Always ask for the order, even if you're not sure if the meeting when well. In one of our early customer meetings, we thought we had blown it. As we were leaving, the person said: "I'm almost offended you didn't ask me to join your private beta."  It turned out he was keenly interested in our product, and we had misread his intense questioning as skepticism. Ask for the friggin' order!


Sales Strategy

Once you have some pilot customers, take a step back and think about your company's overall sales strategy. What is your ideal customer? How do you reach them? What type of salespeople will you need to hire?

Think of your overall sales process in terms of unit economics: how much money will you earn from a customer over their lifetime (life time value, or LTV)? And how much did it cost to sign them up (customer acquisition cost, or CAC)? Generally speaking, you want LTV > 3*CAC. Otherwise, you're not bringing in enough revenue to finance growth.

David Skoll's blog has a great intro to SaaS unit economics, to which Bill Gurley provides a counterpoint.

CAC is driven by what type of sales you do, and what type of sales you do is driven how your customers buy software. Strategy starts with the customer.

That's worth re-stating: customer acquisition cost is mostly out of your control. If I know how your customer's buying process, I can tell you your eventual CAC without knowing a single thing about your sales team. So work outside-in: rigorously understand how your customers buy software, design your sales process to match that, figure out how costly that sales process is, and then set your pricing to support it.

Roughly speaking, your sales process will fall into one of three basic strategies.

The most expensive sales strategy is field sales, in which a salesperson makes in-person visits to the customer. This can cost $25k, or even $200k if you need sales engineers to build proofs-of-concepts (popular for very expensive enterprise contracts).

The cheapest strategy is self-service, where the customer signs up on your web site without requiring any humans in the loop at all. Here, the typical CAC is under $100. Stripe and GitHub are examples, but many enterprise products are too complex to be sold through self-service.

Inside sales form the middle ground. Everything is done over the phone or web, with light touch, lowering costs dramatically — roughly $1k-$10k is typical.

The conventional wisdom is that software priced between $1,000 and $100,000 is the "valley of death": expensive enough to trigger complex corporate approval processes, but not enough to cover the cost of paying a salesperson. These days the "valley of death" is shrinking due to the prevalence of SaaS, enterprise freemium, and inside sales. See SaaS survey to get a sense of today's business metrics.

A brief word on channel sales: channel sales don't work for startups. Outsourcing sales works just as poorly as outsourcing engineering. Own your sales pitch.

PR is your "air war." Press alone won't close deals, but it does open doors. When Wired and the WSJ covered us, customers who ignored us before called us back up. Press creates legitimacy that you can't create for yourself.


Closing Thoughts

Enterprise sales doesn't have to be black magic. If you're a hacker starting an enterprise startup, selling is one of the most valuable skills you can learn. Before you've hired a sales person, it'll give you great insight into how customers think about your product. And when the time comes to hire a salesperson, you'll be better able to judge candidates when you've learned to do the job yourself.


Update: HN Thread.

Is your B2B startup New Enterprise or Old Enterprise?

Picture an enterprise startup. What comes to mind?

Most people imagine an army of expensive salespeople wearing Rolex watches and flying around the country to sign seven-figure contracts with the Fortune 500. That's the Old Enterprise. The Old Enterprise is all about top-down sales: first you convince executives and other decision-makers to buy your product, then you negotiate a contract, then you install it, and only then can employees toward the bottom of the organization start using your software.

But there's a new model emblemized by startups like Twilio, Stripe, GitHub, Yammer, and 10gen (the makers of MongoDB). The New Enterprise is about grassroots, bottom-up adoption. Take Twilio, for example. If a developer at a company wants to start using Twilio, they just need to sign up and they can start integrating the API immediately. There’s no contract, no setup fee, no need to talk to a salesperson, and it takes minutes.

You can tell whether a startup is New Enterprise or Old Enterprise by just looking at their web site. Do you see a "Try it now" button? That’s the New Enterprise. Do you see a button to "Request a Demo"? Old Enterprise.

New Enterprise vs. Old Enterprise is like the tectonic plates of B2B startups. It affects who your customers are, how you sell to them, who your investors are, and what roles you hire for. Those who straddle the middle risk liquefaction.


Is New always better?

If you’re an engineer, designer, or product person, the New Enterprise holds an incredible allure. It means you can forget about 12-18 month sales cycles. Rather than sales, you can compete on product and design, a strength for many founders. And you can import compelling ideas like virality from the consumer world and use those to fuel your product’s growth.

But New isn’t always better. Even among a top VC with a relatively young portfolio like Andreessen-Horowitz, 16 of their 28 enterprise investments fall into the traditional Old Enterprise model.

What gives?

The trend is obvious if you break out investments by category:

Category
Old Enterprise
New Enterprise
Developer APIs
0
6
Collaboration
0
4
Security
3
1
Business Intelligence
3
0
E-Commerce services
2
0
Storage/Networking
5
1
Other
3
0

For startups creating developer APIs (e.g., PagerDuty, Meteor) or collaboration software (e.g., Asana, Box), the New Enterprise predominates. For all other categories, well... Meet the New Enterprise Customer, he’s a lot like the Old Enterprise customer.


Strategy Starts with the Customer

To understand why things are so polarized, you have to think about how a typical company buys software.

Let's say your startup sells A/B testing software, and your product lets marketers try different text on the site and measure conversion rates. At a typical company, the users of the software are people in the marketing department (the "technical buyer"). But they can't buy your software alone -- the CMO or VP Marketing controls the budget (they’re the "economic buyer"). Not only that, a typical enterprise installation requires modifying code on the web site, which means you'll need to get approval from a bevy of engineers, engineering managers, or product managers. You may also have to handle objections from security, procurement (who negotiate contracts), legal (does your software comply with the company's privacy policy?), and possibly more "stakeholders." This is a complex, lengthy sales process, and to make it harder, often people inside of the company can't even describe how the full purchasing process works. Great enterprise sales representatives are masters at taming organizational complexity, ruthlessly mapping out the decision-making process and checking off boxes until the contract is signed and the software up and running.

It's tempting to want to bypass the complexity of top-down sales, and just build a product that "sells itself."

But if that's not the way your customer buys software, that's not the way you're going to sell it. You can change your design, you can change your feature set, and you can change your marketing. But you can't change your customer. Your customer's buying process is your selling process. Since the default customer buying process is complex and involves many people, the default B2B startup strategy is Old Enterprise.


When does the New Enterprise model work?

The "New Enterprise" model succeeds if, and only if, there's a "unitary customer" at a company who can decide to use your product unilaterally, with no approvals from anybody else. Then you can bypass the traditional top-down sales model. Most New Enterprise startups follow one of three basic strategies:

Open source, e.g. 10gen, Meteor, Cloudera. The core software is open source, and developers can download a version and immediately start using it without paying a cent. Once the customer relies on the software day-to-day in production, you can sell them a support contract or premium (closed-source) features. This is a variant of the freemium model.

Developer-oriented software as a service, e.g. Stripe, Twilio, Parse, Firebase. The software is a back-end API that developers integrate, and it’s either free or cheap enough to come out of a personal or team budget (e.g., generally < $1000), without requiring corporate approval. These companies sometimes have free plans, but you don’t have to do a freemium model to make this work.

Team collaboration, e.g., Yammer, Asana, Box. One person on the team can start using the software for free and invite others. These products are almost always freemium and viral. The idea is that the software will spread throughout the organization, and once a critical mass of employees are using it, then the sales process begins. Usually, the startup sells premium enterprise features—for example, controls on sharing, quotas, e-discovery support—in exchange for a large enterprise contract with the company's IT department.


Does it scale?

For early stage startups, New Enterprise vs. Old Enterprise is a strict dichotomy. But as companies grow, they naturally adopt a mix of sales strategies tuned to different segments of the market. For example, Twilio has started hiring enterprise sales reps, just as Yammer did several years ago. And traditional companies sometimes introduce a freemium product. That’s normal — all companies grow in layers. Particularly for companies that start off with the New Enterprise model, it’s almost always eventually necessary to add an enterprise sales force—with support roles like sales engineers, account managers, people to qualify leads, etc.—in order to build a truly  meaningful business.


Conclusion

Strategy starts with the customer. Carefully observe how your customers buy software. If you find a unitary customer, you can go after the bottom-up New Enterprise model. Otherwise, stick with Old Enterprise.


Thanks to Alex Rampell and Chris Dixon for reading drafts of this.

No filter: the meanest thing Paul Graham said to a startup

Our second week in Y Combinator, we almost pivoted away from building a B2B startup. As we walked up a hill on our way to office hours, my co-founder turned to me and said, "What are we doing here? I want to build something my mom can use." So we pivoted to a mobile app for local events.

Our friends, well-intentioned but misguided, feigned enthusiasm and acted supportive of our new direction. The YC partners, who had seen another startup crash and burn in the previous batch with a nearly-identical idea, politely tried to steer us back to our original idea.

Nobody got through to us until Paul Graham found words sharp enough to pierce our mental armor. During office hours with Sam Altman, Sam told us we were about to make a huge mistake, said "Let me get PG," and darted out to the next room. Uh oh. Paul Graham came running into our tiny conference room, obviously irritated, and said:

"Moments like these make me glad we invested in sixty-four startups!" He threw up his hands in exasperation. "If you want to drive off a cliff, go right ahead."

Later, he told us we were "like moths for bad ideas." Oof

That was enough to pop our bubble. We sucked it up and went back to the hard work of building a B2B company. Paul Graham later said that was the meanest thing he had said to a startup. But in retrospect, it was actually one of the nicest things anybody did for us.


No Filter

Giving blunt, unfiltered feedback is one of the secrets to Y Combinator's success. And that same brutal honesty is seems to be at the core of many of the greatest technology companies like Apple, Google, and Microsoft. Steve Jobs described his role at Apple as:

I don’t think I run roughshod over people, but if something sucks, I tell people to their face. It’s my job to be honest. I know what I’m talking about, and I usually turn out to be right. That’s the culture I tried to create. We are brutally honest with each other, and anyone can tell me they think I am full of shit and I can tell them the same.

Now, you can certainly overdo it. For example, if you're telling people to SHUT THE FUCK UP on your developer mailing lists, it's possible you have gone too far.

But the vast majority of teams have the opposite problem: people filter their thoughts too much. The psychological and social incentives to do so are quite strong: we don't want to go against the team, or we're worried about giving offense, or we don't want to be "the bad guy." So team members might think individually, "We're driving off a cliff" or "That UI design is shit," but they either stay silent or the words that come out are so saccharine they mask the bitter truth below.

And that has a corrosive effect on culture. Those negative thoughts don't go away, and when team members repress doubts, resentment builds. Passive-aggressive behavior starts to predominate, politics brew, and problems linger on without being solved. So although people may hold their tongue intending to be nice, the result is that a more subtle kind of meanness takes root.

Actively fostering a culture of "no filter" is painful at first. But like exercising, the more you do it, the easier it gets. And it's better than the alternative—death.


How to break past filters on your team

So, where do you start?

You can’t just start telling your teammates they’re about to drive off a cliff. Or that they’re moths for bad ideas. If you do that, you’ll just end up with a bunch of defensive, insulted, or angry co-workers.

So I don't think most of us can create "no filter" behavior as a speaker alone. I think "no filter" has to start with us opening up as listeners.

In particular, teams can start to break down their own filters by asking themselves the hardest question.

In the first week of Y Combinator, Paul Graham told each startup in our batch to ask him "Are we failing?" It's a question that cuts to the bone, and most of us never asked because we were afraid of the answer. And therein lies the trick: we didn't really need Paul Graham to tell us where we were failing. We already knew, and we were simply deluding ourselves. What we were missing was simply the courage to ask ourselves the hardest question, and stop filtering our own answers.

Even if your startup is 'killing it,' there's always some area where it's failing, some muffled doubt that silently gnaws at people.

So if you want to break down filters on your team, start by asking : "Are we failing? How?"

And just listen.


Update: HN Discussion

Thanks to Christine Yen, Garry Tan, and Kalvin Wang for reading drafts of this... and having no filter at all.