Version 1 Sucks, But Ship It Anyway
codinghorror.com
codinghorror.com
Version 1 sucks. Ship it anyway? Yeah, Cuil can tell you how well that worked out.
Clearly, the decision to ship is one that should be taken seriously, and the pros and cons of shipping need to be weighed. There's an upside to shipping early (feedback from users) but there are a lot of potential downsides as well.
But we all knew that already, didn't we?
Cuil didn't just ship; Cuil was launched Hollywood style with a tremendous amount of anticipation and buzz. If they had soft launched, their fail wouldn't have been nearly as epic.
another important point I think that is part of the same, design your product in a way that allows you to ship early. forget about all the bells and whistles before you launch, think of the simplest possible thing that is useful.
this is a concious process and a bit different from just losing the fear of launching 'bad' stuff.
A. "spending three months fixing up this version in a sterile, isolated lab"
OR
B. "listening to feedback from real live, honest-to-god, dedicated users of your software."
You shouldn't need to 'ship' in order to get feedback from potential users. You should be engaged with them early-on, during the design and development of your product.
I would revise Jeff's argument to read: "Don't develop in a vacuum. Get feedback as early on as possible. If you need to ship something in order to get that feedback, then so be it, but that's risky. "
For instance, before we launched a version of our software, we spent two months working on security mechanisms to make sure it couldn't be stolen or pirated or hacked. While security is important, it was a mistake for us to take it as seriously as we did, and we wound up wasting those resources in hindsight.