At Kinfolk, we regularly feature articles from people around the world whose perspectives we believe are important and valuable. Our aim is to help demystify the process of building enduring technology businesses for African founders and leaders.
In this article, renowned tech leader and visionary, Paul Graham, emphasizes on startups doing things that are unscalably laborious.
One of the most common types of advice we give at Y Combinator is to do things that don't scale. Many would-be founders believe that startups either take off or don't. You build something, make it available, and if you've made a better mousetrap, people beat a path to your door as promised. Or they don't, in which case the market must not exist.
Startups take off because the founders make them take off. There may be a handful that just grew by themselves, but usually, it takes some push to get them going. A good metaphor would be the cranks that car engines had before they got electric starters. Once the engine was going, it would keep going, but there was a separate and laborious process to get it going.
Recruit
The most common and unscalable thing founders have to do at the start is manually recruit users. Nearly all startups have to. You can't wait for users to come to you. You have to go out and get them.
Stripe is one of the most successful startups we've funded, and the problem they solved was an urgent one. If anyone could have sat back and waited for users, it was Stripe. But they're famous within YC for aggressive early user acquisition.
Startups building things for other startups have a big pool of potential users in the other companies we've funded, and none took better advantage of it than Stripe. At YC, we use the term "Collison installation" for their invented technique. More diffident founders ask, "Will you try our beta?" If the answer is yes, they say, "Great, we'll send you a link." But the Collison brothers weren't going to wait. When anyone agreed to try Stripe, they'd say, "Right then, give me your laptop," and set them up on the spot.
There are two reasons founders resist going out and recruiting users individually. One is a combination of shyness and laziness. They'd rather sit at home and write code than go out and talk to strangers and probably be rejected by most of them. But for a startup to succeed, at least one founder (usually the CEO) will have to spend a lot of time on sales and marketing.
The other reason founders ignore this path is that the absolute numbers initially seem small. They think this isn't how the big, famous startups started. The mistake they make is to underestimate the power of compound growth. We encourage every startup to measure its progress by its weekly growth rate. If you have 100 users, you need to get ten more next week to grow 10% weekly. And while 110 may not seem much better than 100, if you keep growing at 10% a week, you'll be surprised at how big the numbers get. After a year, you'll have 14,000 users; after two years, you'll have 2 million.
Fragile
That initial fragility was not a unique feature of Airbnb. Almost all startups are fragile initially. And that's one of the biggest things inexperienced founders and investors (reporters and know-it-alls on forums) get wrong about them. They unconsciously judge larval startups by the standards of established ones. They're like someone looking at a newborn baby and concluding, "there's no way this tiny creature could ever accomplish anything."
It's harmless if reporters and know-it-alls dismiss your startup. They always need to correct things. It's even ok if investors ignore your startup; they'll change their minds when they see growth. The significant danger is that you'll dismiss your startup yourself. I've seen it happen. I often have to encourage founders who need to see the full potential of what they're building. Even Bill Gates made that mistake. He returned to Harvard for the fall semester after starting Microsoft. He didn't stay long, but he wouldn't have returned if he'd realized Microsoft would be even a fraction of the size it turned out to be.
The question about an early-stage startup is not, "Is this company taking over the world?" But "How big could this company get if the founders did the right things?" And doing the right things often seems both laborious and inconsequential at the time. Microsoft couldn't have seemed very impressive when it was just a couple of guys in Albuquerque writing Basic interpreters for a market of a few thousand hobbyists (as they were then called). Still, in retrospect, that was the optimal path to dominating microcomputer software. And I know Brian Chesky and Joe Gebbia didn't feel like they were en route to the big time as they were taking "professional" photos of their first hosts' apartments. They were trying to survive. But in retrospect, that was the optimal path to dominating a big market.
Delight
You should take extraordinary measures not just to acquire users but also to make them happy. For as long as they could (which turned out to be surprisingly long), Wufoo sent each new user a handwritten thank-you note. Your first users should feel that signing up with you was one of the best choices they ever made. And it would help if you were racking your brains to find new ways to delight them.
Why do we have to teach startups this? Why is it counterintuitive for founders? There are three reasons, I think.
One is that many startup founders get trained as engineers, and customer service is not part of the training of engineers. You're supposed to build robust and elegant things, not be slavishly attentive to individual users like some salesperson. Ironically, engineering is traditionally averse to handholding because its traditions date from when engineers were less powerful — when they were only in charge of their narrow domain of building things rather than running the show. You can be ornery when you're Scotty, but not when you're Kirk.
Another reason founders need to focus more on individual customers is because they worry it won't scale. But when founders of larval startups worry about this, I point out that they have nothing to lose in their current state. If they go out of their way to make existing users super happy, they'll have too many to do so much in one day. That would be a significant problem to have. See if you can make it happen. And incidentally, when it does, you'll find that delighting customers scales better than you expected, partly because you can usually find ways to make anything rise more than you would have predicted and somewhat because delighting customers will have permeated your culture by then.
Experience
I was thinking of a phrase to convey how extreme your attention to users should be, and I realized Steve Jobs had already done it: insanely great. Steve wasn't just using "insanely" as a synonym for "very." He meant it more literally — that one should focus on the quality of execution to the degree that everyday life would be considered pathological.
All the most successful startups we've funded have, and that probably doesn't surprise would-be founders. What novice founders need to get is what insanely great translates to in a larval startup. When Steve Jobs started using that phrase, Apple was already an established company. He meant the Mac (and its documentation and even packaging — such is the nature of obsession) should be insanely well-designed and manufactured. That's not hard for engineers to grasp. It's just a more extreme version of designing a robust and elegant product.
What founders need help grasping (and Steve himself might have had a hard time learning) is what insanely great morphs into as you roll the time slider back to the first couple of months of a startup's life. It's not the product that should be insanely great, but the experience of being your user. The product is just one component of that. For a big company, it's necessarily the dominant one. But you can and should give users an insanely great experience with an early, incomplete, buggy product if you make up the difference with attentiveness.
Fire
Sometimes the right unscalable trick is to focus on a deliberately narrow market. It's like keeping a fire contained to get it hot before adding more logs.
That's what Facebook did. At first, it was just for Harvard students. In that form, it only had a potential market of a few thousand people, but because they felt it was really for them, a critical mass signed up. After Facebook stopped being for Harvard students, it remained for students at specific colleges for quite a while. When I interviewed Mark Zuckerberg at Startup School, he said that while it was a lot of work creating course lists for each school, doing that made students feel the site was their natural home.
Any startup described as a marketplace usually has to start in a subset of the market, but this can also work for other startups. It's always worth asking if there's a subset of the market in which you can get a critical mass of users quickly.
Most startups that use the contained fire strategy do it unconsciously. They build something for themselves and their friends, who happen to be the early adopters, and only realize later that they could offer it to a broader market. The strategy works just as well if you do it unconsciously. The most significant danger of not being consciously aware of this pattern is for those who naively discard part of it. E.g., if you don't build something for yourself and your friends, or even if you do but you come from the corporate world and your friends are not early adopters, you'll no longer have a perfect initial market handed to you on a platter.
Consult
Sometimes we advise founders of B2B startups to take over-engagement to an extreme and pick a single user and act as if they were consultants building something just for that user. The initial user serves as the form for your mould; keep tweaking till you fit their needs perfectly, and you'll usually find you've made something other users want too. Even if there aren't many of them, there are probably adjacent territories that have more. As long as you can find just one user who needs something and can act on that need, you've got a toehold in making something people want, and that's as much as any startup initially needs.
Consulting is the canonical example of work that doesn't scale. But (like other ways of bestowing one's favours liberally), it's safe to do it as long as you're not being paid. That's where companies cross the line. So long as you're a product company that's merely being extra attentive to a customer, they're very grateful even if you don't solve all their problems. But when they start paying you specifically for that attentiveness — when they start paying you by the hour — they expect you to do everything.
Manual
There's a more extreme variant where you don't just use your software but are your software. When you only have a small number of users, you can sometimes get away with doing things by hand that you plan to automate later. This lets you launch faster, and when you do finally automate yourself out of the loop, you'll know what to build because you'll have muscle memory from doing it yourself.
When manual components look to the user like software, this technique starts to have aspects of a practical joke. For example, the way Stripe delivered "instant" merchant accounts to its first users was that the founders manually signed them up for traditional merchant accounts behind the scenes.
Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. It would be frightening to solve users' problems in a way that wasn't yet automatic but less threatening than the far more common case of having something automated that doesn't solve anyone's problems.
Big
One initial tactic that usually doesn't work is the Big Launch. I occasionally meet founders who believe startups are projectiles rather than powered aircraft and that they'll make it big if launched with a sufficient initial velocity. They want to launch simultaneously in 8 different publications, with embargoes. And on a Tuesday, since they read somewhere, that's the optimum day to launch something.
It's easy to see how little launches matter. Think of some successful startups. How many of their launches do you remember? All you need from a launch is some initial core of users. How well you're doing a few months later will depend more on how happy you made those users than how many there were of them.
So why do founders think launches matter? A combination of solipsism and laziness. They believe what they're building is so great that everyone who hears about it will immediately sign up. Plus, it would be much less work if you could get users by broadcasting your existence rather than recruiting them one at a time. But even if what you're building is excellent, getting users will always be a gradual process—partly because great things are usually novel, but mainly because users have other things to think about.
Vector
The need to do something unscalably laborious to get started is so nearly universal that it might be a good idea to stop thinking of startup ideas as scalars. Instead, we should consider them as pairs of what you're going to build plus the unscalable thing(s) you'll do initially to get the company going.
It could be interesting to start viewing startup ideas this way because, now that there are two components, you can try to be imaginative about the second and the first. But in most cases, the second component will be what it usually is. To recruit users manually and give them an overwhelmingly good experience, the main benefit of treating startups as vectors will be to remind founders they need to work hard in two dimensions.
In the best case, both components of the vector contribute to your company's DNA: the unscalable things you have to do to get started are not merely a necessary evil but change the company permanently for the better. If you have to be aggressive about user acquisition when you're small, you'll probably still be aggressive when you're big. If you have to manufacture your hardware or use your software on users' behalf, you'll learn things you couldn't have learned otherwise. And most importantly, if you have to work hard to delight users when you only have a handful of them, you'll keep doing it when you have a lot.