Y Combinator Startup Podcast - Startup Experts Discuss Doing Things That Don't Scale | Office Hours

Episode Date: November 16, 2024

A little over ten years ago Paul Graham published the essay "Do Things That Don't Scale." At the time, it was highly controversial advice that spoke to the drastically different needs of an early startup versus the needs of a much larger, more established company. YC Partners discuss PG's essay, its influence on Silicon Valley, and some prime examples of YC founders that embraced the mantra "Do Things That Don't Scale." Read Paul Graham's essay here: http://paulgraham.com/ds.html

There's nothing like that founder FaceTime in the early days, right? And that's a great example of something that doesn't scale, but that's so important in recruiting customers, recruiting employees. Anything you can do to optimize for these learning is good to do. And doing things that don't scale, I think. The main goal is that. How much can I learn? In 2013, Paul Graham, the founder of White Combinator, wrote an essay entitled

Do Things that Don't Scale. And this essay transformed the culture of Silicon Valley. PG said not to worry about the theoretical problems of scaling and fix the thing in front of you right now. Do everything you possibly can to get early customers and delight them, even if it meant doing things in a manual and one-off way. The essay created a playbook for startups who needed to get from zero to one. And many of them made it, and they're making it right now. So today we'll hear from the YC group partners about the best examples of companies that did unscalable things to get off the ground.

Let's get started. So I think to start with this set us up, what I remember from being a founder in the early 2000s is that investors and people in general at big tech companies were obsessed with this word scalability. Because the issue with the internet and the issue with websites was that people created these early web servers. processors were pretty slow. The size of bandwidth is pretty slow. And so if you wanted to build an internet company, and if it only could serve 10,000 or 100,000 people, and the site crashed, it didn't scale. And it was actually pretty hard to scale. It was a real problem. This meant in addition to technically scaling, which in this case just means the servers can handle the load, it also meant business models had to scale. A scalable business model would mean a business model that does not top out at a small amount of money. It's a business model that

could go all the way into making billions of dollars. I actually think Google is indirectly responsible for basically warping the minds of a whole generation of founders and investors and creating the problem that Paul Graham had to solve with this essay. Which is because Google became so famous for this because they did so much content marketing, everybody wanted to emulate Google. And so everybody from day one wanted to do the same thing and to be thinking about how they were going to build something that was as scalable as Google.

And you wouldn't be able to raise a dollar. from investors if you do not have a scalable solution. Period. Full stop. And again, I'm not saying this is wrong, but this created the elephant in the room when you are a founder during that era. And I would argue to a lesser extent still to this day, was if you did not have good answers to how your product or solution or business model scaled, it was not considered

a venture capital fundable company. Paul Graham heard this problem because many Y Combinator companies were obsessed with this thinking of scalability. for all the reasons I just mentioned. And so he had to invert it and say, the opposite, ignore this. And he wrote this essay with this amazing title, Do Things That Don't Scale.

And this essay, I would argue it transformed the culture. Like it actually transformed, not overnight, but over the years that followed, it actually transformed Silicon Valley culture. And it became ingrained in the psyche of the current generation of founders. I agree. Because what he realized

was the biggest problem that most startups have is they can't get users and they're not making something people want, not that their architecture is not scalable enough. Think about how many startups build something, this beautiful thing that has like so much scalability. And no one wants it. It's like if you build it, they will come. It's the field of dream startup, right?

It's this beautiful thing and you hired a big team and it's like you got all the servers set up and you're ready to scale. You got a chief architect in place. Yeah. And like, no one cares. And everyone churns. It's game over. Yeah.

Right? And so this do things that don't scale. And at the time, it was such a contrarian title. I would say it's analogous to Mark Zuckerberg's Move Fast and Break Things. Do Things that Don't Scale. It sounded at the time like somebody was crazy. It was so contrarian. Especially coming from an investor.

Yeah. Which is why it had a real impact. And so that is the context. To me, the point of Paul Graham's essay and that we talk about all the time in office hours is worry about the thing that is your biggest problem at any one point of time and try to slay that dragon first

