There's a subtle difference here that isn't being highlighted: Releasing often does not mean giving in to feature creep. Feature creep and lack of coherent direction was the failure, not release timing nor release frequency.

Releasing often is about gauging user feedback to evolve features, seeing how user's really use things and discovering what nobody foresaw. That, however, does not mean that you're supposed to give in to each and every feedback request from users. Most of all, releasing early does not absolve you of the responsibility to consider the effect the feature will have, in either its requested form or your translation thereof, on the direction of your product.

To expand on that, your users will have ideas for features that would take your product in a direction that you do not want to go. Releasing often does not mean that you have to go that way. It's perfectly fine to say, "You know what, we're not going to build that," and still keep releasing changes every couple days. Users provide feedback, but ultimately, you control the direction of the product.

So the question becomes: (1) Do you embark on this journey as a ship, taken by the winds and currents of user feedback wherever they may roam? Or, (2) Do you get out some oars and influence your path.

Remember, it was your vision that caused you to start this. You shouldn't discount that just because users want things you're not providing. That's not to say that you shouldn't listen to user feedback, just that you have to decide upon your philosophy and either stand firm with your product direction, be comfortable with having the direction swept out from under you when the site begins to grow, or drift somewhere in between.

I don't think we were the prey of feature creeps. The human factor of wanting to release often caused us to lose our vision. In a perfect world, it wouldn't happen but we're not part of this world.

The article is nowhere near as controversial as the title makes it sound. You released what you called "half-baked" ideas, so it's no wonder it didn't quite work.

Clearly there is a "too early": taking release early and often to its logical extreme you would first release a "Hello World" app then extend in thousands of iterations of 1 line of code, which is clearly nonsense.

Look at the positives - you learned a hell of a lot about your market and development from this experiment, so I'm sure the next version will be a success.

It was half-baked because we felt the urge to release often. I consider this experience very positive, we learned a lot but meanwhile, our product had to fail and now, we have to resurrect it.

But that's not what release often means. If you've got a half-baked idea, then it's half-baked regardless of when and how often you release.

Releasing often has lead us to stop seeing the bigger picture. I think the danger when you release often is to rush the releases... and in the end transform what was a great idea into a half-baked product. I don't want to say that this statement is always wrong, because it certainly isn't, but I think people should approach it with care and stop applying it like it was a God commandement.

> ... but I think people should approach it with care and > stop applying it like it was a God commandement. Isn't that the case with _any_ guideline ?

Guidelines like 'Release early, release often' are just that, guidelines. Take any guideline to its extremes and it will just collapse. They are just there to 'guide' your _thinking_, and that's something no-one else can do for you.

Now, this I can comment on.

As others have pointed out, you should be more hesitant to call this a failure. You've learned a lot about your market, and you've also learned a lot about your vision, by exploring it "hands-on". Would you have gotten that if you'd instead spent 12 months developing your product before releasing it? Probably not. In short, it's best to err on the side of releasing too often than not often enough.

But the more important point is a clear demonstration that you can't replace a project manager with a motto. "Release early and often" is a good practice, but all practices need to be adapted and tailored to your specific project. You can't just follow them dumbly. A project manager's job is to understand the specific circumstances of your project, pick the right practices at the right stage so that your project goes as well as possible, then adapt and evolve those practices as the project goes along. No single practice is ever going to be always right.

To me, you just did everything right. The idea of releasing early & often is to learn about your market, understand what your users really need and what your product should be. Could you have done your 'grand scheme' release without the experience gained during those 2 years?

Writing the post, that's what I realized. The problem is that when we had enough experience, we didn't stop to "release often" and it hurt us more than it helped us.

good point... I fear we're at that stage :-)

Has it "failed"?

You have a user base, and you've experimented with lots of features very quickly. You now you have a very clear idea of what you want, what the market wants, and a sense of how different features and implementations contribute to that.

Did you have such a clear idea at the beginning? Could have have gotten this clarity in any other way?

Prototyping won't tell you the right way, but it gives you concrete terms to think within: by holding some aspects constant, it's easier to reason about the remaining aspects. Prototyping is an aid to thinking.

But I feel your pain; this is an ordeal. It would be so much less frustrating to know how to do everything perfectly in the first place. :-)

As others have already said, to me the definition of "release early and often" doesn't mean "release something as soon as possible". But rather...

Release Early: Find the minimum amount of features needed to let your customer achieve their goal, implement just those and release it.

Release Often: Stage the release of new features rather then letting a load stack up and releasing them all at once. Release feature, receive feedback, refine and repeat (Wow 4 Rs!).

If something is not right or not finished. It should be kept back.

A philosophy shouldn't be the determining factor as to what and when things are released, only you can decide that.

Nice example of how releasing early and often can go bad... on many levels (dual submission)

After bad comments on how short was the first post, here is the new version. We'll see if I get more comments on a short post or a long post.

Of course it won't. You submitted the same story twice, instead of just fixing the first one.