logo
|
Blog
  • DelightRoom
  • Alarmy
  • DARO
  • DelightHub
  • KOEN
Careers
Culture

Do things that don't scale

This is a translation of Paul Graham's 'Do things that don't scale'. There may be some paraphrasing or mistranslations. Feedback is welcome. The bolded parts throughout are the ones I strongly resonate with.
DelightRoom's avatar
DelightRoom
Apr 18, 2017
Do things that don't scale
Contents
RecruitFragileDelightExperienceFireMerakiManualBigVector

2

This is a translation of Paul Graham's Do things that don't scale. There may be some paraphrased or mistranslated parts. Feedback is welcome if you spot any errors. The bolded parts throughout are the ones I strongly resonate with.

The most common advice we give at YC is to "do things that don't scale." A lot of would-be founders believe that startups take off on their own. They think if they just build something, launch it, and make a good product, people will flock to it as promised. If people don't come, they complain that "the market doesn't exist."

In reality, a startup's success is in the hands of its founders. Sure, a handful of startups grow on their own, but in most cases, it takes a kind of continuous manual grind to get the business rolling. A good analogy is the crank used in car engines before electric starters were invented. Once the engine starts, the crank keeps turning with it, but to get it going in the first place, you have to do some independent, laborious work.

Recruit

Stripe is one of the most successful startups we've funded, and they built a solution that clearly solved people's pain points. The problem their product tackled was so good that Stripe was exactly the kind of startup that could just sit back and wait for users to come. But Stripe didn't just sit around. They were famous at YC for their aggressive early user acquisition.

B2B startups had plenty of potential users within YC (the startups we've funded). And no one took advantage of that as well as Stripe did. At YC, people still use the term "Collison installation" for the method they used. Most timid founders just ask, "Want to try our service?" and send a link. But the Collison brothers didn't wait. When someone said they'd try Stripe, they'd say, "Give me your laptop" and install it right then and there.

There are two main reasons why founders don't go out and manually recruit users. The first is shyness and laziness. They'd rather sit at home and code than talk to strangers who might hate their service. But for a startup to succeed, at least one founder (usually the CEO) has to spend a lot of time on sales and marketing.

The other reason founders avoid manual recruiting is that the number of users they can bring in this way seems so small. They think big, famous startups could never have started like this. Their mistake is underestimating the power of compound growth. We encourage all startups to measure their growth rate weekly. If you have 100 users, you need to recruit 10 more next week to hit a 10% growth rate. 110 doesn't seem like much more than 100, but if you keep growing at 10% a week, you'll be shocked at how big that number gets. In a year, you'll have 14,000 users, and in two years, 2 million.

As you keep growing, there will come a time when you start bringing in huge numbers of users at once, and what you do will change a lot. Eventually, your growth rate will slow down compared to those early days.

But if the market exists, you can start by recruiting users manually and gradually transition to less hands-on methods.

Airbnb is a prime example of this. Getting a platform business rolling is extremely difficult, so you have to start with heroic measures. For Airbnb, those heroic measures involved going door-to-door in New York. Acquiring new users and helping existing ones improved their listings. When I think back to the Airbnb founders during my time at YC, I remember them always rolling suitcases into dinner because they had just flown in from somewhere.

Fragile

Today, Airbnb looks like an unstoppable juggernaut, but in the beginning, it was so fragile that 30 days of hitting the pavement to meet users could make the difference between success and failure.

This initial fragility isn't unique to Airbnb. Almost all startups are like this at first. And this is one of the biggest things inexperienced founders and investors (along with journalists and know-it-alls) misunderstand. They unconsciously judge early-stage startups by the standards of established companies. It's like looking at a newborn baby and concluding, "There's no way this tiny baby could ever achieve anything."

If journalists or know-it-alls dismiss your startup, it doesn't really matter because they're always wrong anyway. Even if investors see it that way, it's fine. They'll change their minds once they see the startup growing. The biggest danger is if you yourself think your startup is worthless. I've often seen founders fail to see the full potential of what they're building, and I've had to encourage them. Even Bill Gates made this mistake. He went back to Harvard for the fall semester while working on Microsoft. He didn't stay long, of course, but if he had known Microsoft would get as big as it is now, he never would have gone back.

The question to ask about an early startup isn't "Is this company going to take over the world?" but "How big could this get if the founders do the right things?" And the right things to do early on can look exhausting and trivial. You couldn't imagine Microsoft becoming this incredible company when a few friends were just writing a BASIC interpreter for a few thousand hobbyists. When Brian Chesky and Joe Gebbia were taking the first photos of their hosts' apartments, they didn't feel like they were on the fast track to success either. They were just fighting to survive. But looking back, for Airbnb, just like Microsoft, those actions were the optimal path to dominating a massive market.

When you're trying to manually acquire users, how do you find them? If you built something to solve your own problem, it's easy—just find peers who are like you. If not, you'll have to put in more effort to hustle in places where potential users hang out. A common trick is to launch publicly and see what kind of people use it most enthusiastically. For example, Ben Silbermann noticed that early Pinterest users were really into design, so he went to design conferences to recruit bloggers, and it worked beautifully.

Delight

You have to take extraordinary measures not just to acquire users, but to delight them. For as long as they could (which was surprisingly long), Wufoo sent handwritten thank-you notes to their new users. You need to make your early users feel like signing up for your service was the best decision they ever made. Ultimately, you should constantly rack your brains figuring out how to delight them.

Why do we even have to teach this to startups? Why isn't it intuitive to founders? I think there are three reasons.

First, a lot of startup founders are trained as engineers, and customer service isn't part of engineering training. They think their job is to build robust, elegant services, not to grovel for users' attention like a salesperson. Ironically, part of the reason engineering is traditionally so far removed from interpersonal skills is a hangover from the days when engineers just built their own little piece of the puzzle instead of seeing the big picture (when they had less influence). You can afford to be a jerk when you're Scotty (the engineer working on a specific part), but not when you're Kirk (the CEO looking at the big picture).

Another reason founders don't focus enough on customers is the fear that it won't scale. When early-stage startups worry about this, I point out that they have nothing to lose right now anyway. If you put immense effort into making your existing users happy, one day it might become so overwhelming that you have to stop. That's a great problem to have. If you can make it happen, do it (it'll be hard even if you want to). If you do, you'll find that delighting customers through manual labor actually scales better than you thought.

