

Release Late, Release Rarely (2006) - alexandros
http://www.aaronsw.com/weblog/rlrr

======
jganetsk
I've noticed that there's a simple formula many bloggers use to come up with
titles for posts.

1) Take famous other blog post title, book title, or meme

2) Negate

3) Apply DeMorgan's law

~~~
Alex3917
The reason bloggers give their posts these kinds of titles is because they get
more readers. I don't like doing this on my blog, but on the other hand it
really sucks when you spend eight hours writing something and it only gets
twenty readers and no comments. (When you could get 20,000 reads by saying the
same thing but with a more provocative title.)

~~~
roc
Which is only a true improvement if the other 19,980 readers necessarily
contribute to ... whatever it is you're shooting for.

To quote the article: _You only get one chance to make a first impression; why
have it be “junk”? Once that’s associated with your name or project, it’s
tough to scrape off._

~~~
vaksel
bad first impression > no first impression

------
aaronsw
My 2008 thoughts on this are here: <http://www.aaronsw.com/weblog/howtolaunch>

~~~
ALee
Btw aaron, your talk at Startup Bootcamp was great. I didn't realize you were
such a great speaker. All those years with Lessig really paid off.

------
mrshoe
_> Releasing means showing it to the world._

It does if you're Apple, but it doesn't if you're me. You tell me how I can
get the entire world to check out my little startup (<http://shoptalkapp.com>
;) ) and then I'll take your advice and polish the heck out of it before I
release it.

This article applies very well to large companies who get lots of publicity.
They need to be careful not to release junk, because everyone is watching
them. For startups like mine, releasing means trying to show it to the world,
but actually only showing it to a small group of people.

------
ryanelkins
It hink it really depends on product. Even within the world of software, as
always - it depends.

Example: Blizzard Entertainment. They are well known for releasing "When it's
Done." or fixing things "Soon". It would be hard to argue taht the strategy
hasn't paid off for them. I'm not sure if a large MMO or RTS is really the
kind of software that can best benefit from having a minimal feature set.

I think it's important to know your audience when writing something,and this
article seems somewhat out of context without knowing who the intended
audience was.

~~~
req2
"When it's done" doesn't tell the whole story for Blizzard. They continue to
patch and support Starcraft, and they are currently working on a sizable
content patch for Diablo II. WoW has been constantly receiving additional
content and balance updates. Blizzard goes a little bit beyond all that, a
remarkable trait in such a 'now' focused games industry.

------
csallen
Sure, if you're Apple and you make expensive hardware, you don't want your
initial release to suck. It's just too hard to make changes after the fact.
Software, on the other hand, is cheap to produce. You can afford to release
early and often, because releasing fixes and improving features is quite
doable. If you release late and rarely, how are you going to improve your
application? How are you going to know what users want? How are you going to
know if your idea is headed in the right direction? Simple: you won't. You'll
spend all your time, effort, and money building the wrong thing. At best
you'll get a ton of users for a few weeks when you launch, and that'll be
that.

------
akkartik
It's more nuanced than whether you release early or late. I've noticed a lot
of startups that release early because "well, that's what you're supposed to
do," but then the feedback comes in and they're ill-equipped to deal with it.

Release early when you can release often, but not earlier. Often this requires
some meta-thinking about the space your app is in, the alternatives you may
need to switch to, and how easily you can turn on a dime. Good design, in
other words.

Another thing you can benefit from is good infrastructure and processes for
listening to users. As an extreme but perhaps strawman example, in some
consumer-web spaces there's little point in releasing an app without being
able to A/B test. Build that capability in before you launch.

"Release early, release often" helps evoke the right mindset around launching:
save your A game for the time after launch, not the weeks before. Don't build
up the launch. Don't set a deadline, round up the press, create an embargo,
and work unsustainably late hours to meet the deadline. That way you'll be
tired when launch happens. You'll have a celebration, folks will ease up for a
day or week, some will even take vacation, until eventually someone notices
that _nothing happened_. Instead, focus on the process. Be blase early on:
"This ol' thang, yeah we develop in public, and release all the time." You
aren't done when you launch, you're just getting started. Ramp up the velocity
after you start getting noticed, because now you have less room for manoeuvre.

Whatever you do, don't focus on the first half of "Release early, release
often," and ignore the second.

~~~
ams6110
And I would add, release early and often only if releasing is easy. I worked
in an shop that was trying to be "agile" with an enterprisey consultingware
kind of product. They tried to release every 6 weeks or so, but the releases
were complicated to deploy and deployments were additionally complicated by
their customers' own change management processes that made the releases flow
like cold molasses.

