What I Learned from Zuckerberg's Mistakes(launch.is)
launch.is
What I Learned from Zuckerberg's Mistakes
http://launch.is/blog/2010/12/14/launch002-what-i-learned-from-zuckerbergs-mistakes.html
11 comments
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.
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...
Once again "vak" is trade/profession/"subject area" and "idioot" means well idiot.
http://www.proz.com/kudoz/dutch_to_english/other/833923-vaki...
Yeah I hear you.
in Danish fag is trade/profession/"subject area" and idiot means well idiot.
Although it has negative connotations it's accepted.
in Danish fag is trade/profession/"subject area" and idiot means well idiot.
Although it has negative connotations it's accepted.
This is a very good comment. I feel like this point is not appreciated enough. I've been in on meetings where people get very passionate about the subject under discussion. I have seen people become stubborn. I have seen people lose their temper. I have seen meetings drag on for 5 hours. Yet usually the subject under discussion did not deserve the intensity with which it was discussed.
Even when a subject is very important, in a startup, we often have to deal in a vacuum of data, so why fight, when really, neither of us can be sure of our position? Why not just move passed the issue and come back to it 3 months later, when more data might be available?
People underestimate how expensive time is. This is especially true in a startup. And the less people are paid, the more this is true - people underestimate how expensive it is to spend time discussing X, when we could be doing Y. Everything has an opportunity cost, but these are hard to see.
Even when a subject is very important, in a startup, we often have to deal in a vacuum of data, so why fight, when really, neither of us can be sure of our position? Why not just move passed the issue and come back to it 3 months later, when more data might be available?
People underestimate how expensive time is. This is especially true in a startup. And the less people are paid, the more this is true - people underestimate how expensive it is to spend time discussing X, when we could be doing Y. Everything has an opportunity cost, but these are hard to see.
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.
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.
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.
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.
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.
In case of Apple, GavinB is actually spot on.
Apple is all about design but not in the way it's often used (visually).
Apple is all about design but not in the way it's often used (visually).
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
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
This comment reminds me of 'Fooled by Randomness' and 'Black swan' by Taleb.Logic rules.
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.
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.
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.
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.
[deleted]
[deleted]
"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.