Doing things that don't scale

Graham opened his July 2013 essay with that sentence (Do Things that Don’t Scale), and it has since become startup advice that almost every founder can recite. The essay itself is mostly a catalogue of unglamorous chores, and the chores carry its argument.

The first chore is finding users one at a time. Graham calls it the most common unscalable thing a founder has to do at the start, and he gives two reasons founders avoid it. Many are engineers who would rather stay home writing code than talk to strangers. And the early numbers look too small to bother with. His answer to the second is arithmetic. A company with 100 users that grows 10% a week needs only ten new ones next week, and at that pace it reaches about 14,000 users after a year and around 2 million after two. Ten percent is a high bar; in a 2012 essay on growth he put a good rate during Y Combinator at 5 to 7% a week.

Stripe is his clearest case. When someone agreed to try the payments service, Patrick and John Collison did not email a link. They asked for the person’s laptop and set the account up on the spot, a habit Y Combinator came to call the Collison installation. Wufoo, a maker of online forms, sent every new user a hand-written thank-you note for as long as it could keep up. Pebble’s founders assembled the first several hundred watches themselves. Graham’s own first company, Viaweb, spent its early months building online shops for merchants selling things like luggage and shirts, which he says taught it how the software felt to the people using it.

Underneath the anecdotes is a claim about fragility. A young company can die from one quiet month, and effort spent by hand on the first users keeps it alive until growth has momentum of its own. Graham also argues for a narrow start. Facebook began as a site for Harvard students only, a market of a few thousand people who joined in large numbers because the site felt built for them.

Where the advice runs out

Graham writes that he has never seen a startup led down a blind alley by trying too hard to please its first users. It skips a case worth naming. Hand-holding can conceal a product that nobody would use without it. When every customer needs a founder at their elbow to get started, the founder has learned something true and unwelcome: the onboarding is doing the work, and the software is not yet doing its share.

The test is what happens when the help stops. Users who stay after the founder steps back were won by the product. Users who drift off were won by the founder’s attention, which does not multiply. One of the techniques in the essay, using the software yourself on a hesitant customer’s behalf, makes the risk sharper, because a capable founder operating a tool can make almost any tool look useful.

It also matters what the effort is pointed at. The laptop installations put people inside a product that already worked and removed the step where they would have hesitated. The thank-you notes made a form builder feel personal without changing what it did. In both cases the manual work bought attention for something good. Manual work that stands in for a missing feature is another matter, and it is best read as a list of features to build.

Near the end of the essay Graham suggests treating a startup idea as a pair: what the company will build, plus the laborious things it will do by hand to get going. Written that way, the second half becomes a plan with an end. Each manual task is a guess about what customers need, and the guess is settled once the product can do that task as well as the founder did.