Release Late, Release Rarely (2006) | Hacker News Reader

Release Late, Release Rarely (2006)

aaronsw.com

55 pointsalexandros32 comments

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

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

Perhaps additionally, it's because there is always counter perspective that, for somethings, ring true.

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.

bad first impression > no first impression

My personal favorite:

Why I (don't|switched)+ (use|to)+ X

Why I switched use X?

Yes, and technically this could also generate

   * Why I don't switched use to X
   * Why I don't don't don't to to to to X

etc...

I think we need:

Why I (don't use|switched to){1} X

I think he meant something like:

Why I (did|will) (not)? (use|switch to) .+

Haha, only on HN.

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

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.

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

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.

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

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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

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!

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

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

But seriously, wow. That is bad advice.

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.

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.

Reply on news.ycombinator.com