Because as you do it, you'll discover ways to scale it better than you originally anticipated, and by then, delighting users will have already permeated your company culture.

I have never once seen a startup hit a dead end because they tried too hard to satisfy their early users. The biggest reason founders don't realize how much they can listen to their users is that they've never experienced it themselves. Their standard for customer service is set by the big companies they interacted with as customers. Tim Cook doesn't send you a handwritten note when you buy a MacBook. He can't, obviously. But you can. That's the superpower of being a small company. You can provide a level of service that huge corporations simply can't.

Once you realize that existing conventions aren't the upper limit of user experience, you can start imagining how much happier you could make them. This is an incredibly exciting prospect.

Experience

I've tried to convey just how much attention founders need to lavish on their users. This is something Steve Jobs did insanely well. Jobs didn't view doing something "insanely well" as the same thing as doing it "very well." Doing it insanely well means literally obsessing over it to a pathological degree every single day.

Being pathologically obsessed with one thing is a trait shared by most of the successful startups we've funded, though clueless would-be founders probably just brush it off as a cliché. What novice founders don't understand is the role that "doing things insanely well" plays in an early-stage company. When Jobs started talking about this, Apple was already an established company. He meant that not just the Mac, but everything around it—the packaging and the documentation—had to be designed and manufactured infinitely better. That's not hard for engineers to grasp. It just meant designing a much more robust and superior version of the product.

Founders struggle to understand what "doing it insanely well" translates to in the early days of a startup (and Jobs probably would have, too). It doesn't mean the product itself has to be insanely good; it means the experience of being your user has to be insanely good. The product is just one component of that (though naturally, in a large company, it becomes the biggest piece). If you can differentiate yourself by how much you care about your users, you can (and must) deliver an incredible user experience even with an incomplete, buggy early product.

Can you? Probably. But should you? Yes. Over-engaging with early users isn't just a hack you can use to grow. For the most successful startups, building extreme relationships with users is a vital part of the feedback loop that makes the product great.

Building a better product is something you can do concurrently. Even if you're building something you need and following the exact playbook of the most successful startups, your first version is not going to be good. Except in domains where mistakes are catastrophic, it's usually better not to aim for perfection right out of the gate.

