How Stanley Tang Built DoorDash with Speed, Conviction & Chaos | The Library of Minds

Yeah, no, that's a good question. I think I was very lucky. I grew up in a household that really embraced technology and this idea of just trying different things out. My dad's a physics professor. So at a very young age, I remember I was three years old when he first brought home a computer. I remember as a kid I was always surrounded with computers and I remember just being hooked to playing with Microsoft Paint and making PowerPoint slides, making websites, all that. And my dad always encouraged me. He's a physicist, so one of the things he really emphasized was this whole idea of experimenting with things. You're not going to know what you like unless you try it. So as a kid, he really encouraged me to just try a lot of different things and explore different hobbies, versus pigeonholing you into a pre-planned career or life that's been assigned to you. So yeah, just experimented with a lot of different things and I think I just fell in love with technology and computers and the potential of tech and software and the internet.

Yeah. Well, the founding story is actually really funny and really interesting because we actually weren't trying to start a company. It came out of a class dorm room project. The project had nothing to do with food or delivery. It was about how do you apply software to the world of local small businesses. This was like 2013 at the time. I think the hot thing back then was mobile apps, social apps, Snapchat, Facebook, Instagram, but no one was really focused on building software for the physical world. The local businesses down the street, for the vast majority of these, again this is back in 2013, they're run on pen and paper, no technology, no software. And so we felt like that could have been an interesting opportunity. What software could we build for that audience? So as part of the project, we would go and interview a bunch of small business owners around Stanford. Palo Alto, Mountain View, San Mateo, just door to door. We'd go in and say, 'Hey, we're a bunch of Stanford students doing a class project. You want to talk to us?' So we spoke to flower shops, furniture stores, restaurants, boutique retailers, you name it, all across the spectrum. And I remember it was at a macaroon store in Palo Alto when we first encountered this problem around delivery. The owner Chloe sat down with us at the time. She started explaining to us, oh, she's getting all these delivery requests from her customers, but she has no delivery drivers to fulfill these orders. So she's a one-woman shop. She would go do it herself, otherwise she has to reject it. So this is why the vast majority of local businesses, including restaurants, don't offer delivery. And we spoke to a coffee shop in San Mateo. We heard the same thing. We heard it from a flower store especially during Valentine's Day. And so we thought maybe that's the idea we should be pursuing. It seems like there's an opportunity to instead of just building a piece of software that these businesses want, it's actually a service. When you get one of these delivery requests come in, they should call a service that is optimized for local last mile delivery. The idea is instead of each of these businesses hiring their own drivers, we would create a shared pool of delivery drivers that all these businesses can tap into. That's what these businesses need. So that was the initial light bulb moment for us. And so we thought, well, what if we built an experiment instead? This experiment was very straightforward. The idea is, okay, why don't we put together a simple landing page? It's a one single page static HTML website where we found a bunch of restaurants we liked in Palo Alto that didn't offer delivery. We compiled it into these PDF menus. We threw it up on this website and all this website said was if you want to order delivery from these eight restaurants, call this phone number. And it was a Google Voice phone number that rang the cell phones of the founders. The whole point of this website was if we put this out there, how many phone calls we would get. It was essentially a fake delivery service, but the idea was to see how many phone calls we'll get. It was a data collection exercise and then we can use that data to support, oh, there's demand for delivery, therefore we should go work with these restaurants to build something. That's as far as we thought. Nothing further. And then literally like an hour later, we got a phone call. We picked up our phone. It was the Google Voice number on paloaltodelivery.com. We picked up the phone call. First of all, I have no idea how this person found this website. Even to this day, I still have no idea how because we hadn't told a single person. He literally must have just typed in paloaltodelivery.com. We picked it up. And yeah, it was this guy. Somehow he found our website. He wanted, I remember his exact order, he wanted shrimp pad thai and egg rolls from this restaurant that unfortunately doesn't exist anymore called Bangkok Cuisine in Palo Alto. And I remember in that moment we were kind of taken off guard a little. We weren't, originally we were supposed to tell this person, oh this is not a real delivery service, it's just a data collection exercise so that we can complete our class project at Stanford. I think in that moment, this guy seemed really, really hungry and we kind of felt bad telling him this is not a real delivery service. I certainly did not have the guts to tell him it was not a real delivery service and so I said, 'Hey, about my co-founder, do you guys want to tell him?' And they didn't want to tell him either. So we said, 'You know what? It's just one delivery. How bad can it be? Why don't we just do this delivery ourselves? We can actually learn about how this whole delivery thing works. Not like we have anything better to do.' So we literally just picked up the other phone, called Bangkok Cuisine, placed a takeout order, we got in our cars, drove over ourselves, picked up the food, and delivered it to that customer. So I remember the exact date. It was January 12, 2013. And that was the start of paloaltodelivery.com. And the next day we got two more phone calls and we decided okay well we'll take those two as well and then it became three and then five and the next thing you knew, paloaltodelivery.com just went viral on campus. Everyone was ordering. We were the delivery drivers going back and forth. Again, up until then there's no technology. This is literally just Google Voice phone calls. We're just placing the takeout order ourselves over the phone and we're just coordinating everything through texting and Google spreadsheets and things like that. So that was how DoorDash got started.

