Wimps Wait. Revolutionaries Release Early.

About This Blog

This site is for  entrepreneurs.  A full RSS feed to the articles is available.  Please subscribe so we know you're out there.  If you need more convincing, learn more about the site.

Community

Google+

And, you can find me on Google+

Connect on Twitter

Get Articles By Email

Your email:

Google

Blog Navigator

Navigate By : 
[Article Index]

Questions about startups?

If you have questions about startups, you can find me and a bunch of other startup fanatics on the free Q&A website:

Answers.OnStartups.com

Subscribe to Updates

 

30,000+ subscribers can't all be wrong.  Subscribe to the OnStartups.com RSS feed.

Follow me on LinkedIn

OnStartups

Current Articles | RSS Feed RSS Feed

Wimps Wait. Revolutionaries Release Early.

 

If you are not a believer in “Release Early, Release Often” you can safely stop reading now.  No sense in clouding your passionately held opinions with my passionately held, and ill-defended opinions.  My best wishes to you.

On the other hand, if you’re as passionate about the power of the “Release Early” model  as I am, then this article is just for you. 

If one of these tickles your fancy, please feel free to share it.  Lets improve the world, one waiter at a time.  [waiter, as in “one who waits”.  Oh wait, those kinds of waiters wait too.  Screw it, you know what I mean].

Enjoy.

14 Sound Bites And Insights On Releasing Early

1.  Wimps wait.  Revolutionaries release early.

Suggested reading:  “Rules for Revolutionaries” by Guy Kawasaki.  Guy’s my hero. 

2.  Failing to scale is excusable.  Failing to release is not.

3.  Don’t hug your software too hard.  If you love it, set it free.

4.  You will more often regret when you were reluctant than when you released.

5.  At the end of the day…just ship it!

6.  You don’t get a first chance to make a second impression.

I realize the above statement makes no logical sense.  But, the argument against releasing early is often “you don’t get a second chance to make a first impression” and I wanted to twist it into something clever for my purposes.  I failed.  No worries.  This one’s on the house.

6.  It’s better to release early, and irritate some users than not release, and not have users at all.

7.  If it helps you release earlier, know that my software sucks more than yours. 

8.  Ship it now.  Why wait until tomorrow to learn what you can today?

9.  There are always 10 pretty good reasons not to release.  But, they’re not that good — so just release.

10.  Software in the wild always trumps software in waiting.

11.  You’re overestimating the degree to which people give a flying flip.  Get over yourself and just freakin’ ship it already.

12.  To succeed, you need to be remarkable.  To be remarkable, you actually have to release something.

Suggested reading:  Seth Godin’s blog.  Seth’s my hero.

13.  Better to release early and be ridiculed than just ridiculed.

14.  No heroes and legends are created by software that almost shipped.

—-

That’s about the best I can do.  I have a feeling you can do better.  Post your best pithy insight on the awesomeness of “releasing early” in the comments.

Posted by Dharmesh Shah on Tue, Nov 18, 2008

COMMENTS

One can tell you are really passionate about releasing early: a whole bunch of your points above are "Just do it". Wonderful article

posted on Tuesday, November 18, 2008 at 3:30 AM by Slav Ivanov


Dharmesh, I notice that many of your points can be applied in my world. It's not unusual for one of my clients to know what to do (or say) and not have the internal fortitude to do (or say) it. Thanks!

posted on Tuesday, November 18, 2008 at 5:23 AM by Rick Roberge


This is so true. I can remember a couple of good applications that never made it live from early testing stages and its like giving up before trying.

posted on Tuesday, November 18, 2008 at 7:10 AM by Neil Sequeira


1. Wimps wait. Revolutionaries release early. 
 
What is the degree at which you launch your software/web product? 
 
Do you launch it all to the general public right away and see if it all hit/miss? 
 
Do you launch with a beta group that you have established and sent out invite-only requests to? 
 
