[wpietri]

Are you sure you're a startup, then? If you're going to build the kind of thing your future clients are already buying, then it sounds more like a normal new business to me.

Startups are pursuing some sort of radical improvement on the status quo. For that, there should be early adopters, people who care a great deal about your kind of improvement. People who are willing to sacrifice the normal kind of good for your specific kind of great.

There's nothing wrong with being a new business, with wanting to deliver a mousetrap that's 20% better than existing mousetraps. But it's a very different kind of thing than doing a startup, and I think it's dangerous to apply one sort of conventional wisdom to the other.

[Mz]

Google was not the first search engine. A better version of an existing thing can hit big growth. Rate of growth seems to be what people are talking about when they distinguish startups from normal new businesses. It isn't actually necessary for it to be some new fangled thingamajig the likes of which the world has never seen before.

[wpietri]

My definition of a startup is the same as Blank's: "an organization formed to search for a repeatable and scalable business model." So I'd call Google a startup because they were radically reinventing the search model.

It's important for briandear to decide which he's going for. The behaviors appropriate for a startup by Blank's definition are different than those needed for a new business. Even fast-growing new businesses are different than startups, because they're not trying to do something particularly innovative.

Take Google as an example. If their goal was to be 20% better than the average search company of the day, then they would have gone for breadth of content first, because you couldn't compete in the search market without good general-audience results. Instead, their first target was Stanford users, and their second was Linux users. Instead of investing in deep ops cost reduction, which became a huge strategic advantage, they would have used commodity hardware and tools. They wouldn't have tried a variety of revenue models, seeing which ones best suited them; they would have aped existing solutions.

Google's approach is exactly the playbook that Blank, et al, recommend for startups: find early adopters and iterate until you can knock something out of the park for them. Then use that feedback loop to build a broader product while extending your market reach. Eventually you find product-market fit; if you're fast you can entirely take over a market before you have real competition.

But that's a terrible strategy to use when you're just looking to be another provider of an existing commodity, even if you want to grow quickly. Look at the top 5 fastest growing restaurants: Raising Cane's Chicken Fingers, Jersey Mike's Subs, Marco's Pizza, Wingstop Chicken, and Chick Fil-A. [1] None of these are particularly innovative companies. They sell known products to known audiences using known methods. I worked at a McDonald's as a teen, and I'm sure I could walk behind the counter at any one of those restaurants and jump into any of the line jobs there.

Both are fine kinds of companies to start. You've just got to use different techniques, so you have to know which you're doing.

[1] from http://www.nrn.com/top-100-restaurants/2017-top-100-top-10-f...

[Mz]

So I'd call Google a startup because they were radically reinventing the search model.

Everyone seems to think they are radically reinventing something. The rest of the world agrees only if they grow big enough.

I worked at Aflac for over five years. They really are a very big insurance company with a genuinely different business model. But, part of why they grew so big is because of the daring Aflac duck marketing campaign. Having worked there, I am abundantly familiar with what a shocking choice that was.

I also know that, for example, the name Aflac is really an acronym for American Family Life Assurance Company. They originally were called American Family Life Insurance Company. Another company in another state had the same name. The two companies had to decide who got to keep it and who had to go to the enormous legal hassle of changing their name. Aflac lost "a gentleman's coin toss" and changed their name.

Then when they wanted to change their overly long name for marketing reasons, they ended up going with the acronym, because that did not require them to legally change their name in all fifty states. It is sort of like someone going by Bill instead of William.

The acronym would have been Aflic instead of Aflac had the company not lost a gentleman's coin toss years earlier. Aflac sounds like a duck quacking and inspired a marketing company to suggest the duck commercials. Aflic does not.

So, Aflac is as big as it is in part because of the company losing a gentleman's coin toss -- i.e. a twist of fate, beyond their control, not remotely planned -- not simply because their insurance plans are distinct and unusual. Most people don't even understand how their policies are radically different from most insurance policies.

I think the distinction you are trying to make is pretty arbitrary. Some companies manage to grow like they are sucking down ent draught and some don't. That mostly isn't because of setting a goal to be radically different or setting a goal to grow rapidly. Many companies would very much like to do both, but even YC does not know how to guarantee that outcome and even they sometimes pass on companies that turn out to be successful anyway.

If creating the next unicorn weren't akin to mysterious voodoo magic, there likely would not be nearly so much ink spilled on the subject.