Yeah, honestly none of that mattered in the beginning. In the beginning, the only thing that mattered was just serving the customers you have. People use the phrase product market fit a lot. The most important thing in the beginning is are you solving a customer problem? In this case, there was a clear customer need for both sides. For the consumer, they wanted delivery and for the retailers and the restaurants, they wanted to have the ability to offer delivery because it was a way to expand their reach and grow their business. So we kind of found this perfect customer problem to go after and it was an unmet need as well. There wasn't really anyone solving this problem for both sides. I mean there were companies like GrubHub and Seamless that existed back then, kind of these legacy food delivery players that actually weren't really delivery players. They were more marketplace aggregators. This is kind of where we were able to fulfill that unmet need for them. We weren't only listing your restaurants on a website, we could actually power the delivery as well. That was the initial focus. You got to solve a customer problem, you got to get product market fit with an unmet need and there aren't any existing players that are really equipped to solve it. So that's kind of what allowed DoorDash to take off in the beginning.

Yeah. So doing things that don't scale, that's probably the most important part of the DoorDash founding story and DNA and we probably took that to the most extreme as possible. In the beginning, the whole thing didn't scale. It was zero software. The whole thing was done through pen and paper or texting and Google spreadsheets. And then when we started onboarding new drivers, we said okay, we made everyone install Find My Friends on their iPhone so you could track everyone's location and dispatch manually. Initially in payments, we didn't have payments available online. The whole thing was just done through these Square dongles lying around. So that was payments when it came to charging the customer. But what about paying for the food at the restaurants? In the beginning when the founders were doing the deliveries, we would just use our own credit card which was fine. But now that you have drivers doing deliveries for you, you can't expect a driver to be paying for all this food up front on their own personal credit card. It starts adding up. So the solution was, well, why don't we go, we found out you can actually buy these prepaid debit cards from a Walgreens or CVS. You essentially just go in, you buy one of these cards, you load it up with cash, and then you can just give it out to your drivers and then replenish it every week. So that's what we did. And here's the funny thing, we didn't realize that you actually can't buy one of these debit cards with a credit card. You have to pay cash to buy one of these debit cards. So every day we would go to the ATM machine, draw a boatload of cash, walk into Walgreens, buy up all the debit cards, and then the next day we'll go back and do the same thing again. So just imagine the Walgreens staff seeing these bunch of young college students coming in with bricks of cash buying up all the debit cards every day. They probably thought we were like drug dealers or something, but that's what it took to make this happen. And the last example I would give to illustrate how we took doing things that don't scale to the extreme is this idea of, initially the thinking was okay, we'll start by doing things that don't scale. We'll just call these restaurants and then in six months later we'll convert them into some sort of integration into the point of sale. We'll give them an iPad, we'll digitize it at some point. Well, it turns out the pace at which we were onboarding these restaurants, or the pace at which we were growing DoorDash and adding new restaurants, was outpacing our ability to implement these integrations. So we had to just keep, we thought this was like six months, but turns out it would be years later before we were able to digitize everyone. So in the meantime, we thought, okay, why don't we just figure out a way to scale order placing? No one ever asked the question, well, how far does doing things that don't scale actually scale? And the answer is always much further than you think. So we thought, okay, why don't we just try to instead of trying to limit our growth, try to figure out a way to scale order placing? So we just literally said, okay, what if we just go and hire a bunch of order placers or contractors that all they do is just place orders? We built a little dashboard where you can claim orders and for every order they placed. And we were able to scale that. I think at our peak we had probably over 8,000 people placing orders every single night. And even to this day, we still have order placers. A lot of things at DoorDash, I would argue even to this day, are things that are quote unquote unscalable, but we still do it. So I think it forces you to prioritize what actually matters. It's so easy to just say, oh, we got to automate all these things. We don't have enough engineering resources, etc. But really, what is actually truly necessary to automate? By doing things that don't scale, it really forced us to actually work on the things that couldn't scale, versus thinking, oh, we just got to automate order placing because it feels like something doesn't scale, but turns out it does scale.