Especially in software, it's best to get the product out in front of users as fast as possible—as long as it's somewhat usable—and see how they use it. Perfectionism is just an excuse for procrastination. Even if you built it for yourself, the early version is always wrong, so launch fast and get user feedback.

The feedback you get from engaging directly with your earliest users is the best you'll ever get. When you eventually have so many users that you're forced to look at them in focus groups, you'll find yourself wishing you could still just go to their homes or offices and watch them use your product, just like you did when you only had a handful of users.

Fire

One of the best unscalable tricks is deliberately targeting a narrow market. It's like building a fire: before you throw on the big logs, you focus the heat on a small area to get the embers glowing.

This is exactly what Facebook did. At first, Facebook was just for Harvard students. In that form, their total addressable market was only a few thousand people. But almost all of those potential users felt the need for it, and a huge number of them signed up. Even after Facebook expanded beyond Harvard, it remained a service strictly for specific university students for quite a while. When I interviewed Mark Zuckerberg at Startup School, he said it was a ton of work to create course lists for every single school, but doing it made Facebook feel like a comfortable home for the users.

Any startup aiming for a big market should usually start by targeting a small one. This strategy works not just for those chasing massive markets, but for any startup. It is always worth looking to see if there's a subset of your target market where you can quickly gather a dense pocket of users.

Most startups that use this narrow-market strategy do so by accident. They build a product for themselves and their early-adopter friends, and only later organically realize they could expand it into a broader market. The strategy works perfectly even when it's unintentional. The biggest danger of stumbling into it, though, is that you might casually discard a segment of the market. For instance, if you don't build a product for yourself and your friends, you're essentially throwing away the perfect, freely available initial market. (Of course, if you're only surrounded by corporate lifers and lack early-adopter friends, you might not have that market to begin with.)

For B2B startups, the best early adopters are usually other startups. They haven't been around long enough to have locked-in vendor choices, and they are inherently open to new things. Plus, when the startups (using your product) succeed, they grow fast, and you get to ride their coattails. This is an unexpected perk of the YC model (and one of the things that makes YC grow so much): B2B startups in YC instantly gain a captive market of hundreds of other startups.

Meraki

For hardware startups, there's a specific variant of doing things that don't scale, which we call "Pulling a Meraki." Although we didn't fund Meraki, the founders were graduate students of Robert Morris, so we know their history. They started their company by doing something truly unscalable: assembling their routers entirely by hand.

Hardware startups face an obstacle that software startups don't. The minimum cost of doing a factory run is usually a few hundred thousand dollars. This puts them in a catch-22: without a product, they can't generate growth, but to make the product, they need money. When hardware startups pitch investors for money, they have to be convincing enough to prove they can overcome this hurdle. Crowdfunding (or, more accurately, pre-orders) has been a massive help to these companies. Even so, I still advise startups to "pull a Meraki" in the early days if they can. Pebble did exactly that. They assembled the first few hundred units themselves. If Pebble hadn't pushed through that phase, they never would have sold 10 million dollars' worth of watches on Kickstarter.

Just like lavishing extreme attention on early users, building your own products by hand is an invaluable experience for a hardware startup. You can tweak the design far faster than you could if you were relying on a factory, and you'll learn all sorts of things you never would have known otherwise.

Eric Migicovsky from Pebble said one of the things he learned was how crucial it is to source good screws. Who would have known?

We often advise founders of B2B startups to take user engagement to an extreme: pick a single user and act as if you're building a product just for them, treating them like a consultant for your product.

Your early user acts as the mold for your product. If you keep tweaking it to perfectly fit their needs, you'll eventually find that you've built something other users want, too.

Even if there aren't many of them, there's probably an adjacent area with way more users. As long as you find something that one user truly needs and you fulfill that need, you'll have achieved what most startups desperately want in the beginning: "making something people want."

Consulting is the ultimate example of doing things that don't scale. But it's completely safe as long as you're not getting paid for it (treating it as freely giving favors). The line is crossed when you start charging. As long as your company is a product-driven one that ostensibly doesn't coddle users, they'll be extremely grateful if you solve even a fraction of their problems instead of all of them. But the moment they pay you for that extra attention, they'll expect you to fix everything.

