

Releasing early and often... how it failed for us [extended version] - dan_sim
http://behindtheclock.timmyontime.com/post/85858089/releasing-early-and-often-how-it-failed-for-us

======
RWilson
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.

~~~
dan_sim
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.

------
amouat
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.

~~~
dan_sim
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.

~~~
unalone
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.

~~~
flamontagne
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.

~~~
willemv
> ... 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.

------
swombat
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.

------
cedsav
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?

~~~
dan_sim
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.

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

------
10ren
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. :-)

~~~
theBobMcCormick
Agreed. Releasing early and often didn't fail them. It sounds like they found
out a _lot_ about their users, they found out a lot about what their
application should _really_ be and how it should really work.

They also found out that releasing early and often doesn't mean you _have_ to
develop and release every half baked new feature idea as soon as it pops into
your head! :-)

------
Hates_
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.

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

------
dan_sim
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.

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