before you worry about later dragons you have to slay. And for most startups, it's just getting zero to one. It's getting a first customer. It's building the first product. And to just get from zero to one, you don't need to worry about scale. So don't.

Yep. So don't. And then if you're lucky enough that people want your product enough, that you have the luxury of worrying about scalability, great. Okay, then you should totally scale. Again, like, he's not saying never scale ever for any reason. That is not what the advice is. It's just worry about it when it's time.

As Dalton and Jared pointed out, do things that don't scale really encouraged founders to focus less on the future problem of scaling and more. more on solving the hair-on-fire problems of their first customers. It was about focusing on what really matters in the moment. Next, Harge and Pete talk about the Airbnb founders and what they did to inspire Paul Graham's essay. So what do we mean, Harge, when we say do things that don't scale? What are those actual things?

I feel like a lot of the spirit behind PG's essay here was to get startups to be urgent, feel urgency and be like, hey, like, you don't have time to spend six months writing the perfect piece of software before you go and get a real customer. Yes. And I feel like what inspired him with this was the Airbnb guys. They'd been working on that idea for a while, had no users, and they needed to get the flywheel turning. And so one of the pieces of advice he gave them was, hey, look, like, you need just like really

high quality listings. Like, the most important part of a listing is a photo. And so if you can't get people to upload high quality photos, just go and take them yourself. and like have this catalog of really great places to stay with like professional quality photos. And so the Airbnb guys would go out and do that. And that was clearly something that did not scale. That's what got them that like flywheel turning early on. And if they had been like, oh, like we can't do that because like that's never going to scale,

they were totally missed out on that. Totally. It's like so much of that work is actually just like it can feel beneath you in a way. Like if you come in particular, I think the archetype here is like you come from like a really well-paid job at like Google or like Facebook. Yes. You're like used to having like reports and infrastructure and people do all this stuff. And then you come into a startup and it's like, okay, like, I've got to send the cold email.

I've got to like cold call. I've got to do all of this like, like, I'm going to like manage all of the admin stuff. I've got to get the company incorporate. Like no one else is going to do it. Yes. And one thing I've just noticed again is the best founders, no matter how smart they are, like they just like dive into that. I think you just got to have that mindset of like nothing.

is beneath me, the only thing I care about is like getting your product market fit, serving customers, getting users. And that will like send you in the right direction. As an early stage founder, no task is beneath you. No action is too small or manual if it is in service of your customers. That's an important piece of this philosophy. Next, Nicholas and Brad talk about the unscalable things that Nico did at Algolia to get his first customers and how he used that practice to more deeply understand what his users needed. We and our jobs run across companies sometimes that are like terrific examples of doing things that don't scale. There's a company from the Winter 22 batch that I worked with called

Fleek. And they are a marketplace for secondhand clothing connecting wholesalers, the people who just like get tons and tons of clothes coming in and boxes from all over the world, and actual secondhand clothing shops. So it's like the back off. stuff. How does the clothing in the second-hand clothing shops get there? Fleek is this marketplace that connects the two. What did they do? So when they started out, it was just three guys with an idea and they didn't have a website. They didn't have any clothes. They didn't have anything. And they had to figure out how do we get a marketplace started between these two parties. And so they would go to the wholesalers in London, these giant warehouses full of clothes. And they would say, give us this box and

just pick a box of clothes and say, give us six hours. Just give us the box for free. We'll bring it back in six hours. And either you'll have all the clothes back or you'll have a bunch of money. And so they would get these clothes basically and they would schlep to all these shops around London and come back with $6,000 for the store. And they would do that over and over and over again and go to these different wholesalers. And eventually people knew them as these like useful people in the wholesale community who were helping. you know, match buyers and sellers.

So what did they learn from that? I mean, why did they do that? Well, they did it because they had to figure out who actually, like what sells, what doesn't sell, when's the best time to bring clothing in there, how to price this stuff, how elastic is the demand for it. And these are things that you need in a marketplace, but it's very, very hard to figure that out by building a marketplace web page and then emailing. a bunch of people and asking them to transact in it.

