Jeff Atwood is not the only one recommending, or rather urging software teams to release early and not delay shipping because the product is not perfect. Jason Fried from 37 signals makes a good case of shipping early for a startup: waiting a year before putting something in front of the users is too long, 3 months is a much better strategy. Get feedback early, so you can improve the design, understand what works and what doesn’t, get a feel for what features would get people to pay for your service, and how much they’d be willing to pay. Jeff Atwood points out that shipping early is not about shipping crap, but rather it’s about not postponing the moment when you start getting useful feedback because you’re scared of not having done the most perfect job.
I would add one sole variable to whether shipping early is a good strategy or not: expectation, as in expectation from the consumer, the customer, or the user.
Sure, when you are a startup hoping to make money with a new Internet service, I see little reason why you should not thrive to get something out as soon as possible. What is the worst thing that could happen? No user. Even bad feedback is useful. Okay, maybe having another company take your idea, implement it better in record time is the worst that could happen. The assumption is you’ll take big steps as soon as you ship and you can make better decisions for the future. What is the expectation of the users? Not very high: you’re a startup, you put a big beta in the title, you humbly demand users to give it a try and give you feedback, good and bad. The expectation is low because as a startup, you probably don’t want it to be very high, and even if you did, you’re probably not asking for money anyway to try it out. Users don’t pay for your Beta 0.9 version, thus their expectation is low, and their tolerance to non perfect code is high.
What happens now when you’re a much bigger company, your marketing group publicizes the shit out of an upcoming product (months in advance) and the user is going to pay, sometimes a lot, for this product? The expectation is high, and you’d better not screw it up. Imagine Apple releasing their next product with a beta version of the software. Exactly, it’s hard to imagine because they wouldn’t. When the expectation is high – whether it is from buying the product or from big ad campaigns – it is very hard to evaluate the damage done to the product and the company (in terms of revenue and image) if the product delivered does not meet the expectation of the consumer. Another bias that screws the good judgment of people for when a new product should be released in a big company are the individual or team objectives defined as part of whatever evaluation process is being used. Maybe the product team will get the bonus if the product is shipped on time, no matter what the consequences. Or the team gets the bonus if the product has no bug, and will never ship or eventually ship with a huge delay. Missing anything better to suggest, I would say: pick the person with the best common sense and good judgment (whatever that means for your company) and give full power to that person to decide whether to ship or not.
Other than that, I can think of a few strategies that companies use to reduce the risks of under delivering:
- They ship a lot of different products, trying to compensate the failure of some with the success of others.
- They cultivate a public Beta sandbox where they explicitly keep consumer’s expectation lower (they call it more glamorously: explore, discover new ideas, experience earlier, evaluate and influence emerging technologies) than for their other products: Google Labs, Nokia Beta Labs, Adobe Labs, Sun Labs, Microsoft Office Labs, etc.
- The software is Open Source, thus bears the seal of “you can’t complain if there are bugs, fix them yourself”.
There are other aspects to take into account in the decision to ship early or not. Is the software coming with a device? How fast can you update the software? Shipping early software that works in a browser is less risky than shipping software that the user needs to install, which is usually itself less risky than shipping software that comes embedded in a device. And things get even more complicated when you make an OS and applications (like for phones). No matter what you ship, one important requirement that you need to establish and do a really good job of at the very first released version is the update mechanism. If updating is quick and easy (does not require the user to do anything, or not much more than clicking OK), bugs will get fixed and the user experience will improve steadily. Mess up that part and you ruin your chances of making the user happier. And if you ship early because you want feedback early, make sure you have a great feedback mechanism too.
