理解产品和创业最重要的事情

First, a quote from Marc Andreessen's "Guide to Startups, part 4: The only thing that matters"

If you ask entrepreneurs or VCs which of team, product, or market is most important, many will say team.
...
Personally, I'll take the third position -- I'll assert that market is the most important factor in a startup's success or failure.

Why?

In a great market -- a market with lots of real potential customers -- the market pulls product out of the startup.

The market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along.

The product doesn't need to be great; it just has to basically work. And, the market doesn't care how good the team is, as long as the team can produce that viable product.
...
Conversely, in a terrible market, you can have the best product in the world and an absolutely killer team, and it doesn't matter -- you're going to fail.

Mark's blog post did not immediately resonate with me, because his terms are somewhat different from the way I think. After all, how great is your product if nobody wants it? How great is your team if they persist in building something that nobody wants?

However, his main point has stayed in the back of my mind since then, and I'm continually reminded of how important it is, and how often I see people who clearly don't get it.

In my mind, there's really two points. One: You can take the smartest, most experienced, most connected, most brilliant people in the world and have them build the most stunningly designed and technically advanced product in the world, but if people don't want it, then you will fail. This is roughly what happened with the Segway, for example.

Perhaps that seems a little discouraging. After all, if really smart people with all the right resources can fail, then what hope is there for the rest of us? Perhaps success is random, and maybe startups are more like the lottery than we'd like to admit.

I don't believe that's true though. There is an optimistic way of understanding my first point, and that's my second point: Even if you aren't the smartest person around, and your product is kind of ugly and broken, you can still be very successful, if you just build the right product. YouTube and MySpace are both fine examples of this.

But if your team is so great, why aren't they building the right product? Simply put, they have the wrong attitude. Firstly, they overestimate the importance of their own skills. Engineers think that success is all about fancy technology and complex engineering (hello Google). Designers think that success is all about beautiful design. MBAs think that success is all about knowing the right people, or spreadsheets, or something. If you have especially smart or successful people, then this problem could be even worse, because then the team is also likely to be arrogant and overconfident, which makes them less likely to question these assumptions or the value of their own skills.

It's easy to find examples of this wrong attitude. When Google acquired YouTube, many people inside the company were flabbergasted, "But they have no technology!?" They didn't understand that you only need enough technology to make the product work. Any more and you probably have the wrong priorities. I regularly see similar complaints about Facebook, MySpace, and a lot of other popular sites. Similarly, people will often complain that MySpace or even Google has "no design" or "bad design". Again, they have enough design (or the right design) to work for their users.

So what's the right attitude? Humility. It doesn't matter how smart and successful and qualified you are, you simply don't know what you're doing. The good news is that nobody else does either, though some are foolish enough to think that they do (and that's why you can beat them).

What is the humble approach to product design? Pay attention. Notice which things are working and which aren't. Experiment and iterate. Question your assumptions. Remember that you are wrong about a lot of things. Watch for the signals. Lose your technical and design snobbery. Whatever works, works.

MySpace is a great example of this. I'm pretty sure that their custom profile page layouts were an accident. They didn't know enough to properly escape the text that people put on their profiles, and that allowed their users to start including arbitrary html and css in their pages. This is a common bug, and most people would have fixed the bug and that would have been the end of it (really great engineers wouldn't have had the bug in the first place). But they did something smarter. They noticed that the feature was popular and found a way to preserve it. The result is mostly ugly, but it's extremely popular.

There are many other accidental inventions besides MySpace, but it's important to understand that "accidental" isn't the same as "random". There are clues all around us, we just need to watch more closely.

For web based products at least, there's another very powerful technique: release early and iterate. The sooner you can start testing your ideas, the sooner you can start fixing them.

I wrote the first version of Gmail in one day. It was not very impressive. All I did was stuff my own email into the Google Groups (Usenet) indexing engine. I sent it out to a few people for feedback, and they said that it was somewhat useful, but it would be better if it searched over their email instead of mine. That was version two. After I released that people started wanting the ability to respond to email as well. That was version three. That process went on for a couple of years inside of Google before we released to the world.

Startups don't have hundreds of internal users, so it's important to release to the world much sooner. When FriendFeed was semi-released (private beta) in October, the product was only about two months old (and 99.9% written by two people, Bret and Jim). We've made a lot of improvements since then, and the product that we have today is much better than what we would have built had we not launched. The reason? We have users, and we listen to them, and we see which things work and which don't.

Find the gradient, then follow it.