And instead, they did this like mishmash in person carrying cartons of clothes around and selling them by hand to get all those lessons into their bones. How long did they do that? They did that for about four months. That was a great way for them to get started. But eventually they needed to transition and start introducing the buyers and sellers to each other through their website. Because at the end of the day, in order for them to like have a scalable business that can

start making money with good margins, they need the buyers and sellers to be transporting the clothes themselves and using their own delivery fleet and employees to actually make the connections. It can't just be the CEO and the founders of the company moving products back and forth. A great story. One of the stories I remember that gave me a good impression was the story of the Stripe. It's a pretty well-known story when the Stripe founders would actually work with their customers, like implement their software, their API directly in the software of their customers. And we actually did that with Algolia too. I remember when we implemented

Algolia in Product Hunt, you know, Ryan the founder, that was before Product Hunt became huge. And he didn't have like any resource to implement Search himself. And so we remembered the Strive story. We did it. Like he gave us access to his GitHub. The first version of Algolia of search on Product Hunt was us. implementing it and pull request and him putting that online. And he was probably thrilled for the help at the time. He loved it. He loved it.

He couldn't ever have done it otherwise. And so for him it was such a help. And for us, I mean, of course, it paid back like a thousand times. Do you feel like you learned anything from setting customers up in that way? Yeah, because that created connection. Because from that point, you have that contact, that connection with the customer that is so much stronger. You can ask them anything.

And you have a way more candid conversations with them than if they are your customers and always worried about what else you are going to ask them, like money or whatever. That's a great point. You have context that all of your later conversations and interactions with them kind of grows out of. You know why they're using it, what they want to get out of it. And A, that helps you developing the product yourself, but it also helps them have a much better experience using the product. Anything you can do to optimize for these learnings is good to do. And doing things that don't scale I think the main goal is that how much can I learn today not waiting to

have developed anything maybe what I'm going to develop is going to be the wrong thing like if I can do anything like manually even going physically doing the job yourself not the software you're going to make sure that what your building is actually providing value yeah and better do that before we need too much yeah and so said differently really strong like exciting founders that we run across are people that are operating in a way that optimizes for learning. Yes, right? Like when we see people, oh, like, let's jump to self-service early on.

It's in some ways you wonder like, oh, they want to hide behind their computers versus going out and talking to their customers and really grappling with their problems and their pain. Optimizing for learning is a good way of looking at it. As Brad pointed out, the best founders we work with at YC operate in ways that optimize for learning and getting in the trenches with your, customers is an incredible way to learn about their biggest pain points.

Next, Serbia and Aaron talk about how founder FaceTime with customers can give you a real advantage over your bigger, better funded competitors. There's nothing like that founder FaceTime in the early days, right? And that's a great example of something that doesn't scale, but that's so important in recruiting customers, recruiting employees. One of the best sales founders that I worked with was Ryan from Vendor. and vendor buys SaaS software for startups and big companies. And he's really great at sales.

And one of the things that I've heard and talk about and that I learned from him is that as a founder, you have to sell yourself, especially when you don't have a product. You have a product. That's the only thing you have. Exactly. It's like really janky. And so, you know, it's when you're reaching out to somebody,

you say, here's my cell phone. Contact me any hour of the night. Or, you know, reach out to me because I, and, you know, basing the future success of my company on making you successful. And I'm going to do whatever it takes to do that. I will stop at nothing to do that. And ultimately, when you're selling to somebody, especially as an early stage founder, what you're really selling is yourself.

You have to get them to make a bet on you. And so really leaning into that is important because especially sometimes people are scared, like, oh, I'm going up against this big, well-funded competitor or a public company or whatever. Like, what middle manager is going to give out their personal cell phone number? when trying to win a customer's business. Like, nobody's going to. Right, right. And so if you make people feel like you care about them

and you're going to stop at nothing and your personal career depends on making them successful, people are going to want to go with you every single time. Every single time, yeah. Don't be afraid of taking that first step that doesn't scale so you could truly validate what it is you're working on. Anything is better than standing still. And sometimes making progress means doing things that don't scale.

