Y Combinator's Guide for Founders: Do the Hard Things That Are Right
TechFlow Selected TechFlow Selected
Y Combinator's Guide for Founders: Do the Hard Things That Are Right
Startup companies succeed because their founders make them succeed.
Navigating Web3 tides with focused insightsWritten by: Paul Graham
Compiled by: TechFlow
At Y Combinator, one of the most frequent pieces of advice we give founders is to do things that don't scale. (Do Things That Don't Scale, referring in the text to efforts that seem labor-intensive and unrewarding but are essential for founders to personally undertake—tasks that cannot be systematized or scaled initially)
Many aspiring founders believe a startup either succeeds or fails outright. You build something, offer it to people, and if you solve a real need better than others, users will naturally come. If not, then there’s no market.
In reality, startups succeed because founders make them succeed. There may be companies that grow entirely on their own, but usually some deliberate push is needed to get them started. A good analogy is the hand-crank starters used in car engines before electric starters were invented. Once the engine starts, it keeps running—but starting it requires a separate, time-consuming effort.
Recruiting Users
One of the most common unscalable things founders do early on is manually recruiting users. Almost every startup needs to do this. You can’t wait for users to come to you—you must go out and get them.
Stripe, one of the most successful startups we’ve funded, solved an urgent problem. If any company could afford to sit back and wait for users, it would be Stripe. Yet in fact, they became famous within Y Combinator for their aggressive early user acquisition.
For startups building products for other startups, there was a vast pool of potential users among the other companies we funded—and Stripe excelled at tapping into it. At Y Combinator, we coined the term “Collison installation” to describe the technique they invented. More cautious founders might ask, “Would you like to try our beta?” And if the answer was yes, they’d say, “Great, we’ll send you a link.” But the Collison brothers didn’t wait. Whenever someone agreed to try Stripe, they’d say, “Okay, hand me your laptop,” and install it right then and there.
Founders resist personally recruiting users for two reasons. One is a combination of shyness and laziness. They’d rather stay home writing code than go out and talk to strangers—most of whom will likely reject them. But to make a startup succeed, at least one founder (usually the CEO) must spend substantial time on sales and marketing.
The second reason founders overlook this approach is that the absolute numbers seem tiny at first. They think this couldn’t possibly be how big companies start, underestimating the power of compounding growth. We encourage every startup to measure progress by weekly growth rate. If you have 100 users, you need to add 10 more next week to maintain 10% weekly growth. While 110 doesn’t seem much better than 100, if you keep growing at 10% per week, the numbers become astonishing. After a year, you’ll have 14,000 users.
When you’re acquiring 1,000 users at a time, you’ll do different things, and growth will eventually slow. But if a market exists, you can usually start by manually recruiting users and gradually shift to less manual methods.
Airbnb is a classic example of this tactic. Markets are hard to grow, so expect to take extreme measures at first. In Airbnb’s case, they had to go door-to-door in New York recruiting new users and helping existing hosts improve their listings. When I think of Airbnb during YC, I always picture them lugging suitcases, because whenever they came to Tuesday dinners, they’d just flown back from somewhere.
Fragility
Today, Airbnb seems unstoppable, but in its early days it was so fragile that about 30 days of hands-on fieldwork and face-to-face user contact made the difference between success and failure.
This initial fragility isn’t unique to Airbnb—nearly all startups are fragile at first. It’s also one of the biggest misunderstandings inexperienced founders, investors, forum pundits, and commentators have about startups. They inadvertently judge early-stage startups by the standards of established companies. It’s like looking at a newborn baby and concluding, “This little creature can’t achieve anything significant.”
If journalists ignore your startup, it doesn’t matter much—they’re often wrong anyway. If investors ignore it, that’s fine too; they’ll change their minds when they see growth. The greatest danger is that you yourself ignore your startup. I’ve seen this happen. I often have to encourage founders who don’t yet grasp the full potential of what they’re building. Even Bill Gates made this mistake. After founding Microsoft, he went back to Harvard in the fall. He didn’t stay long, but if he’d realized how big Microsoft would become, he never would have gone back at all.
The right question to ask about an early startup isn’t “Is this company taking over the world?” but “How big could this company become if the founders do the right things?” And the right things often seem both laborious and insignificant at the time. When Microsoft was just a few people in Albuquerque writing a BASIC interpreter for a market of a few thousand hobbyists (as they were then called), it didn’t look impressive. But in retrospect, it was the best path to dominating microcomputer software. I know Brian Chesky and Joe Gebbia didn’t feel like they were on the road to greatness when they were taking “professional” photos of their first hosts’ apartments. They were just trying to survive. But in retrospect, that was also the best way to dominate a large market.
What’s the method for finding ways to manually recruit users? If you’ve built something to solve your own problem, you just need to find peers with similar problems—which is usually straightforward. Otherwise, you need to target your efforts more deliberately to find the most promising user segment. The typical approach is to launch relatively broadly to get an initial set of users, observe which group seems most interested, and then find more users like them. For example, Ben Silbermann noticed that Pinterest’s earliest users were interested in design, so he attended a design blog conference to recruit users—and it worked well.
Delighting Users
You not only need to recruit users—you need to delight them. 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 decisions they’ve ever made. And you should constantly invent new ways to delight them.
Why do we even need to teach founders this? Why does it feel counterintuitive? I think there are three reasons.
First, many founders are trained as engineers, and customer service isn’t part of engineering education. You’re supposed to build robust, elegant systems—not act like a salesman obsessively tending to individual users. Ironically, engineers traditionally dislike excessive user attention because their profession originated in eras when engineers had limited power—responsible only for narrow technical tasks, not running entire businesses.
Another reason founders don’t focus enough on individual customers is fear that the approach won’t scale. But when I hear founders worry about this, I point out that at their current stage, they have nothing to lose. Maybe if they go all-out to make existing users extremely happy, someday they’ll have so many users they can’t do this for everyone. That would be a great problem. See if you can make it happen. And by the way, when it does happen, you’ll find you can scale user satisfaction better than expected. Partly because you can usually find ways to scale things further than anticipated, and partly because the culture of delighting users will already be embedded in your company.
I’ve never seen a startup die because it tried too hard to delight early users.
But perhaps the biggest obstacle preventing founders from realizing how high they can aim in user attention is that they’ve never experienced it themselves. Their standard for customer service is set by the large companies they interact with as customers—companies that are mostly massive. Cook won’t send you a handwritten note after you buy a laptop. He can’t. But you can. This is an advantage of being small: you can offer a level of service large companies can’t.
Once you realize existing norms aren’t the ceiling for user experience, it becomes far more interesting—and pleasantly so—to think creatively about how to pamper your users.
Experience First
I once tried to come up with a phrase for how intensely focused you should be on users, and realized Jobs had already done it. Steve didn’t just use “insanely” as a synonym for “very.” He meant it more literally: You should care about execution quality to a degree that would seem pathological in everyday life.
All our most successful startups embody this, though it may not surprise aspiring founders. What new founders don’t understand is how “insanely great” changes in the first months of a startup. Insane greatness shouldn’t be applied to the product—it should be applied to the experience of becoming your user. The product is just one component. For large companies, the product must dominate. But if you compensate for an early, incomplete, flawed product with an insanely good user experience, you can and should do exactly that.
Is it possible? Maybe. Should you do it? Yes. Over-engaging with early users isn’t just a tactic to allow growth—it’s a necessary part of the feedback loop that makes the product better. Even if, like most successful startups, you start by building something you yourself need, the first version is rarely perfect. Unless you’re in a domain where mistakes are severely punished, the best approach is usually to get the product in front of users as quickly as possible, as long as it has some utility, and then observe how they use it. Perfectionism is often just an excuse for procrastination, and anyway, your initial model of users is always inaccurate—even if you’re one of them.
The feedback you get from direct interaction with your earliest users is the best feedback you’ll ever get. When you grow so large that you have to rely on focus groups, you’ll wish you could still visit users’ homes and offices and watch them use your product, as you did when you had only a few.
Focus Relentlessly
Sometimes, the right unscalable tactic is to focus on a narrow market. It’s like concentrating a fire before adding more wood—making it burn very hot first.
That’s what Facebook did. Initially, it targeted only Harvard students. In that form, it had a potential market of just a few thousand people, but because users felt it was truly made for them, a critical mass signed up. Even after Facebook expanded beyond Harvard, it remained confined to students at specific colleges for quite some time. When I interviewed Zuckerberg at Startup School, he said that although creating course lists for each school was labor-intensive, it made students feel the site was their natural home.
Any startup that can be described as serving a market usually needs to start with a subset of that market—but this applies to others too. It’s always worth asking whether there’s a sub-market where you can quickly acquire enough users.
Most startups using this “concentrated firepower” strategy do so unconsciously. They build something for themselves and friends—who happen to be early adopters—and only later realize they can offer it to a broader market. If you do it unconsciously, the strategy works just as well. The biggest danger for those who adopt this pattern naively is often that they unwittingly discard part of it. For example, if you’re not building for yourself and friends—or even if you are, but you come from the corporate world and your friends aren’t early adopters—then you no longer have a perfect initial market to launch from.
Across industries, the best early adopters are often other startups. They’re naturally more willing to try new things because they’re just getting started and haven’t locked in all their choices yet. Plus, when they succeed, they grow fast—and you grow with them. One of the unforeseen advantages of the YC model is that B2B startups instantly have hundreds of other startups as a ready market.
Meraki
For hardware startups, there’s a variation called “pulling a Meraki.” Though we didn’t fund Meraki, its founders were Robert Morris’s grad students, so we know their story. They started by assembling routers themselves—a truly unscalable task.
("Meraki" refers to the name of a hardware startup. The article describes how, in its early days, the company took an extremely hands-on, non-scalable approach—personally assembling their routers. This practice is known as "pulling a Meraki," used to describe a strategy in early-stage startups of personally doing certain tasks to drive growth)
Hardware startups face obstacles that software startups don’t. Minimum order quantities from factories often require hundreds of thousands of dollars. This creates a catch-22: without a product, you can’t achieve the growth needed to raise funds to manufacture it. Hardware startups relying on investor funding must be especially persuasive to overcome this. Crowdfunding has solved many of these issues. Still, I recommend that startups, if possible, begin with a “pulling a Meraki” approach. That’s what Pebble did. Pebble’s founders assembled the first few hundred watches themselves. If they hadn’t gone through that phase, they likely wouldn’t have succeeded when they sold $10 million worth of watches on Kickstarter.
Like over-engaging with early customers, building things yourself is valuable for hardware startups. When you’re your own factory, you can iterate faster on designs and learn things you wouldn’t otherwise. Pebble’s Eric Migicovsky said one thing he learned was “how valuable it is to find good screws.” Who knew?
Be the Customer’s Advisor
Sometimes, we advise B2B startups to take an extreme approach: pick a single user and build something for them as if you were their consultant. The initial user shapes your model; by iterating until you fully satisfy them, you often end up building something others want too. Even if such users are rare, adjacent niches may exist. As long as you find one user who genuinely needs something and can act on it, you’ve secured a foothold—enough for any startup to begin.
Consulting is a classic example of Do Things That Don’t Scale. But (like other forms of unpaid help) it’s safe as long as you’re not being paid. The problem arises once a company starts paying for your special attention—once they pay by the hour, they’ll expect you to do everything for them.
Another consulting-like tactic to recruit initially reluctant users is to use your software on their behalf. We did this at Viaweb. When we approached merchants about using our software to create online stores, some said no—but allowed us to build one for them. Since we were willing to do anything to get users, we did. At the time, we felt embarrassed. Instead of grand strategic e-commerce partnerships, we were selling luggage, pens, and men’s shirts. But in retrospect, it was absolutely the right move—it taught us exactly how merchants would experience using our software. Sometimes the feedback loop was nearly instantaneous: while building a merchant’s site, I’d realize I needed a feature we didn’t have, so I’d spend a few hours implementing it, then continue building.
Manual Operations
Here’s an even more extreme variant: you don’t just use your software—you become the software. When you have only a few users, you can sometimes manually perform tasks you plan to automate later. This lets you launch faster, and when you finally automate yourself out of the loop, you’ll know exactly what to build because you’ve done it yourself and have firsthand experience.
This technique starts to feel slightly mischievous when the manual component appears to users as software. For example, Stripe provided “instant” merchant accounts to its earliest users by having founders manually sign them up for traditional merchant accounts behind the scenes.
Some startups may initially operate entirely manually. If you can find people with a problem you can solve manually, go ahead and do it—keep doing it as long as possible, then gradually automate the bottlenecks. Solving user problems in a non-automated way may feel scary, but it’s far less risky than having an automated system that doesn’t solve anyone’s problem.
Big Launches
It’s important to recognize one initial strategy that usually doesn’t work: the big launch. Occasionally I meet founders who seem to believe startups are projectiles rather than powered aircraft—only able to succeed if launched with sufficient initial velocity. They hope to simultaneously debut across eight different publications, all under embargo. Of course, it’s best to launch on a Tuesday, since they read somewhere that’s the optimal day to launch something.
It’s easy to see how little launches matter. Think of some successful startups. How many launches do you remember them having? From a launch, you only need a small core of initial users. What matters months later is far more dependent on how happy you made those users, not just how many you had.
So why do founders think launches matter? It’s a mix of narcissism and laziness. They believe what they’ve built is so amazing that anyone who hears about it will immediately sign up. And if you could just gain users by publicizing your existence, rather than recruiting them one by one, it would save enormous effort. But even if you build something truly great, acquiring users is always a gradual process—partly because great things are often novel, but mostly because users have other things on their minds.
Partnerships usually don’t work either. They rarely help ordinary startups, especially as a way to kickstart growth. A common mistake among inexperienced founders is believing a partnership with a big company will be their breakthrough. Six months later, they all say the same thing: it required far more work than expected, and we ended up getting almost nothing.
It’s not enough to simply do some unscalable labor at the start. You must put in extraordinary effort initially. Any strategy that skips this effort—whether hoping for a big launch to bring users or expecting a major partnership to drive growth—is suspect.
Combining Vision with Execution
Starting a startup usually requires doing some initial, labor-intensive, non-scalable work—it’s almost a universal phenomenon. So, perhaps it’s better to stop thinking of startup ideas as single ideas. Instead, we can treat them as combinations of two parts: what you want to build, plus the initially unscalable things you must do to get the company going.
Thinking about startup ideas this way can be interesting, because now with two components, you can exercise creativity on both the second part as well as the first. But in most cases, the second part will be what it usually is—manually recruiting users and giving them an outstanding experience—and the main benefit of viewing startups as two-part structures is reminding founders they need to work hard on both fronts.
In the best-case scenario, both parts contribute to your company’s DNA: the unscalable things you had to do at the start aren’t just a necessary evil—they permanently benefit the company. If you had to actively recruit users when the company was small, you may retain that proactiveness as it grows. If you had to build your own hardware or use your software on behalf of users, you’ll learn things you couldn’t have otherwise. Most importantly, if you had to work hard to delight your few early users, you’ll likely continue doing so when you have many.
Recommended reading: "AllianceDAO: Does Doing 'Unscalable' Things Work in Crypto?"
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@paulg