[wpietri]

I gave you 5 examples of growing companies that are not radically reinventing anything. I could give you a hundred more. Everybody here thinks they are radically reinventing something, because they have to say that. The great majority of new companies don't.

You might think the distinction is arbitrary, but that is because you are not doing the work. I have started both kinds of companies, and had reasonable success at both kind of companies. I have mentored people in both categories. The techniques involved are different.

[Mz]

You might think the distinction is arbitrary, but that is because you are not doing the work

Or perhaps you are just not explaining yourself well. Telling me why I think something is a lousy argument tactic, especially when the framing looks so personally dismissive.

[wpietri]

Sorry. Let me rephrase it as a question. Have you started companies of both types? Having read the stuff you post here and elsewhere, I believe that not to be the case, but I'd be happy to be wrong.

Also, I don't get the feeling you're engaging with much of my argument or have much familiarity with the literature I'm referring to. So you're not the only person feeling dismissed here.

[dasil003]

This feels like a no-true-scotsman distinction. What is it about briandear's description that does sound like searching for a repeatable and scalable business model? What is it about that definition that demands a high level of innovation?

Frankly, it's very easy to wax poetic about how innovative and different the biggest startup success stories were. Tech pundits have spilled buckets of ink describing in great nuance what makes AmaGooFace so different and special. But it's much easier to do this in hindsight than it is before you have any feedback, and I doubt very much that any of these company's journeys matches their early vision.

My model of a startup is this: find a way from 10 => 100 => 1000 => 10000 => 100000 => 1000000 customers. Just worry about delighting that next tier of customers, and the things you learn will give you a better shot at propelling yourself to the next phase.

[wpietri]

Ok, I accept it feels like that to you. It doesn't to me.

Briandear's description doesn't sound like a search for a repeatable, scalable business model. Which is why I asked him if it was really a startup.

Your model of a startup is not uncommon, but as I explain in detail above, pure scale is a different kind of thing than doing something that hasn't been done before. Different techniques are required. Different success milestones are used. Both involve scaling and continuous incremental improvement, but one requires a great deal of innovation early on.

[dasil003]

Okay, but that's not in your quotation from Steve Blank.

[nostrademons]

FWIW, Google did use commodity hardware and tools when they started. That was actually one of the things that supposedly made them innovative at the time. Instead of spending lots of money on beefy Sun servers, they put together stuff out of corkboards, components you could find in a PC catalog, and Linux. Their programming language was Python; their webserver was based on Medusa; their distributed filesystem was NFS; their logs processing was all UNIX tools.

All of the fancy homegrown ops stuff came afterwards, once they got lots of VC and could hire some really talented experts. GFS, MapReduce, Sawzall, the custom networking & server designs, the proprietary webserver - all of that was in the early 2000s, ~1-2 years after incorporation and 5 years after Larry first started working on it.

[wpietri]

Sorry. "Commodity" was the wrong word. "Industry standard" would have been better. My point was, as you explain in detail, that they did stuff radically different than their competitors.

In their lobby, they have (or at least had) one of the original racks. It was all caseless, no-name hardware. That was very different than the industry standard in 1997-2000.

[markpapadakis]

I thought their proprietary Web Server was an Apache for (and maybe still is)?

[nostrademons]

That's bullshit that got written into Wikipedia and then repeated frequently. I worked on that proprietary webserver; it's absolutely nothing like Apache. (When I left, it was like basically no other program I'd ever seen before - it was a frankenbinary written in C++, Java, and two proprietary programming languages. Oldest continually-pushed binary at Google; it's been gradually evolved since Craig Silverstein first wrote it in 1999, and never completely rewritten.)

BTW, the Medusa-based webserver I mentioned was gone by 1999; it was the prototype that Larry, Sergey, Scott Hassan, and Craig Silverstein did when Google was still a Stanford research project.

[markpapadakis]

Thanks Jonathan. Why did Google chose to build its own proprietary web server? Was there a specific requirement or need that Apache or other alternatives couldn't support? I suspect around that time the first event-based (async I/O /w connection multiplexing) web server was Zeus, which was commercial and likely not worth looking into it and soon thereafter there was Lighting HTTPD or whatever it's called. Did you want to, perhaps, implement your own similar design, optimised for your use cases, without having to say, pay, for Zeus?