One of my favorite examples of a company that did unscalable things to get off the ground is Instacart. In his original essay, PG says, partnerships usually don't work. They don't work for startups in general, but they especially don't work as a way to get growth started. Startups can't rely on big partnerships with brands to get going, so they're forced to be more creative. Here's the story of how Instacart launched without a single grocery store partnership. Do you have any good examples of this? from your own companies or from other companies you worked with? The best example that I love is from Instacart.

And so, Instacart's a service that lets you, I'm sure, lots of people are familiar with. You open your app and you can browse the inventory from a grocery store and make an order. And so a normal person starting this business might think, oh, we've got to, you know, we want to support Trader Joe's and Whole Foods. So let's go and talk to, like, management of Trader Joe's. And try and get some kind of like corporate partnership or something, get access to their data.

And like, it's going to take a really, really long time. we'll have to pay salaries and some lawyers and all this kind of stuff. It might take years. And instead, what Instacart did was they took their YC money and went to Trader Joe's and just bought one of every item at Trader Joe's. And over a weekend got access to a photography studio, took all the produce that they bought, took it to the studio and took pictures of it all, wrote down the prices, and on Monday morning put all of it online and said, we're Instacart,

you can order anything from Trader Joe's. Some founders might say, like, maybe this is not like, like perfectly legal? Trader Joe's might object, you'll get a cease and des, even if it is legal. Does this matter? I think it matters that you're not doing anything illegal. Yeah. I think it, if Trader Joe's object to you running this thing, honestly they'll probably only notice

when you get to a certain scale and then you have the negotiating leverage, you have all these customers who are already buying through Trader Joe's, but actually they don't want to shut you down. And that's exactly how it played out with Instacart. They struck deals with these grocery stores eventually after they got to scale. And they'd use this kind of hacky, janky solution to get to scale. Because it took a founder to highlight to them that this idea was actually a good idea. Otherwise, they would have never come up with it themselves.

Yeah, absolutely. And if you'd have gone to Trader Joe's or Whole Foods with nothing and tried to present this idea, you'd have been laughed out the room probably. At the very least, it would have taken you years to get that deal. Yeah, okay. All of these examples ends up succeeding. But the cases where you do things that don't scale, and it turns out no one wants to think, actually, that's good as well, right?

because you've just saved yourself months or potentially years of building something that actually no one wants. It's way better to know that up front and to be able to pivot your product slightly or choose a whole new idea complete. And by doing this stuff that doesn't scale, you've not hard-coded yourself into a corner, you know, you haven't written so much software that it's hard to change. A lot of the processes are manual. You're doing it yourself. And so if you want to try something different the next day, it's really easy because there's no software to change. And the bet that you're making ultimately is once you've figured out the right configuration of the service or the product or whatever it is, that you will then be able to use software, write an algorithm that will provide the same level of quality of service at scale.

Yeah. But it might take you several years of investment to do that. And so in the early days, without making that investment, you can give the appearance of that service or product already existing by basically faking it manually, by pulling the strings in the background, doing tons and tons of hard work yourself to deliver that incredible white glove experience to customers. Doing things that don't scale lets you experiment, fail fast and try new things. it lets you test your assumptions before you spend months building a product. From an engineering perspective, doing unscalable things, gives you freedom to move more quickly. The first version of your product doesn't need to have a ton of technical infrastructure.

Next, Diana and Michael talk about DoorDash and how they built the first version of their product in one day and did a lot of clever manual work to find out whether people wanted what they were building. DoorDash as a product was built in one afternoon. Whether you believe it or not, the tech stack was basically Google Drive to upload the menus, HTML CSS for putting the menus. The phone was Tony's phone. And then find my friends to pretend to have real-time dispatch. So it would be one of the founders going to go pick up the order.

and then the other founder, it was a team of four, would be watching in real time where we'd find my friend where the order was and it would text the customer, hey, your order ETA is 10 minutes, 20 minutes. And the orders were just taken on Google form. Granted, the team was actually very technical. It was a team with Stanford engineers, Stanford MBAs.

