I've been eagerly watching/reading all of these lectures.
Top quality content. Many thanks to YC for doing this - I look forward to the beneficial impact that spreading this knowledge will have.
My only complaint is that many of these things are easy to hear, and agree with - i.e. talk to users first, of course! Yet, it can be hard to bridge the gap between what we agree with, and the actions we take. Much easier to bridge the gap when this advice is given during YC session, where people can take it and immediately apply it.
To remedy this for myself I'm making checklists for each of the classes, almost like a CS183B sanity check tool.
As an example, here's my checklist for class #5 (on growth).
I really like the main message of this video. I think it makes loads of sense, I've employed it in my own projects at the beginning.
One question is that it seems like the first speaker and some of the people asking questions are asking "why did nobody ever do this before?"
That just isn't true. In Atlanta, for instance, we have had a company Zifty for years. Zifty has been here well before grubhub or the other sites. I guess Zifty hasn't expanded to San Francisco, yet. :) But anyway, my point is that I don't see how doordash is a new idea?
Edit here's the question from the transcript: Q: When you started, it seemed so obvious to you, you were wondering why, what the reason was nobody had done this before. What's your answer now looking back?
Do things that don't scale is a great. An approach we took to heart. However, we're now ripping apart at the seams and this is negatively affecting our members. So now I need to go out and raise capital so that we have more bandwidth, but in doing so I exacerbate the problem because when I'm away lose 1/3rd of our team. I can't way I would have done anything differently, but if the capital is not there when you need it, then things start to break down with this approach.
I'm not sure why you got downvoted because our experience matches yours. Just like everything, this mantra needs to be put in context. There are different stages in a startup life. It is possible that some strategies would cease to be valid once you go beyond certain stage.
DoorDash should team up with Uber, Lyft et al. Or the other way around, Uber or Lyft could do what DoorDash does.
On another note, home delivery has been in Japan for many years, but there, the density of population makes it feasible - someone at the restaurant just loads the trays of food onto a special spring-suspension tray holder on his bicycle and makes the delivery. After finishing the meal, the recipient leaves the trays, dishes, and bowls outside for pick up the next day. Usually, there is no extra charge, and tipping isn't common in Japan, so it's a good deal.
Home delivery has been around in India for ages too. Not only for restaurants (for which it became common only some 10 or 15 years ago, IMO, though existed before too), but much more for small general stores - called kirana stores here - what are called mom-and-pop stores in the US. And the owners of those small stores, who often are from the Marwari community (at least in northern and central India) are very entrepreneurial.
A lot of great points shared. I like how door dash talks about hacking solutions together to make it work. To improve the efficiency the way a business is ran you have to understand all its components. In their case it was driving cars, charging transactions, etc. starting crappy is ok as long as you continuously improve.
I don't understand why there's so much emphasis on doing things that don't scale. Here's why:
In this lecture, we heard about DoorDash, a successful delivery business that is now expanding to multiple cities.
DoorDash adds value by delivering more efficiently than small businesses can on their own.
An example of a small business that benefits is a Palo Alto Macaroon store. Before DoorDash, the Macaroon store took orders by phone and recorded them by hand in a thick notebook. Then, when there was time, the owner of the Macaroon store would personally deliver orders out of their personal car. No additional cars were ever purchased and no drivers were ever hired.
One key factor is causing DoorDash to succeed where others have failed: mobile phones. The ubiquity of smartphones has enabled DoorDash to hire and coordinate part-time contractors with personal cars. This new development makes the service cheaper than past competitors.
Now, you may be wondering what my point is. Why am I summarizing the pitch we heard from DoorDash?
Because it's all about SCALING!
Let me explain.
+DoorDash is startup. By definition, that means it wants to scale.
+DoorDash is expanding to multiple cities. I.e., it is scaling.
+The businesses it helps are those who otherwise deliver at low volume with a phone and notebook. I.e., in a way that doesn't scale.
+DoorDash has no proprietary technology and is not a monopoly (Peter Thiel disapproves, by the way). DoorDash is competing on one main dimension: cost. And how do they achieve lower cost than a mom & pop macaroon shop? By scaling. Operating at scale is their main competitive advantage.
+And why is DoorDash succeeding now, when past delivery start ups have failed? Because of mobile technology. And what is mobile technology letting them do? Manage a fleet of drivers at scale.
+DoorDash is a software company and software companies are eating the world. Why are software companies eating the world? Because software scales!
DoorDash's words say to "do things that don't scale." But DoorDash's actions say the opposite. Scaling is the key to their business.
(Incidentally, DoorDash gave an example of something that they claim doesn't scale: writing personalized notes to customers after orders. But guess what? That totally scales!)
Can someone explain why so much more emphasis is placed on doing things that don't scale? Doing things that scale seems to be more important to me.
Edit: I don't mean to be harsh. I'm honestly curious and hoping to open up a discussion. The emphasis on not scaling seriously puzzles me. I'm sure you folks have great ideas that I'm missing.
The idea is part you must do whatever it takes to have your first users/clients and keep growing from there (as the guy from Teespring says) and part is that you must first know what to scale.
Sure, startup = growth, no one starts a startup without imagining it will grow a lot. But that is why this advice is particular powerful, because, as PG says for a lot of things on startups, it is counter-intuitive.
So the advice is more about doing things that don't scale until you actually reach product/market fit (which means "Make sure your retention flat lines at the appropriate level.", as said by Alex Schultz in his lecture); you should do things that don't scale.
But, sure, when you focus in big growth and scale, yes, then you start scaling stuff.
PS: I really sound like the ass-kissing student on your class who repeats everything teachers said before to look good. But I really think al of it makes sense.
Here's an analogy: Have some URLs of some Web
pages and want to extract the links from those
pages? Okay, first do it by hand! So, have
a Web browser save the HTML and CSS, JS, files.
Then use a good editor to look at the HTML and
see how to parse the thing and extract the links.
Write some code to do this and try on some more
of the URLs. When see are not parsing the files
just right, tweak the code.
Finally, get some okay code and get and parse all
the HTML files from all the URLs with the code --
scalable!
So, start by hand and see how to automate the work
and then have a scalable solution.
I just did that for a collection of about 5000 URLs!
> DoorDash adds value by delivering more efficiently than small businesses can on their own...DoorDash is competing on one main dimension: cost. And how do they achieve lower cost than a mom & pop macaroon shop? By scaling. Operating at scale is their main competitive advantage.
You make some good general points in your comment, but since you're holding up DoorDash as an example of success, I thought I'd point out that DoorDash is just one of a number of "on demand" companies that are currently en vogue.
In many cases, their ability to scale is heavily dependent on their ability to shift major costs (taxes, vehicle operation, commercial auto insurance, etc.) onto their workers, who they classify as independent contractors. The big question is whether the workers are actually independent contractors. This is a topic of discussion in legal circles[1] and the trend does not look favorable for many of these companies[2]. Uber is already being sued for misclassification[3] and the same attorney says she's looking at Homejoy[4].
One adverse outcome in a legal action could change the economics of these businesses significantly, and potentially even put some of them out of business.
>In many cases, their ability to scale is heavily dependent on their ability to shift major costs (taxes, vehicle operation, commercial auto insurance, etc.) onto their workers, who they classify as independent contractors.
well, probably time comes for a "collective bargaining on demand" startup and an app for it
Non-scalable things usually can still scale to tens or hundreds of customers, and those first tens or hundreds are the hardest customers to acquire for startups. The hardest thing for startups is to get started (hence gain insights to what problems are most important to solve first), and these non-scalable things are the fastest/easiest ways to start. For typical hackernews readers, solving problems and scaling are usually not too hard (challenging but quite doable), but getting started fast and finding THE problems are very very hard and often not fun to do.
he said it in the lecture: it's more important to go fast than to worry about scaling when you're trying to get your first users/customers.
of course you need to scale later, but the activation energy of getting users/customers is high and you will likely need to try many solutions to overcome that activation energy, so fast is better than scalable in the beginning.
You raise a good issue, the role of mobile phones.
Okay, I heard that point in the lecture and read it again
in your post.
Okay, now for me -- I'm slow this evening, and I still
just don'e get it on the crucial role of a mobile
pbone. A phone, sure. But what's the crucial role
of the mobile part?
A guess: For a given delivery job, the candidate
drivers typically are not close to a land line or
desktop phone. Instead they are out and about
typically in the car they will use for the delivery.
So, the fact that their phone is mobile, that is,
with them always, is what is crucial. A guess.
A second guess: The phone should be not just mobile
but also smart so that it has GPS to say where the
heck the driver is currently. Then, with an app on the
smart phone, could let the central office or
dispatching system pick the driver closest to the
location of the pickup. But this would meant that they
have an app, and I thought that maybe so far they
didn't.
Gee, I had heard that it was standard for taxi
services to be willing to pickup from a restaurant
and deliver the food.
And I'm confused: Where I've lived in the US, it
has long been standard for pizza shops and Chinese
restaurants to be willing to deliver. So, sounds
like the problem of delivering food for such
restaurants had long since been solved.
Apparently there's going to be more of this stuff
of a customer pushing some buttons and have some product delivered within, say, an hour. So, apparently one goal
of Amazon is to have warehouses in major cities so that
there can be same day delivery of orders. Okay, then,
Doordash could be looking to do those deliveries?
There should be some economies of scale here: That is,
for five pizzas, have two ways to proceed. First way,
just pick up the pizzas one at a time and deliver them.
The second way is to pick up all five pizzas and deliver
them using a solution to the traveling salesman
problem with six stops, the pizza shop and the five
customers. So, of the pizza shop is busy, get to
pick up several orders there within, say, 5 minutes.
Or, maybe pick up from several restaurants in the
town center and deliver to the surrounding houses
and offices -- one Doordash with nearly all the
restaurants in the town center would have an
economy of scale.
Doordash got such fast response from their simple
landing page that maybe a lot of taxi drivers,
some of which are just sole proprietorships anyway,
and, sure, now likely making heavy use of cell phones,
that they could just offer a service like Doordash
for any pairs of customers and restaurants
that want a delivery. I'm failing to see why
the taxi drivers in Peoria need Doordash to
follow the same idea.
Top quality content. Many thanks to YC for doing this - I look forward to the beneficial impact that spreading this knowledge will have.
My only complaint is that many of these things are easy to hear, and agree with - i.e. talk to users first, of course! Yet, it can be hard to bridge the gap between what we agree with, and the actions we take. Much easier to bridge the gap when this advice is given during YC session, where people can take it and immediately apply it.
To remedy this for myself I'm making checklists for each of the classes, almost like a CS183B sanity check tool.
As an example, here's my checklist for class #5 (on growth).
https://chris.typeform.com/to/DxLnqP
(by the way, typeform is awesome and way better than google forms)
Anyhow, awesome series and I look forward to watching this lecture. I'll reply and post my checklist for this class too!