They ended up with releases backed up two or three cycles at some customer
sites, customers who could not cope and only wanted every other (or every
third release), which created a support nightmare and customers who felt the
software was in a never ending state of flux.

So, if your releases involve a "download this zip file and extract it here"
kind of process, it's a lot more feasible to do the early/often thing. If your
releases require dispatching an engineer on a site visit, maybe not such a
good idea.

------
RevRal
This is true of a lot of trades.

Music and writing. Do not let people in on your work, unless they're privy and
trusted.

It is hard for average people get excited about your intentions, if it isn't
presented properly.

In fact, it is all about presentation. Look at the average response to the
awesome explosions in Transformers. It would take more words to describe the
functions of Notepad than to describe what is going on in the too long eye-
candy scenes of that movie.

Hell, look at the bible. Why do we need long parables to describe simple
ideas?

From This is the Dreamtime blog post by Robin Hanson
([http://www.overcomingbias.com/2009/09/this-is-the-dream-
time...](http://www.overcomingbias.com/2009/09/this-is-the-dream-time.html)):

 _We were built to be influenced by the rhetoric, eloquence, difficulty,
drama, and repetition of arguments, not just their logic. Perhaps this once
helped us to ally us with high status folks. And we were built to show our
ideals via the stories we like, and also to like well-crafted stories. But
today we are exposed to arguments and stories by folks far more expert than
found in ancestral tribes. Since we are built to be quite awed and persuaded
by such displays, our beliefs and ideals are highly influenced by our writers
and story-tellers. And these folks in turn tell us what we want to hear, or
what their patrons want us to hear, neither of which need have much to do with
reality._

------
tonystubblebine
For a much better take on releasing late, try Dick Costolo's (FeedBurner
founder) Launch Late to Launch Often:
[http://www.burningdoor.com/askthewizard/2007/03/launch_late_...](http://www.burningdoor.com/askthewizard/2007/03/launch_late_to_launch_often.html)

------
jon_dahl
This article assumes that "the public" is a homogeneous group. In reality, if
you want to release a polished, useful app to "the public" (i.e. a median
target user), you probably need to release early and often to _early adopters_
first.

~~~
Perceval
That's the point of his article. He says open source works because you
'release early, release often' to a group of insiders, not the public. Hence
why we have multiple release channels: trunk nightlies, branch nightlies,
closed betas, public betas, and official releases.

His point is not to 'release early, release often' to the unwashed masses, but
to 'release late, release rarely' to the public so they get a polished,
finished product.

------
stevoski
There is a false assumption in this article: that the whole world will see and
remember your initial release. The reality is - unless you are a big company
like Apple - your initial release will attract almost no attention. But you
may get some helpful feedback.

"You don't get a second chance to make a first impression", goes the
conventional wisdom. Actually you do. You get second and third and fourth and
more chances because there are a lot of people on this planet of ours.

~~~
eli_s
i think the point is you don't get a second chance with the people who have
already written you off - add a couple of negative blog posts here and there
and you may end up with a lot of negative publicity to overcome.

~~~
eru
Change your name, then. If its so early in the game, nobody recognizes your
company / product anyway.

------
mauricio
The whole article is flawed. The article, minus the title, implies that he is
arguing you shouldn't Release Early, Often but rather Release Ready.

The title, however, implies you should miss deadlines regardless of your
readiness and you should never update. Wtf?!

~~~
gloob
Perhaps I'm displaying a lack of sophistication, but by my reading, the title
"implies you should miss deadlines...and you should never update" in the same
way that "worse is better" implies that shipping a ten-line random number
generator is an acceptable solution to all problems. I mean, that would be
worse than that database app the bank wanted, right? So it must be better!

------
gfodor
Eagerly waiting for the controversial "Don't release" response screed.

------
gcheong
So you mean all these versions of OS X I bought is just Apple doling out
software it already had in the can?

------
aazeemazhar
But seriously, wow. That is bad advice.

~~~
McP
Can you explain why you think that? I disagree with you, for many (most?)
products the "release early, release often" philosophy simply isn't
appropriate.

------
eli_s
I think it really depends what type of industry you're entering. If you're
breaking new ground and creating something truly original then you can get
away with releasing early and often - your audience is going to be made up of
early adopters who are more tolerant of issues.

However if you're building a product for a well established industry e.g. if
you were building new shopping cart software you would be entering a saturated
market full of knowledgable potential clients and full featured alternatives.
In this case you need to release when your feature set matches or hopefully
exceed that of your competitors.

