Early-stage theories

If you'd met the Wright brothers around 1900, when it was just the two of them and some hand-built models, you might have guessed that their flying machine startup was going somewhere.  Wikipedia article:

Despite Lilienthal's fate [died when his glider crashed], the brothers favored his strategy: to practice gliding in order to master the art of control before attempting motor-driven flight. The death of British aeronaut Percy Pilcher in another hang gliding crash in 1899 only reinforced their opinion that a reliable method of pilot control was the key to successful—and safe—flight. At the outset of their experiments they regarded control as the unsolved third part of "the flying problem". They believed sufficiently promising knowledge of the other two issues—wings and engines—already existed. The Wright brothers thus differed sharply from more experienced practitioners of the day, notably Ader, Maxim and Langley who built powerful engines, attached them to airframes equipped with unproven control devices, and expected to take to the air with no previous flying experience. Though agreeing with Lilienthal's idea of practice, the Wrights saw that his method of balance and control—shifting his body weight—was fatally inadequate. They were determined to find something better.

Even without hindsight it's clear they had ideas and momentum. They had done their own experiments, learned about others, figured out some non-obvious things, and developed an original plan of attack. They didn't have the answer to stability, but they knew how they were going to figure it out. They focused on specific problems and didn't get distracted by others. Obviously they knew they'd need strong engines and wings someday, but they decided to start with the control system and build everything else around it later. They were willing to solve the hard problems by strapping themselves to kites on remote hillsides rather than just tinkering with engines on the bench like some of their competition.

In the end, their Wright company made a lot of mistakes and wasn't the biggest financial success of the early aircraft industry, but it could have been. It's the sort of startup we like at Y Combinator: technologically disruptive with a good chance of cashing in.

You can see the same features in good early-stage web 2.0 startups. They are sometimes caricatured as being frivolous companies, but in fact the good ones are based on ideas as valuable as the Wright's scheme for controlling an airplane. When Posterous applied to YC in spring 2008 there were probably as many companies trying to create blogging software as ever tried to make flying machines. The Posterouses stood out because they had been thinking about easy web publishing together for years, built prototypes, tried things, and had some insights nobody else did and a plan for creating a successful product. They had thoughtful reasons why the problems they were going to focus on would make them popular among a growing class of users, while Blogger would continue to focus on its existing user base and stagnate. 

Good founders are open-minded like good scientists. For example, I challenged Garry's assertion that submitting blog entries by email was easier than web forms. Many people seem to prefer Gmail over desktop email software, so why wouldn't they prefer entering their blog posts on the web than their email client (which might even be Gmail?) Bad founders react to such questions like, "What? It's obvious! How dare you question my premises?" Garry's answer was more like, "Yeah, we wondered about that too, but we tried X and saw users do Y so we think it'll work." He had tested his assumptions, evolved his theory, and figured out important details that nobody else seemed to get.

Fundamentally, most YC-funded companies are in the business of providing a digital service that users pay for or advertisers sponsor. There are already thousands of web companies providing a wide range of services, so why will a brand new company make money? At the heart of a web 2.0 startup are several theories:
  1. Our new service will attract the following kinds of users: .....................
  2. They will use it for the following purposes: ..................
  3. Instead of a trusted brand, they will use a startup they've never heard of before because ......................
  4. Even though some of the value is social, we will be useful to the first users because ..........................
  5. Users will recommend us to their friends because ....................
  6. Big competitors won't be able to copy our features as soon as they notice us because ........................
  7. .................... will pay us $................... in return for ........................
  8. Once we get critical mass it'll be hard for new startups to steal our users because ..........................
Those are hard questions and they're interrelated, but startups continue to find answers to all of them. Make sure the existing players don't have better answers than you. For example, Craigslist has a very good answer to #8, so you need something big for #4. We get a lot of "Craigslist for X" applications, and often they miss that. For example:

YC: Why will users prefer you over Craigslist?
Founders: We'll be more localized. Craigslist has listings from all over the city, but we'll just show you listings from your neighborhood.
YC: Maybe Craigslist would be better if it were more localized, but until you're popular you'll have to be *less* localized in order to have any listings show up at all.
Founders: So we won't turn on localization at first.
YC: But then you won't be much different from Craigslist, and there's no reason for people to switch. Your special sauce only works after you're already successful. You need a way to get there.
It's clever of Craigslist to err on the side of large granularity, because it's a phase a startup would have to go through to compete with them. Or:
YC: Why will users use your software instead of Quickbooks?
Founders: Our software will be easier to use.
YC: Are there a lot of people who find Quickbooks too hard?
Founders: Yes.
YC: But a lot of people already know Quickbooks, so it's easiest for them to not change.
Founders: Sure, we won't take away their users. We'll get new users.
YC: How will new users find out about you?
Founders: Their friends will tell them.
YC: Do people tell their friends, "Say, I just found this really easy new accounting system!"
Founders: No, but when people start a business they'll ask their friends what they should use.
YC: But they're going to ask their friend who knows the most about accounting. Won't that person be a Quickbooks user? Won't they recommend what they know?
Suppose you have answers to all the above questions. You build it and nobody comes, so something is wrong. How do you figure out what? I don't have any universal advice, but helps if you have a complete, consistent working theory the team agrees on so you have a basis for debate and experimentation.

Experimenting is hard because people are naturally afraid to put their theories to the test. Often when startups take a long time to launch, it's because they're afraid of bad news. They fear people won't like their product, so they don't release. They plow forward based on their untested theory rather than testing and iterating. Teams that don't really trust each other or where one founder is intellectually domineering are less able to try different approaches. The best advice is to strap on some plums and put whatever you can to the test, so if it's wrong you can adapt and move forward.
16 responses
Thanks for the blog trevor. It'd be really interesting to know what X, Y were in posterous's case. (We tried X and users did Y);
That was awesome advice, thanks a ton
Seconding myprasanna - I would love to know @posterous' X and Y.
Thanks. This is a great article.
@myprasana: The most visible answer: X="support a really good web editor as well as email" and Y="use email a lot".

Supporting 2 interfaces can be useful, because if people start switching it suggests a problem/opportunity. You also get better used feedback: rather than vague wishes, they'll tell you "I can do this in interface B, but it's really inconvenient in interface A." That seems to lead to good product evolution.

11 visitors upvoted this post.