Do you launch to a concentrated niche market of yours (for example in local search, launching in one city or state) and see if you can learn and develop more before you release out across different markets? 
 
What is the general approach to the release early, release often theory? I am of the camp of launching your product early but in a small set of your targeted audience. Check and test if it succeed, measure, track and once you hit your established critical benchmarks...start rolling it out. 
 

posted on Tuesday, November 18, 2008 at 9:14 AM by Timothy Leung


Tim: Generally, my approach is the following: 
 
1. Try to trickle out small changes at a time to increasingly larger audiences. 
 
2. Too much visibility at once leads to the "100 people reported the same bug" problem. 
 
3. In order for the release early to really work, you also have to release often. Keep building on a base of (somewhat) working code and improve it.

posted on Tuesday, November 18, 2008 at 11:01 AM by Dharmesh Shah


Thanks for the response. This might require a new post ;) but what about the communication to senior management/product stakeholders of the "Release early, release often" methodology?  
 
For example, in previous experience I have had the difficulty of building a lot of features before we get the go ahead to release the software.

posted on Tuesday, November 18, 2008 at 1:16 PM by Timothy Leung


Heh classic. Preach on.

posted on Tuesday, November 18, 2008 at 3:34 PM by LukeG


This list is a kernel of truth expressed as a feel-good, vacuous pile of truisms. 
 
"Failing to scale is excusable" - Tell that to Friendster. 
 
"Software in the wild always trumps software in waiting." - Not if your software still sucks. Talk to the folks at Cuil www.cuil.com), if you can reach them in the bottom of the huge hole they've dug for themselves. 
 
The basic idea is sound: a software company only creates value by releasing software. Anyone would agree with that. But releasing early can also kill a startup.  
 
One needs to find a release schedule that balances the legacy concerns a release creates (in terms of code that gets built up, users and data that needs to be supported, the company's brand and image) with the good that releasing gets you. And, where a company can, reducing the legacy (through clean code, incremental development, creating strong connections with users, ...) helps make more frequent releases possible. 
 
But it's always a balance. 
 
If it weren't why doesn't Hubspot release every hour ? 
 

posted on Tuesday, November 18, 2008 at 3:49 PM by Drew


I am also passionate about "release early and release often." We are doing this for our product "ObservedRequirements" as Martin Fowler puts it best. 
 
On the other hand, we are also working on a consumer site for a client who wants to release it after it is "ready." I could not convince our client otherwise. I should send him the link to this blog...:-) 
 
Syed

posted on Wednesday, November 19, 2008 at 3:21 AM by Syed Rayhan


Yes indeed! Procrastination as an excuse to get it “perfect” can be your killer. Somebody really wise said - “The results you’re getting usually are not about whether you’re doing it ‘right’ or not. It’s usually about whether you’re doing ‘it’ enough.”

posted on Wednesday, November 19, 2008 at 4:05 PM by Phoenix Business Coach


All fine and good as long as you aren't building products that kill people or cost millions of dollars if they fail on release (e.g. medical devices or semiconductor manufacturing equipment).

posted on Wednesday, November 19, 2008 at 6:07 PM by Devon


How about "for users, a release in their hands is better than ten in development?? 
 

posted on Wednesday, November 19, 2008 at 7:55 PM by Dobes Vandermeer


Another one: Fire and then Aim.

posted on Thursday, November 20, 2008 at 2:06 PM by Venkat


Great advice. I've launched a few start/test ideas in the recent months and in the end I couldn't be happier. I usually battle with myself beforehand because I'm not sure if I'm ready to launch but it always ends up being the right decision. 
 
The best feedback you will ever get is from your users. You will never please everyone but you will never have the chance to until you release!

posted on Thursday, November 20, 2008 at 3:04 PM by Jared O'Toole


I cannot agree that an early and buggy release is in all cases better than nothing. If you are in a crowdy market, you only get one chance to make an impression. If you waste it, you may as well, release the next version under a different name ;-). Only other hand, there in nothing bad with a public beta.

