(The following is consolidated notes from the talk at the Startup meetup put on by the YCombinator folks, which I found to be a very enjoyable event and hope they put on again soon)
Conduit Labs had the longest incubation period (eg. no outside users) of any of the dozen or so product launches that I've been a part of in my still relatively early career in startups. Although we still erred on the side of releasing as early as possible, this long incubation period left me with a couple of thoughts on the old mantra of releasing early and often.
Suffice to say that you have likely heard that releasing early and often is a good idea. I first read this in writing somewhere in the mid 90s in The Cathedral and the Bazaar, and still believe it is perhaps one of the more eloquent explanations of why it is important. Eric Raymond described Linus treating his users as co-developers with a voice in the growth of the product. Or has he put it,
"keeping his hacker/users constantly stimulated and rewarded - stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work."
But I think there is an equally important reason for releasing early that folks don't talk about very often, namely the effect of positive user feedback on the culture of your development team.
The best way I can explain this is to tell a short anecdote about Mark Spitz (which seemed relevant considering the recent Olympics). Spitz went into the 1968 Olympics holding 10 world records in swimming, so think of him in the Larry and Sergey world of talent. After brashly predicting he would win ten golds, he messed up the start of his very first swim which caused him to finish dead last. This killed his confidence leading to him getting "just" two golds.
After bombing at the '68 Olympics, Spitz got gold in his first event at the '72 Munich games. As he tells it, this early win lifted his confidence and was the catalyst for him to go on take seven gold medals, a record that stood for 36 years until Michael Phelps just broke it. This is the relative importance of that first release of your product, and points to the problems that can arise in taking an early release too casually. Positive feedback loops snowball, but so do negative feedback loops. And a world class group of start-up talent, on the order of Spitz, can get derailed for years or even permanently if they mess up that first release.
Startups, like most things, are a head game. It's best you set the culture of your company up for success.
Paul Graham cites these twin problems in his essay, The 18 Mistakes that Kill a Startup, where his #8 is about launching to slow, and #9 is about launching too fast. We hear a bunch about not launching too slow, and maybe not enough about making sure the first step out is going to be a solid one. It is indeed important, even critical, to allow yourself the ability to "fail quickly" so you can move on and improve the product. But a complete failure (no traction, no positive feedback, no real way for users to engage and understand your service) is not only bad for self esteem, it gives them nothing to attach to and build from.
This is just a friendly bit of counter-pressure to the constant drum beat of releasing early. All startups are riddled with failures, so you can't be afraid of releasing because of failure. But if there is a great instinct I constantly see in entrepreneurs it's the ability to look at the primordial goo of an early product and see the little nugget that is working well enough to sprout 100 new ideas. I'll talk a little more about what it means to see that bit next week.
I completely completely agree with this. I love agile and frequent iteration based product development, but you can really blow public opinion and team confidence if your first foot forward is too shoddy.
Posted by: Giff | September 11, 2008 at 11:31 AM