They totally could have done the fancy thing and build like a dynamic site with Google Mac, real time tracking and everything. But the founders were very pragmatic. That was not the hardest thing to prove out. It was like, is this even a thing that people want it? That was the startup way. Like that's the path.

No big company would ever take. This is the advantage you have as a startup, right? It's the thing you can do and no one else can do. To your point, too many founders kind of, we have to unteach them what they learn at the big companies. And like, if you play the big company game, they will always beat you. You always have to be thinking about what would you've gotten fired for at the big company? That should be your playbook at the startup.

I think the second kind of misconception that's embedded inside of a lot of startups' founders' minds is there's a way to do this in an error-free play. Like, if I'm working at Google, I have to be far more careful. All right. I need to create plans that are kind of. error proof. And that's why it takes Google forever to do anything. As a startup, your path is full of errors. Like errors are the feature. So like, should you be so lucky to have a product that so many people want to use that it crashes and then you figure out of scale, that is the correct thing, right? Like the way I always try to describe this is like, imagine a house that has a number

of cracked pipes and you have no idea which pipes are cracked or not. The big company person, would go and check every pipe one by one, no, it would take two years. The startup person turns on all the water. And where's water coming from? That pipe's cracked. Let's go fix it. And turns out that like when you are dying because too many people are using your product, the motivation to fix those bugs goes through the roof and they get fixed rather quickly.

I don't think we've seen startups die because of that reason. That's not. That is actually 100%. unsolvable problem. And you're not going to die from it because the incentives are so high to fix it. And you're on the path to build a large company at that point. But most of them don't even get to see that. And you've got to like run the pipe and run with the mess and embrace the chaos. Yeah. Doing things that don't scale is the startup way. It's the advantage you have as a small company. But at what point should you stop doing unscalable things? When do you flip the switch? This is a really

important one because people who get from zero to one often get stuck here. Harge and Pete discuss. The other side of this advice, though, is like, do things that don't scale is great advice, but at some point you do need to scale. And I think that's where it's useful to have, like, good advisors and investors around you, because they can tell you like, hey, look, no, no, no, like, you're in do things that don't scale mode. And like, oh, actually, like, now you need to flick the switch.

Now this is working. Now you should scale. Yes. Yeah, I think that's a great point. And you can think of kind of those early doing things that don't scale as a quick way to answer an important question. And once you've answered that question, well, now you have license to invest. Right? One of the forms that I've seen this question take with founders that are building SaaS software is that there's this moment in the earliest stages where you can make money by selling consulting services to other companies.

Right? And so we actually had this example at Optimizely where we were building software to help companies run AB tests. But at the earliest stages, we got companies to pay us just to go in and manually build AB tests for them. Right. And so we were making money. Great. The first version of our product was actually something that we used to make ourselves more productive in delivering those consulting services. And that's all great, right? Because it helps you answer the question, is this something that? that anyone will pay for. Right? Yes. It turns out the answer is yes.

The failure mode here though is getting addicted to that consulting revenue. Because like that's the thing that won't scale, quite literally, like it won't scale and you won't be able to build a big business if you depend on humans labor. It's a really interesting example of where you can't just fix it on just your revenue number, but it says you can always get revenue to go up by taking your more consulting. But that's why you can get around it by just setting yourself really ambitious growth

targets. And I feel like this is partly why we push the companies to have such big growth targets is one way investors tell apart what's a consultancy or a small business from like a startup that could be Stripe or Airbnb one day is like can it grow 10x? So you can't grow a consultancy business like 10x in a year. You can grow a like real software business. Totally. The advice to do things that don't scale might sound counterintuitive, but it is truly the best advantage startups have over their larger competitors. It helps you intimately learn about your customer and their problems.

It ties those early users to you more tightly and gives you opportunities to delight them. And it makes it possible to experiment quickly and fail fast if things aren't working. Go read Paul Graham's essay right now. Link in the description below. That's it for this episode of Office Hours. If you like this and want to see more, please be sure to click like, subscribe, and the bell icon down below. We'll see you next time.