11 ms·

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

29 points by dan_sim 18y ago

teej 18y 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 18y 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_sim 18y 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".
  - swombat 18y 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.html http://danieltenner.com/posts/0005-starting-up-with-a-friend... (still on the HN front page)
    - DanielBMarkham 18y ago
      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.
      - dan_sim 18y ago
        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.
        DanielBMarkham 18y ago
        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.
    - dan_sim 18y ago
      I really like your post, I commented it http://danieltenner.com/posts/0005-starting-up-with-a-friend.html#comment-7098609 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...
      - swombat 18y ago
        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 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 :-)
    - AlexTheFounder 18y ago
      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
  - trickjarrett 18y 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 18y 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_sim 18y ago
  I wrote the extented version : http://news.ycombinator.com/item?id=513655 http://news.ycombinator.com/item?id=513655
swombat 18y 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 18y 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 18y ago
Another example of another form of procrastination. Release often is about getting exited with your product, I about bugfixing as exiting.
flamontagne 18y 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".
- gnaritas 18y 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 18y 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 http://www.research.ibm.com/journal/sj/323/ibmsj3203E.pdf [PDF]
    - gnaritas 18y ago
      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.
    - jhancock 18y ago
      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.
lacker 18y ago
Looks self-referential. I think this blog post was released too early, before it got any content.
- dan_sim 18y ago
  I laughed, I must admit.
diN0bot 18y ago
what is timmyontime?
- c3o 18y 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 http://www.timmyontime.com
markessien 18y 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.
- flamontagne 18y 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.
  - markessien 18y ago
    Did you ever consider that the idea was wrong? And that the 'fail' was just telling you that the idea was wrong?
    - flamontagne 18y ago
      Yeah we did consider that. But we arrived at the conclusion that the idea was still great.
      - markessien 18y ago
        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)
        flamontagne 18y ago
        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.
cmos 18y 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)
- flamontagne 18y ago
  Glad you liked the trailer and thanks for your insights.
dan_sim 18y ago
I wrote the extented version : http://news.ycombinator.com/item?id=513655 http://news.ycombinator.com/item?id=513655
jfarmer 18y 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 18y ago
you need to separate the principle from the dogma... apparently, you released too early, too often
10ren 18y 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.

29 points by dan_sim 18y ago

teej 18y 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 18y 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_sim 18y 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".
- swombat 18y 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.html http://danieltenner.com/posts/0005-starting-up-with-a-friend... (still on the HN front page)
  - DanielBMarkham 18y ago
    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.
    - dan_sim 18y ago
      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.
      - DanielBMarkham 18y ago
        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.
  - dan_sim 18y ago
    I really like your post, I commented it http://danieltenner.com/posts/0005-starting-up-with-a-friend.html#comment-7098609 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...
    - swombat 18y ago
      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 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 :-)
  - AlexTheFounder 18y ago
    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
- trickjarrett 18y 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 18y 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_sim 18y ago
I wrote the extented version : http://news.ycombinator.com/item?id=513655 http://news.ycombinator.com/item?id=513655

swombat 18y 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 18y 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 18y ago

Another example of another form of procrastination. Release often is about getting exited with your product, I about bugfixing as exiting.

flamontagne 18y 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".

gnaritas 18y 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 18y 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 http://www.research.ibm.com/journal/sj/323/ibmsj3203E.pdf [PDF]
  - gnaritas 18y ago
    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.
  - jhancock 18y ago
    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.

lacker 18y ago

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

dan_sim 18y ago
I laughed, I must admit.

diN0bot 18y ago

what is timmyontime?

c3o 18y 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 http://www.timmyontime.com

markessien 18y 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.

flamontagne 18y 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.
- markessien 18y ago
  Did you ever consider that the idea was wrong? And that the 'fail' was just telling you that the idea was wrong?
  - flamontagne 18y ago
    Yeah we did consider that. But we arrived at the conclusion that the idea was still great.
    - markessien 18y ago
      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)
      - flamontagne 18y ago
        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.

cmos 18y 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)

flamontagne 18y ago
Glad you liked the trailer and thanks for your insights.

dan_sim 18y ago

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

jfarmer 18y 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 18y ago

you need to separate the principle from the dogma... apparently, you released too early, too often

10ren 18y 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.