Releasing early and often... how it failed for us(behindtheclock.timmyontime.com)
behindtheclock.timmyontime.com
Releasing early and often... how it failed for us
http://behindtheclock.timmyontime.com/post/85810187/releasing-early-and-often-how-it-failed-for-us
14 comments
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".
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)
Example: http://danieltenner.com/posts/0005-starting-up-with-a-friend... (still on the HN front page)
I think you might be misleading here. Your post about starting with a friend triggered quite a lot of emotions, so its staying not only because of its length.
But you're right that longer posts are more likely to 'catch' the reader
But you're right that longer posts are more likely to 'catch' the reader
I really like your post, I commented it http://danieltenner.com/posts/0005-starting-up-with-a-friend... . But even then, I'd say that I read 80% of it (most time, I read less than 50%). I just said to myself why not cut the post to have a shorter one that people will enjoy a moment. Turned out I was (maybe) wrong. I'll definitely give it another try though...
As a counter-example, I tried to be brief as well in another post on there (http://danieltenner.com/posts/0003-impossible-is-a-step.html) and that one didn't work out very well - when I asked people why they didn't like it, they said it was too short and lacked substance/examples.
I'm a big fan of keeping things as brief as possible, but from what I can tell it's not the best format for the web. I've only seen it work for people who have huge followings already (e.g. seth godin). Even there, most of their posts don't take off...
I could be wrong of course! Good luck to both of us :-)
I'm a big fan of keeping things as brief as possible, but from what I can tell it's not the best format for the web. I've only seen it work for people who have huge followings already (e.g. seth godin). Even there, most of their posts don't take off...
I could be wrong of course! Good luck to both of us :-)
Problems with releasing early and often, eh? Have you tried Erlang?
Sorry -- I'm still getting that out of my system.
Seriously, as smombat points out, posts are much better if you tell the story of how you got to where you are and why you made the decision you did. That gives the rest of us some context. For the most part, broad, sweeping statements are false. Especially in IT, where there's too many edge cases. So the details of your particular situation are what adds value to the reader.
Sorry -- I'm still getting that out of my system.
Seriously, as smombat points out, posts are much better if you tell the story of how you got to where you are and why you made the decision you did. That gives the rest of us some context. For the most part, broad, sweeping statements are false. Especially in IT, where there's too many edge cases. So the details of your particular situation are what adds value to the reader.
I didn't want to write a "statement" and that's why I said that it failed for us. I just wanted people to think a little before they release early and often. About how could it fails for them.
Yes, and to get people to think about how it could fail for them, you need to paint a picture in their mind of how it failed for you -- so they can emotionally connect. Otherwise you're just writing one-line platitudes: think about how you release, be sure to debug, think about design before coding, etc.
It's all good stuff, no doubt, but without a frame to pull the reader in it loses a lot of impact.
It's a style thing. Do what comes natural to you. I didn't like your post, because to me there was nothing there. I already know that teams that don't think about the big picture and just push to release get caught in a tweak-debug-release cycle. That's just me, though. Personally I would have enjoyed learning if you started off with a design, what happened to it? Who was driving your release cycle? How often was too often for you? Did you have a master release plan that you threw away, or did you never think that far ahead? Etc. It's the details of the thing that matter: everybody already knows the one-liner (or think they do)
That's just me. No worries here. Glad to see you writing and submitting. Look forward to reading more of your work.
It's all good stuff, no doubt, but without a frame to pull the reader in it loses a lot of impact.
It's a style thing. Do what comes natural to you. I didn't like your post, because to me there was nothing there. I already know that teams that don't think about the big picture and just push to release get caught in a tweak-debug-release cycle. That's just me, though. Personally I would have enjoyed learning if you started off with a design, what happened to it? Who was driving your release cycle? How often was too often for you? Did you have a master release plan that you threw away, or did you never think that far ahead? Etc. It's the details of the thing that matter: everybody already knows the one-liner (or think they do)
That's just me. No worries here. Glad to see you writing and submitting. Look forward to reading more of your work.
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.
The goal isn't "short". It's "concision". You still need to have something to say.
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?
I wrote the extented version : http://news.ycombinator.com/item?id=513655
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".
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".
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.
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.
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.
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.
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.
Did you ever consider that the idea was wrong? And that the 'fail' was just telling you that the idea was wrong?
Yeah we did consider that. But we arrived at the conclusion that the idea was still great.
Do you have numbers to prove that your idea is great? Having been launched for a while, it should be pretty easy to rearrange traffic data in such a way that it gives you a benchmark as to how relevant your idea is to people.
(Forgive me, but I like using numbers as a basis for decisions)
(Forgive me, but I like using numbers as a basis for decisions)
We know that idea is relevant because 1) WE find it relevant and 2) by the initial comments we are receiving from our users. Most are in love with the idea... but after that they feel let down. The problem is how the idea is executed, not the idea itself.
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.
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.
I wrote the extented version : http://news.ycombinator.com/item?id=513655
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".
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".
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.
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.
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]
http://www.research.ibm.com/journal/sj/323/ibmsj3203E.pdf [PDF]
I'll add that "Extreme Programming" and other forms of Agile is mostly a buzzword/re-branding to wrapper quite a few "best practices" from the OOP world. Which is appropriate since so many of the early agile manifesto folk were the same ones that pioneered the OOP best practices.
Oh I believe it, I wasn't trying to imply the practice came from extreme programming, only that that's where I encountered it first.
"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...).
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.
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.
We'll be doing private beta in july. Check out http://www.timmyevolved.com to get involved.
Well, OK .. but I have no idea what your application is even for. Timmy? Evolved? That means nothing to me. Who or what is Timmy? And don't say "go and find out" - why should I have to go and research what the nature of your product is?! I've already visited the web site, and it didn't say!
I'm sure you and your team are well versed in everything to do with Timmy, but please understand that no-one else has any idea what you are talking about. Uh-huh. I see a lot of lightning. That's a nice slideshow you put together there. Very impressive. I might look at the source to see how you did it. WTF is Timmy?
Imagine I pointed you to a link called Michael Evolved, with a nice slideshow and music, telling you that now, Michael is moving to the Next Level! Sign up now for the Michael private beta! You visited the link. You gave it several minutes of your attention. You have no fucking idea what it is talking about. You'd be posting the exact same thing back to me. Who, or what, is Michael? Who knows! Maybe ask Timmy!
I'm sure you and your team are well versed in everything to do with Timmy, but please understand that no-one else has any idea what you are talking about. Uh-huh. I see a lot of lightning. That's a nice slideshow you put together there. Very impressive. I might look at the source to see how you did it. WTF is Timmy?
Imagine I pointed you to a link called Michael Evolved, with a nice slideshow and music, telling you that now, Michael is moving to the Next Level! Sign up now for the Michael private beta! You visited the link. You gave it several minutes of your attention. You have no fucking idea what it is talking about. You'd be posting the exact same thing back to me. Who, or what, is Michael? Who knows! Maybe ask Timmy!
There's some truth in what you are saying. We could put a link somewhere pointing to timmyontime dot com so people can have a better idea of what we are talking about.
By the way, are you angry or something? I don't understand why you are pissed off like that.
By the way, are you angry or something? I don't understand why you are pissed off like that.
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)
(then again, it might not matter since I never knew what the old site did)
Glad you liked the trailer and thanks for your insights.
"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.
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.
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".
Another example of another form of procrastination.
Release often is about getting exited with your product, I about bugfixing as exiting.
Release often is about getting exited with your product, I about bugfixing as exiting.
what is timmyontime?
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
you need to separate the principle from the dogma...
apparently, you released too early, too often
apparently, you released too early, too often
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.