Yeah, I think I'll answer it in two ways. I'll answer your first question and then the second part as well. The first question, in terms of thinking about competition in the early days, not really. I mean, later on, yes. But in the early days, you're going after such a big market, no one's really a big player yet. Chances are the competition you're facing is not Uber or Postmates. The competition you're really competing with is existing consumer behavior of ordering takeout or not ordering delivery at all, like cooking at home. And that's really the main competition. Even if you added up all the delivery players back then, even right now, if you added everyone together, all the delivery players together, I think we're still less than like 20% of the overall restaurant food market. In the beginning, the only thing that matters is are you serving your customers? Are you serving the restaurants? Are you serving your consumers? Are you serving your dashers? That's it. Getting that to work. Chances are a customer is not going to switch off of you because Uber came on. They're probably going to switch off of you because you messed up their delivery. So it's about can you get that delivery quality consistent, obsessing over every single delivery, the quality of each delivery, the speed, the customer service when things do go wrong, and doing that at scale. That's honestly the hardest part, which I think leads to the second part of your question. I think you have to understand what the product you're building. For us, it was very clear that the product we are building is not a pure software business. It's a business that requires the marriage of good technology and operational excellence. It's a lot more of an operationally complex business. One of the things we care a lot about is going into the lowest level of detail because no two deliveries are the same. You can't look at things at an aggregate level. Things might look good on a dashboard because on average our delivery time is 37 minutes, but that doesn't really tell you anything because some of your deliveries are going to be 20 minutes, some deliveries are going to be 80 minutes. It's really the outliers that are going to kill your customer experience. So for us, we always look at things down to the zip code level. We'll pull up literally individual deliveries and go like, what the hell happened here? This was a completely messed up delivery. So what are we going to do to address it? So that's the level of rigor it takes to build an operationally intense product. It's more about how do you optimize the delivery experience. When things go wrong, do you have automations in place to detect the driver is going in the wrong direction, so you should have an alerting system? How do we do a better job predicting restaurant prep time by time of day? Those are the kind of product challenges we focus on, as opposed to where does this button go?

Yeah, that's a really good question. I'm still trying to figure that out to this day.

For me, when people ask me how is DoorDash so innovative, or how does innovation happen at DoorDash, how do you come up with all these products and features and know what to build and keep figuring things out? I can tell you it's definitely not because we're a bunch of product geniuses sitting in a conference room coming up with these amazing ideas. For me, it's more about how do you create product? How do you innovate at a consistent level? It's all about experimentation. It goes back to the founding story of DoorDash. DoorDash started off as an experiment. No idea if this would work or not. And all we've done is simply scale that so that instead of just being one experiment at a time, we're running probably a thousand experiments at a time. It's just about constantly experimenting, constantly iterating. For me, innovation can be defined as how quickly can you iterate. That's it. How many cycles, how many iterations can you get in as short of a time period as possible? The quicker and the tighter you can get that loop, the more innovative you are from the outside because it looks like you are, but that's simply a company that's more innovative is just a company that's iterating a lot more and experimenting a lot more. That's how we think about DoorDash. How do you run this giant experimental iteration machine and decentralize it so that anyone at the company can iterate? Your job as the founders and the leadership team is less about telling people what to do. It's more like you're almost like a VC firm or VC fund. You give people small budgets, see which projects pick up steam, and as they scale, say, all right, this project has graduated into the series A, here's 10 more engineers. Oh, this is now you hit the series B milestone, here's 50 more engineers. As they hit these milestones, you just keep giving more and more resources, versus trying to predict what's going to work and what's not.

Yeah. I would say hardware is definitely a little bit different. Robotics and hardware, I think it has to be a little bit more top down. You kind of have to have a vision and say, hey, this is where the world's going. Robotics, autonomy is going to be part of our future. So do we either want to control our destiny and build that future for ourselves, or do we want to wait on the sidelines and wait for this disruption to happen to us? We will always want to be the former. We always want to be the ones that control our own destiny, especially if there's going to be a big paradigm shift, and that's why we're going to invest in this. You can take a thoughtful way of this iterative milestone based approach, maybe not quite the same as software. For us, we've taken a much more methodical approach where it's like, let's first figure out what is our autonomy approach. Should we be building these things ourselves in house, or should we be working with partners and vendors? There are drone companies out there, sidewalk robot companies out there. First, let's figure out what our approach is. It's understanding what the use cases you're solving for and then figure out what form factors fit into each of these use cases. It turns out, I think what we learned is, there's no one singular autonomy solution for delivery. Maybe ride share is different, but for delivery, it's not going to be like, oh, we create this one singular autonomy solution that addresses every single problem. It's going to be a spectrum. There's some deliveries that we've done millions of deliveries with sidewalk robots, but these sidewalk robots address a very particular use case. They're for college campuses, downtown urban areas where distances are less than half a mile. These things don't work when you need something delivered that's six miles away. Maybe drones fit in really well for deliveries that are going from more rural areas where road accessibility is a bigger issue. That's where drones come in handy. And then maybe you need something like a bigger autonomous delivery vehicle to do the three to five mile deliveries in places like Texas or Kansas where it's more of an urban sprawl. And we even explored there's going to be autonomous robotic solutions that are needed inside the kitchens, around kitchen automation, kitchen operations improvement. We have these things called DashMart which are essentially ghost warehouses. How do we bring automation through there? So again, it's not a one size fits all. It's going to be a spectrum of solutions. Some of these we're going to build ourselves. Some of these we're partnering. We're already doing a lot of these. For example, drone deliveries, we've done probably hundreds of thousands at this point across the world. We've done in Australia, Texas, most recently Charlotte. So we are doing these things, but again, you can take a much more iterative approach instead of one size fits all. Let's throw the kitchen sink at it. Say, okay, let's try to identify what the use cases are and for each of these use cases, figure out what the right form factor is and then figure out if it's working or not and then scale from there.