Another consulting-like technique for winning over lukewarm early users is to use the product yourself on their behalf. We did this at Viaweb. When we approached merchants and asked if they wanted to use our software to build online stores, some said no, but others told us to just build the site for them. We were willing to do anything to get users, so we did. At the time, the product felt incredibly lame. Instead of forging massive strategic e-commerce partnerships, we were trying to sell pens, bags, and men's shirts. But looking back, it was exactly what we needed to do. Because it taught us exactly what merchants would feel when they used our product. The feedback loop was basically instantaneous. In the middle of building a site for a merchant, we'd realize we were missing a feature we needed, spend a few hours building it, and then go back to building the site.

Manual

A more extreme variant is not just using your software, but actually being the software. When you only have a handful of users, you can run everything manually and automate it later. This lets you launch much faster, and when you finally have to break free from the manual grind and automate, you'll have internalized the experience so well that you'll know exactly what you need to build.

It makes no sense to try and solve manual, grueling tasks with software from day one. For example, to give their early users instant merchant accounts, the founders of Stripe manually provisioned the accounts and signed people up behind the scenes.

Some startups can do everything manually in the beginning. If you can find someone with a problem that must be solved and solve it manually, do it for as long as you can, and then gradually automate the bottlenecks. It might feel a bit scary solving users' problems in an unautomated way, but it's infinitely better than having a fully automated system that solves absolutely no one's problem (which is far more common).

Big

I should probably mention one early strategy that almost never works: the big launch. I occasionally meet founders who seem to believe their startup is a missile rather than a powered aircraft. They think they can only succeed if they fully prepare and launch with a massive bang. They set up embargoes and try to get 8 different publications to break the news simultaneously on exactly a Tuesday (since they read somewhere that Tuesday is the best day to release).

It's easy to see how little launches matter. Think of some successful startups. How many of their launches do you actually remember? All you need at launch is a small core of early users. How well you're doing a few months down the line will depend much more on how happy you made those users than on how many you had on day one.

So why do founders care so much about launches? It's a mix of ego and laziness. They think what they've built is so amazing that people will flock to it the second they hear about it. They also think it's way easier to just broadcast their product into the void than it is to recruit users one by one. But no matter how good your product is, acquiring users is always a gradual process. That's because great products are usually novel, and users generally already have existing alternatives they can rely on.

Partnerships usually don't work, either. In general, partnerships are ineffective for startups, and they are especially useless as a way to kickstart growth. Thinking that a partnership with a huge company will result in a massive breakthrough is a classic mistake made by inexperienced founders. Six months later, they all say the exact same thing: "That was way more work than we expected, and we ended up with absolutely nothing to show for it!"

Just starting off with something great isn't enough. You have to pour extraordinary effort into the early days. Any strategy that omits the grind—whether it's a giant launch or a shiny corporate partnership to get users—is fundamentally suspect.

Vector

Because getting a startup off the ground generally requires doing unscalable, grueling work, you should stop thinking of a startup purely as a scalar value (the product). You need to make an effort to think of it as a vector consisting of two paired elements: not just the scalable part, but also the unscalable things you must do to get the company growing initially.

It can be pretty fascinating to start looking at what startups do as a pair of vectors. That's because the two elements actually exist as a pair, and you can exercise just as much creativity in the unscalable element as you can in the scalable one. But in most cases, founders only apply conventional thinking to the second element—the unscalable stuff (e.g., manually recruiting users and giving them an amazing experience). Treating your startup as a two-part vector, however, has the benefit of constantly reminding you that you have to work relentlessly hard on both fronts.

In the best-case scenarios, both elements of the vector contribute to the company's DNA. The unscalable things you have to do to get the business going aren't just a necessary evil; they permanently change the company for the better. If you have to be aggressive about user acquisition when you're tiny, you'll probably stay aggressive when you're huge. If you have to manufacture your own hardware by hand or become a user of your own software on behalf of your customers, you'll learn invaluable lessons you couldn't have picked up any other way. And most importantly, if you bust your ass to delight users when you only have a handful of them, you'll keep doing it when you have multitudes.

Share article
Contents
RecruitFragileDelightExperienceFireMerakiManualBigVector

Delightroom

RSS·Powered by Inblog