Isegoria

First-Mover Advantage is an idea that just won’t die, Steve Blank says:

The phrase “first mover advantage” was first popularized in a 1988 paper by a Stanford Business School professor, David Montgomery, and his co-author, Marvin Lieberman.[1]

This one phrase became the theoretical underpinning of the out-of-control spending of startups during the dot-com bubble. Over time the idea that winners in new markets are the ones who have been the first (not just early) entrants into their categories became unchallenged conventional wisdom in Silicon Valley. The only problem is that it’s simply not true.

The irony is that in a retrospective paper ten years later (1998), [2] the authors backed off from their claims. By then it was too late. Using this idea to differentiate themselves as the hot new Silicon Valley VCs, some of his former business school students made this phrase their rallying cry. Soon every other VC was using the phrase to justify the reckless “get big fast” strategies of dot-com startups during the Internet Bubble.

In fact, a 1993 paper by Peter N. Golder and Gerard J. Tellis had a much more accurate description of what happens to startup companies entering new markets.[3] In their analysis Golder and Tellis found almost half of the market pioneers (First Movers) in their sample of 500 brands in 50 product categories failed. Even worse, the survivors’ mean market share was lower than found in other studies. Further, their study shows early market leaders (Fast Followers) have much greater long-term success; those in their sample entered the market an average of thirteen years later than the pioneers.

James Hague offers some advice to all those aimless, excited programmers, who want to make something using the latest technology that has caught their eye:

Stop and think about all of your personal interests and solve a simple problem related to one of them. For example, I practice guitar by playing along to a drum machine, but I wish I could have human elements added to drum loops, like auto-fills and occasional variations and so on. What would it take to do that? I could start by writing a simple drum sequencing program–one without a GUI–and see how it went. I also take a lot of photographs, and I could use a tagging scheme that isn’t tied to a do-everything program like Adobe Lightroom. That’s simple enough that I could create a minimal solution in an afternoon.

The two keys: (1) keep it simple, (2) make it something you’d actually use.

Once you’ve got something working, then build a series of improved versions. Don’t create pressure by making a version suitable for public distribution, just take a long look at the existing application, and make it better. Can I build an HTML 5 front end to my photo tagger?

If you keep this up for a couple of iterations, then you’ll wind up an expert. An expert in a small, tightly-defined, maybe only relevant to you problem domain, yes, but an expert nonetheless. There’s a very interesting side effect to becoming an expert: you can start experimenting with improvements and features that would have previously looked daunting or impossible. And those are the kind of improvements and features that might all of a sudden make your program appealing to a larger audience.