Oh, I mean there are a lot of these moments, but I'll say the one that stuck out to me the most was actually a moment very early on at DoorDash. It was maybe nine months into the company. September 2013. DoorDash had just been around for a few months. And I remember this was also the night of the first Stanford home football game. So everybody was back on campus. Everyone was excited for the game. They wanted to order food. And also it was raining hard that night. For us, when it's pouring rain, that's when demand spikes. Everyone no one wants to go out. And we were just completely unprepared that evening. Orders just kept flooding in. We couldn't shut the orders off. We didn't have enough drivers. Everyone was out doing deliveries. And of course it ended up being a complete disaster. Everything was late by two hours. For a lot of these customers, this is the first time they ever used DoorDash and it was the worst experience possible. They're never going to use DoorDash again. And oh by the way, we probably had about four weeks of runway, three weeks of runway left. We just got out of YC. We haven't raised our seed round yet. So we only had the YC money essentially. So we got back and it's like everything was disastrous and we're like holy crap, what the hell just happened? No one's ever going to use DoorDash again. And so the question became, what do you do in that moment? Do you try to preserve as much of the cash as you can, just try to pretend this day never happened and hope people forget? Or do you try to do the right thing for your customer? In this case, the right thing for your customer is if something's two hours late, you should get your order refunded plus maybe even more on top. And when we did the math on refunding everyone's order, keep in mind when you refund the full order, you have to actually pay more than what, because DoorDash only collects the delivery fee, but when you refund the order, you got to pay for the entire meal itself because it wasn't the restaurant's fault. We can't make the restaurant pay. So when we did the math, it worked out to about 40% of the amount of cash we had remaining. And it took us about maybe 15 seconds to make the decision and we decided, you know what, we got to do that. This is the only way we could preserve our reputation. Otherwise, what's even the point of doing this? And so we pressed the refund button. We also spent all night writing handwritten apology notes and for the most egregious deliveries, we actually hand baked cookies and delivered them to every one of those homes that evening. And that really preserved our reputation and also defined what DoorDash means as a company. We are the company that's going to do what's right for the customer. Even to this day, it's what DoorDash is about. Customer love is one of our core values.

No, it's forever. You just learn to embrace it. I used to be, it's funny because this is one thing that I've changed the most through this company building process. I used to be a very OCD kind of person. When I was in my early 20s, I was one of the type that your calendar had to be perfectly organized, every minute has to be accounted for. Today I'm the exact opposite. I embrace the chaos, embrace ambiguity, embrace change, embrace fluidity. Because things are never going to be perfectly organized. The day everything is perfectly organized is the day the company shuts down. So you just got to embrace it.

User onboarding for dashers used to be very, very hands on, very heavy handholding. They would literally show up to our office for an in person orientation and go through for a full hour. We'll go through how the app works, how DoorDash works, best practices, this and that. And they will then go out with one of the DoorDash employees. I've actually done this before where we literally just go on a three hour dash together, one on one, just to make sure this person felt comfortable. And then after that we put them into the wild and have them do deliveries on their own. Because we again had no product automation, so the only way to automate onboarding was we actually got to do these physical onboarding sessions. And then eventually you build it into the app where the app gets so much better that it's kind of self explanatory. Then we switched to they watch a video in the onboarding app, and now the whole app is so easy, so automated that you don't need these onboarding sessions anymore. So that's kind of again, we did initially the thing that doesn't scale. It's not you can't scale onboarding sessions, but turns out you can actually scale it pretty far. I remember I was talking to Gojek, which is like the DoorDash of Indonesia, and they said they do these driver onboarding sessions where they literally rent out an entire football stadium and it's like 50,000 dashers just show up. And then they do an onboarding session and an hour later they all leave on their scooters and then they start doing deliveries. So I guess it does scale to a certain extent.

Cool. Awesome. I look forward to talking to myself.