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

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.

I think twitter is a great example of this.

Disclaimer: These are all just my assumptions.

I saw this video where the creator of twitter talked about the product's inception. They were actually working on another product and in the process of working on it they created a side program that simply served to help the process. Twitter was built to be used around mobile devices so they can shoot short messages to one another to better coordinate their collaborative efforts. The program turned out to be so unique and interesting they ended up releasing it to the public.

So here's what they didn't do when twitter was unleashed to the masses. They left it open ended and wanted its users to define twitter's ultimate functionality. So it was never specified that you should synchronize it to your phone. People set up their accounts online and started using it behind the computer, naturally, and here are the result.

Twitter is a program designed around mobile phones, specifically to be used in group coordination and sharing relevant information at the inception of a need or thought at the instant of its necessity; because it needs to be heard then and there so that others may share in that experience as it plays out. Anyone who uses twitter is aware of the junk feeds. But why is that information junk or associated with spam. Mobile social networking is all about the necessity and relevance of information at specific points in time, but when users are on twitter behind the computer they treat that information differently with regards to time and its suggested relevance, which is lost with time. They don't recognize that in the span between 1 minute after a tweet and 10 minutes after a tweet that information lives out an entire life and dies, and should that information hold no temporal relevance whatsoever, then it never held any relevance to the world of active listeners experiencing the world at its very instant anyway.

So to answer your questions with regards to early release.

My idea is that the two dominant functions of twitter, behind the computer use and mobile synchronization, are counterintuitive in the way its relevant duration of content is treated by its users. And I believe that it's because of this functional ambiguity that has triggered such mass appeal, incredible growth, complete incomprehension of its underlying functions, and thus its notorious drop off rate of over 60% (which I would actually put at 80%+).

If you put it out early before it's really defined, you might actually get more people to use it than putting it out with specified functions appealing to specific demographics. However if you run into a situation where the users are stepping on each other's toes they will leave and all you'll end up with are a bunch of unused accounts with birds for avatars.

That's just one scenario.

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

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.