Release early and often or release when ready? - Pros vs Cons

Is one better than the other? Does either provide a greater chance of success? Any examples would be great.

Early - pros

1. The product is never "really" ready
2. You need feedback, you could be totally missing the mark
3. Less expensive to test

Early - cons

1. Not ready
2. Earn a bad reputation which can do long term harm
3. It can be a distraction from your original goals

When ready - pros

1. Solid, well thought out product offering
2. Able to focus more on revenue growth, or simply user acquisition
3. More potential customers

When ready - cons

1. Could be totally wrong product for the market
2. Cost


3. Could be to late, someone else beats you to it

Thoughts?

Variations of this question have been discussed several times with some good answers:

http://www.brightjourney.com/q/companies-failed-released-early http://www.brightjourney.com/q/important-releasing-early-getting-right http://answers.onstartups.com/questions/6060/releasing-early-what-other-steps-can-i-take http://www.brightjourney.com/q/hurt-release-often http://www.brightjourney.com/q/right-time-release-product

100% Ready is a way of saying "it has all the features I thought of, they are tested and work perfectly". This is utopia. You'll never have a finished product. In fact, you need to be in constant beta to ensure your product evolves and people continue using it.

You should tweak the concept of "ready". You product is ready when it provides enough value to people that they start using it. You also need to think of the concept of "instant gratification": they start using the product and get something useful out of it. Otherwise your product will be labeled as useful and die at birth.

If you look at companies like Google, they usually put a Beta version out when they have something solid enough for people to use. Then it stays in Beta for quite a long time.

The fact here is that people don't mind the eventual glitches they'll get from a Beta version (as long as it works well enough). Having a Beta icon somewhere on the product passes the message that the product is not really "ready" yet, and that you intend to gather feedback and evolve what you have.

So my advice is: release earlier rather than later; release a version that works, is stable enough and offers instant gratification; use a Beta label to indicate the state of the product.

Hope this helps

I think it depends on what you are writing, and who your target market is.

For example, if you are writing software that will be mission critical, then releasing early may be very bad, but, if you are writing for a large group, and, as BCSAdvertising mentioned, you don't have a complete picture as to how the application may end up, then releasing it early, but when it is stable, may be useful, to start getting feedback.

But, if you do that you need to have some agile methodology in place, so that you can react quickly to what people are saying, and, you may need to move to cloud computing quickly, perhaps, if you end up needing more resources than you are able to get on your own, so you should be prepared to adapt.

If you go with a limited beta, where you have a smaller number of users then you may get some feedback that is useful, and they may help to steer the product in a reasonable direction, and it is more predictable, but it may not get you to the same place as if you had let more people see what they can do.

I am generally a strong proponent of release early and often, but I am very comfortable with agile methodologies.

No product is ever 100% perfect. With that said, it's morally and ethically wrong to release a product with known data loss defects that can occur under normal circumstances. Morally, because it's wrong to harm the interests of others. Ethically, because it can harm your own reputation.

I went to work at a large software company just after it had shipped a TERRIBLE release of its flagship product, and shortly after I started work there, it began to be apparent that they had released that version while knowing of significant defects including some really shocking data loss bugs. I spent endless hours in bug councils right after joining the company listening to a sickening downward spiral of problems affecting our customers that should have been avoided.

It hurt the company's customers badly and it harmed the company's reputation and the morale of its employees.

The premature release had been dictated by senior management and founders including some engineering people who knew better. Those decision makers, who had all become millionaires already because this was before the end of the dot com bubble, soon departed the company with their millions and left the rest of us to clean up the mess that they had caused. I have never forgotten that experience, and I lost all respect for those who knowingly did that.

It's one thing to release an entertainment product with known flaws so long as no one gets hurt, I suppose (although I would be personally embarrassed by something like that). It's inexcusable to knowingly release a product that will harm your clients or their data.

• Tim

I thought, this would be an easy one. I just defined "ready" to be as early as possible, i. e. the barely usable minimum. Then I started developing and I found that the tough part is deciding what that state should actually look like.

Just this week, more than a year into my enterprise, I finally released. In retrospect, I realize how often along the way I was aiming for the wrong set of functionality. Not because I aimed for too much functionality, but because I repeatedly chose the wrong scope for "more vs less" decisions. I left out things that I thought wouldn't be important, but when I finally did them, so many other things just fell into place, that I wish I had done them first.

In a parallel process, I tried to get people interested in what I was doing, so my understanding of the market also began to evolve, and I was starting to aim for a moving target.

The "minimum" I ended up implementing consisted in a large part of things that weren't even on my list in the beginning.

Now, both my product and my business strategy have been considerably altered between idea and v1. I'm happy to have learned that much, and I feel so much better equipped now, but boy, was it tedious. And all the extra time took large bites out of my budget, too, so I'm left with a lot less time to turn profitable.

How could I have avoided this? If I only knew. And even if I did, the next decisions will have different answers. I've heard it a lot and now I'm experiencing it myself: as an entrepreneur, you're constantly out of your depth.

A quick thought: "feature-complete" and "ready" might not mean the same thing for you and for the user/customer.

I think you should go for a compromise: build a bare-minimum set of features, but rock-solid. Develop the rest as you collect feedback from users/customers, otherwise you might end up with a feature that no-one uses, while you neglected another that is really wanted.