posted on Saturday, November 22, 2008 at 5:09 AM by Vlasta


I bet CUIL are patting each other on the back saying thank goodness we released. Better to be the launch joke of 08 than to not be known at all.. right?? ;)

posted on Monday, November 24, 2008 at 10:05 AM by Guy


Like everything, it is a trade-off. I would say that most developers ship too late though. 
 
 
 

posted on Monday, November 24, 2008 at 5:55 PM by Andy Brice


It seems to me that Microsoft perfected the "launch early" system long ago. Critics have been tearing into them for years that their products are crappy on release.  
 
I think their biggest problem is they never really get back to continually improving those products. It seems frequently like they spend a lot of time just patching holes until the next release version is ready.

posted on Tuesday, November 25, 2008 at 11:13 PM by Darrin Dickey


Up to a point. 
 
Your software has to be at least at a point where you yourself would use it. 
 
There's absolutely no reason to release semi-debugged code into the wild. Suicide.

posted on Friday, November 28, 2008 at 3:49 PM by David


This problem lives with us developer / ceo types.. Dont want to release buggy code, but fixes all the bugs takes users testing it.. 
 
Its really a catch 22.. CEO's need to make sure fuctionality is rolled out to small groups of users slowly..  
 
This is what I ahve been doing at Corkin.com and our users seem very happy with the product.

posted on Monday, December 08, 2008 at 7:57 PM by Paul


Don't forget about your customer...  
 
While releasing early has great benefits from getting off the stick, to helping test, to just plain getting yourself out there, etc.. but if you don't focus on getting your core functionality ROCK SOLID, then why would (should) your customer come back if the basics aren't there. 
 
Don't go into analysis paralysis, but do make sure your got the core foundation of your site... Then Fire away and let your customers enjoy!

posted on Wednesday, December 17, 2008 at 8:48 PM by Jon


Are you familiar with Paul Graham? Seth is popular but Paul, while not nearly as prolific, packs a bigger punch.  
http://www.paulgraham.com/articles.html

posted on Monday, December 29, 2008 at 9:25 AM by kathleen


Kathleen: Indeed, I am very familiar with Paul's work. I'm a huge fan of his.

posted on Monday, December 29, 2008 at 9:37 AM by Dharmesh Shah


The main reason to RE/RO is to gain the cognitive insights of others who are not burdened by your own cognitive filters. You cannot be objective about your own child/creation/whatever. This means you are blind in some ways.  
 
To overcome that blindess and see it all, you need to borrow the cognitive machinery of others. You cannot do this if you do not RE/RO.

posted on Saturday, January 10, 2009 at 8:28 AM by Dan Mezick


I generally agree. If you would use it, then it's ready for others as well.  
 
 
 
Once it's out there, one thing is for sure...today the market will tell you in a heartbeat what they think, how they feel, what they will do or not.  
 
 
 
I have seen some released too early, but many more way too late. 
 
 
 
Wayne Gretzky said: you miss 100% of the shots you never take.

posted on Tuesday, April 07, 2009 at 2:35 PM by Ken Toren


I could not disagree more.... 
 
 
 
If you release early, your will ALWAYS pay a price later...in many cases, the extra bugs, lack of scaling, planned architecure, Q/A, etc will mean more bugs, more support, and more time later cleaning up and fixing software flaws. And those flaws I have found increase with both speed of development and any corners being cut. I have found the opposite...the more love and care and carful attention to architecture, modularization, bug testing, customer attention, reviews and quality of programming translates directly to nearly bug-free and lower cost support. It also translates to higher customer approval and retention and long term branding, based on reputation. If you have a reputation for early releases that carry some errors and issues, that reputation could cut the legs out from under any gains in speed.

posted on Sunday, April 26, 2009 at 1:35 AM by Stormy


Comments have been closed for this article.