One can tell you are really passionate about releasing early: a whole bunch of your points above are "Just do it". Wonderful article
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!
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.
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.
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.
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.
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 ?
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...:-)
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.”
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).
How about "for users, a release in their hands is better than ten in development??
Another one: Fire and then Aim.
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!
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.
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?? ;)
Like everything, it is a trade-off
. I would say that most developers ship too late though.
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.
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.
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.
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!
Are you familiar with Paul Graham? Seth is popular but Paul, while not nearly as prolific, packs a bigger punch.
Kathleen: Indeed, I am very familiar with Paul's work. I'm a huge fan of his.
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.
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.
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.