Releasing early and often... how it failed for us

http://behindtheclock.timmyontime.com/post/85810187/releasing-early-and-often-how-it-failed-for-us

by dan_sim • 17 years ago

29 42 17 years ago

behindtheclock.timmyontime.com

teej• 17 years ago

I think it's a great idea to occasionally step back, throw away some of your work, and start over. That being said, it's hard to say where they draw this lesson. This post is thin on the details of "how it failed for us".

mtkd• 17 years ago

Not much substance in that post.

However you need to control events and not let events control you. If you react to every tiny issue reported you will end up in a cycle of release-issue-fix-release.

If the issue is only affecting a minority of customers and it's not critical for security - park it - and keep on with the feature plan.

You can't please all the people all the time.

dan_sim7• 17 years ago

I'm testing small posts. Not everybody has the time to read a long post with infinite details about a story when the conclusion is "you lose the grand scheme of what you’re building" and that you sometimes should "wipe your entire work".

swombat3• 17 years ago

Tip: keep the long posts, with a good hook at the beginning and a summary at the end with key points highlighted at the end.

Example: http://danieltenner.com/posts/0005-starting-up-with-a-friend... (still on the HN front page)

trickjarrett• 17 years ago

I don't think short posts are bad, but to make a statement about how something doesn't work for you, you really set us up for a longer more detail filled post. Maybe you revisit it later to re-examine and discuss it in more depth?

tptacek• 17 years ago

I felt like this post kind of wasted my time; it contained so little overt signal that I felt compelled to poke around to find out who this was about and why it would be interesting to me.

The goal isn't "short". It's "concision". You still need to have something to say.

dan_sim7• 17 years ago

I wrote the extented version : http://news.ycombinator.com/item?id=513655

swombat3• 17 years ago

This seems like a poor argument against "release early and release often". First of all it's not all that coherent or structured, and secondly it's very lacking in actual discussion of what went wrong.

It sounds like the author's team got stuck in a bug-fixing cycle where each release caused enough new bugs to fill the next iteration with bug-fixing work. Were they using automated testing? Was the development team good enough to adapt to a rapid release cycle (not everyone can do it)? Too many unknowns to comment on the author's experience...

It's also worth pointing out that nobody said a rapid release cycle was easy. It's hard to keep the vision and the details in mind. As they say, "Programming is hard, let's go shopping".

kristiandupont• 17 years ago

I frequently hear these two arguments against releasing early and often: 1) You will have a primitive product with bugs which means that the people who see it will be turned off and not want to come back later. 2) The argument made in this post, namely that you loose focus and end up putting out fires and implementing feature requests all the time.

As for #1, I just think that it matters very much because the group of early adopters is going to be very small anyway, unless you do some hyped launch like Cuil. Therefore, loosing a couple of users for good can be a small price to pay for the highly valuable feedback that you are bound to get.

#2 is something you have to be concerned about but that doesn't mean that you have to let it control you. And once something is launched, you are bound to get feedback anyway, so it really only applies to the "release early"-part.

cuerty• 17 years ago

Another example of another form of procrastination.

Release often is about getting exited with your product, I about bugfixing as exiting.

flamontagne6• 17 years ago

Like Dan, I think that releasing early and often is a bit overrated as a concept. It was started by 37signals and people have a tendency to read their stuff like it was their bible.

There is definitely a danger to release early and often : You have less time to think about your core idea. If you embark yourself in a quick release cycle without precautions, you have greater chances to forget about the product as a whole and its evolution. This is what happened to us. Now you could say that it happened to us just because we are stupid, but it would be more productive to start cogitating on the implications of bold statements like "Release early and often".

gnaritas2• 17 years ago

It was not started by 37signals, it was popularized by them. The practice has been around much longer as part of extreme programming, as have most of the things they preach.

The 37signals guys are great marketers but about the only thing unique to come from them, the only practice they actually created, was convention over configuration as a core principle. Everything else they just picked up and repackaged from existing extreme programming principles.

spolsky• 17 years ago

It's way earlier than Extreme Programming. Believe it or not, it was once considered a part of Object Oriented Programming. Here's an article from IBM Systems Journal 1993 where I first learned the idea of ship early and often:

http://www.research.ibm.com/journal/sj/323/ibmsj3203E.pdf [PDF]

ewiethoff• 17 years ago

"Release early, release often" is an Extreme Programming mantra which has been around way longer than 37signals. I'm not sure who coined the expression though. Maybe Eric Raymond or Linus Torvalds (http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...).

sho2• 17 years ago

I agree strongly with this comment.

There's such a thing as releasing too early. If the idea is not fully developed, and or its architectural ramifications still being explored, releasing early can trap you and make it far more difficult to evolve your concept.

If you're absolutely sure of what you're doing, what you want it to look like, how it will work, and you're just building gradually towards this well-defined final goal - great, release early and get users on board.

But if you're not sure, don't! Once you get a few users who trusted you and put their time into your project, no matter if it was free or not, you can't just walk away. Well maybe you can but I can't.

When you release something, you ask users to commit to your project. It's unfair to do that unless you're equally committed.

I'm a big fan of private betas, where you can flesh all this stuff out before asking strangers to put their time into your app. Very private betas, if need be - just you. Release early and often - to yourself. Maintain a runnable state at all times. Use your app intensively, eat your own dog food, evolve it that way. I like this kind of advice, not 37Signal's cookie cutter platitudes.

dan_sim7• 17 years ago

We'll be doing private beta in july. Check out http://www.timmyevolved.com to get involved.

lacker• 17 years ago

Looks self-referential. I think this blog post was released too early, before it got any content.

dan_sim7• 17 years ago

I laughed, I must admit.

diN0bot• 17 years ago

what is timmyontime?

c3o• 17 years ago

Time tracking over IM bots. I really like the idea (and the nonexistant signup process!), gonna see how well the implementation works over the next days. http://www.timmyontime.com

markessien3• 17 years ago

Releasing early did not fail for you - it showed you what was wrong with your product. If you had done all those tweaks in silence and expected to come out to a great roar of approval, how do you think you would have felt when faced with a great wall of don't-care?

You released, you saw what the problems were, and now you hopefully have learned from the experience, and can go in a better direction. Just be sure to evolve, do not scratch and try to start afresh.

flamontagne6• 17 years ago

Ehm, no. Releasing early did fail for us. The idea was not mature enough, the "puzzle" wasn't completed but we started developement and released too early.

markessien3• 17 years ago

Did you ever consider that the idea was wrong? And that the 'fail' was just telling you that the idea was wrong?

cmos• 17 years ago

I liked the 'timmyevolved' page.. the music was good and it built up mystique. However, I'm going to forget all about it in another hour or so..you'd better get some attention when you relaunch, and even put out a couple more announcements along the way hinting at what the new site might do.

(then again, it might not matter since I never knew what the old site did)

flamontagne6• 17 years ago

Glad you liked the trailer and thanks for your insights.

dan_sim7• 17 years ago

I wrote the extented version : http://news.ycombinator.com/item?id=513655

jfarmer• 17 years ago

"The often part of release early and often, went really bad. Once that TimmyOnTime was out, we had feature requests, bugs and other critics."

I don't see how this is ad. That shit is DATA. Data informs your future decisions. You're free to incorporate it or ignore it at your will.

Why, you can even act as if the "release" never happened in the first place.

alanthonyc• 17 years ago

you need to separate the principle from the dogma...

apparently, you released too early, too often

10ren• 17 years ago

For release early, release often, you need to know where you are going.

It works especially well if you have a model to copy: Microsoft Windows 1.0, 2.0, 3.0 was based on the Macintosh. Linux was based on Unix.

Or you can have clear vision that you are working towards - in this case, the model you are copying is imaginary.

I guess that's the "Grand Scheme" the article is talking about. You do have to have a way to keep that in mind, and build towards it. You can do this by giving selective attention to the feedback (bug reports, feature requests, complaints) that leads towards your Grand Scheme. This also builds a user base that is aligned with what you want to do (by encouraging those people, and turning off the others). Then your user base supports your vision, instead of undermining it.

You are the captain.

Releasing early and often... how it failed for us

Related Stories