

What I Learned from Zuckerberg's Mistakes  - aresant
http://launch.is/blog/2010/12/14/launch002-what-i-learned-from-zuckerbergs-mistakes.html

======
ThomPete
I had another epiphany some years ago and it kind aligns with Zuckerbergs
encouragements.

"Don't worry about it"

In the Design/UX community that I normally work in there is a tendency to not
only identify the problems but blow them way out of proportions.

The smallest things like naming can be debated for hours.

Don't get me wrong. Naming and consistency is very important but it's not
worth wasting an entire day solving when you could have used that day after
the launch to figure out where the real problems where.

In Danish we have a term called fagidiot (very loosly translated into
professional bias). If you have ever tried watching a war movie with a
military buff and heard him complain about how unrealistic the explosion is or
how a Baretta can't really shoot that fast you know what I mean.

We have a tendency to think that the world will come to an end if what we care
about is not taken serious enough when in reality the world move on just fine
and the problems we see as highly important we are the only one caring about.

After that I started realizing that pseudo problems aren't really worth
spending your time on. If you want to build something great just go ahead and
do it don't worry about the mistakes they are not the ones bringing you down.

What will bring you down though is to obsess over details that only you care
about.

~~~
bigmac
Very cool term, sadly its totally unacceptable to use in English. I will never
be able to describe someone who is overly obsessed with minute details as a
"fagidiot" in America. The associations built into that term are just too
politically incorrect.

~~~
wil2k
Another option is to use the Dutch version "vakidioot". ;-D

Once again "vak" is trade/profession/"subject area" and "idioot" means well
idiot.

[http://www.proz.com/kudoz/dutch_to_english/other/833923-vaki...](http://www.proz.com/kudoz/dutch_to_english/other/833923-vakidioot.html)

------
GavinB
Facebook - Developer driven

Apple - Designer driven

Google - Data driven

Amazon - Testing driven

Zappos - Service driven

You could argue semantics on these, but it seems clear that they are all
successful and yet all put the greatest focus in different areas.

Maybe the key is not that one emphasis is the best, but that it's important to
have _a_ priority and stick to it. It's the companies that let different
groups with different priorities fight over things that are paralyzed.

~~~
aresant
That's an oversimplification.

Facebook - Design was their early traction - clean and exclusive, with
regimented testing in every release.

Apple - Built on incredible engineering and developers, leading case for
vertical integration.

Google - Key innovation behind pagerank was scaling it with a node-based
hosting architecture which was built by incredible engineers. Not to mention
google maps which won on design alone and is becoming their #2 most important
product.

Amazon - Innovations in shipping, distribution, and line automation are far
more important than testing in the razor thin book marketplace that put them
on the map.

Zappos - Ran out of steam here, probably a good combo of the above four :)

I see your point, that's what the companies are known for.

But in reality there are deeper innovations that are have powered those to the
levels they are today - seems like each of the above GREAT companies above has
at least 3 of the 5 areas hitting on all cylinders.

~~~
jorkos
Couldn't agree more. I see these companies as much more similar than
different. All of them are very 'user driven' and that's what has made them
such impactful companies.

------
kevindewalt
Jason,

Well-written article, but your thought process follows classic survivorship
bias.

You've extrapolated practices at two of the most successful companies ever
created in the history of capitalism and concluded that "because it seems to
work for them it will work for everyone."

Of course you may well be right, but to conclude that you need to look at
other companies that have followed the same "developer driven" approach. How
many have failed? Succeeded?

Interviewing two people who won the lottery by playing every day but Tuesday
for 5 years doesn't mean I'll win by doing the same.

Again - you might be right - but I can't come to that conclusion based on the
logic described.

For my thoughts on this topic: <http://bit.ly/eKQIKu>

~~~
HoldenCaulfield
This comment reminds me of 'Fooled by Randomness' and 'Black swan' by
Taleb.Logic rules.

------
osuburger
Great article. I think most developers would jump at the chance to be more
involved in "the process"; that is, working hand-in-hand with designers and
not just being given some set of specs to whip up. The more mistakes you make,
the more you learn. Plus, getting products or features into the hands of users
gives you more valuable feedback than any amount of meeting-room discussion
ever could.

------
iamgoat
Bringing developers early on in the process is the key (not necessarily
cutting out the design/product group). While product people come up with the
ideas, developers can really challenge it, ask the "what if" questions, and
think ahead. This extremely helpful type of feedback is hard to find in non-
technical staff.

The #1 person to hire after the founder is the developer. I hear this all the
time. So why would you _not_ give them a voice on the business side? Or
perhaps they had it in the beginning, but as the company grew too many layers
were added. Developers are the problem solvers of the business.

------
tejaswiy
I disagree though, as a developer. It might be unnecessary to have an
incredibly design focussed thinking (but sites like mint.com prove otherwise),
but figuring out how a core feature is supposed to work, and then leaving the
details to devs is how I'd have it. Not just say, okay, lets get picture
sharing on the site.

