I cringe every time I hear about someone who has spent years writing their ‘killer app’, but still hasn’t released it. My preferred approach is to get a solid, but minimally featured, v1.0 out there and then iterate like crazy based on real customer feedback. There are a number of arguments for and against releasing early:
Against: Feature poverty
A common reason for holding back on a release is “my competitor has features A and B, so I have to have A and B”. BZZZZT. Wrong. If you are trying to compete feature for feature with a competitor who is already in the market, you are at big disadvantage. By the time you have added A your competitor will have added B. Anyway, maybe some of your potential customers don’t want A or B. Perhaps they actually want something simpler. Or they really want C, which you can do in half the time of doing A and B. Microsoft has released a number of products that were derided at v1.0, but went on to dominate the market (Windows, for one).
Against: Reputation
If you release early, won’t you get a bad reputation? Only if you produce shoddy software that crashes all over the place. There is no excuse for that, even at version 1.0. The key is to pare down the features without sacrificing quality. Pick the smallest sub-set of features that will be useful. Then add more features at each subsequent release, based on user feedback.
The truth is, unless you are a big company with a lot of marketing muscle or you have picked a tiny niche, very few of your potential customers will ever hear about version 1.0 of your software anyway.
Against: Support overheads
As soon as you have customers you will have to spend considerable amounts of effort supporting them. The sooner you release the software the sooner you get this overhead.
Against: Release overheads
Creating a stable release is a lot of work, even if you manage to automate some of it. If you do more releases in a given period of time than your competitor you will inevitably spend a higher percentage of your time testing, proof reading and updating your website.
For: Feedback
Every product launch is a huge guess. If you have lots of competitors, you don’t know if you will be able to take customers from them. If you don’t have many competitors, you don’t know if there is a real market for your product. It is also tough to know what features people really want and how much they are prepared to pay. What people say and what they do are often quite different. Even if you manage to figure all that out, every market is constantly changing.
The only reliable way to find out if people will buy your product is to release it. As soon as you have paying customers they will let you know what you need to improve. Even emails from prospective buyers asking “does it do X?” can be very valuable. Many (perhaps most) successful products have ended up quite different to what the developers originally intended.
For: Motivation
Having customers is great for motivation. If you are working for a year or two on a project without customers to push you on, it is very easy to lose focus or run out of steam.
For: Failing faster
Despite the best efforts of all concerned many products fail. In fact I would guess that the majority of commercial products fail to recoup the initial investment. Yours could be one of them. If you are going to fail, you should fail as fast as you can so you can start over on something more profitable. The sooner you release and start asking people for money the sooner you will know if your product is a dog.
For: Cash-flow
The sooner you start selling, the quicker you start to recoup your investment. As a simple (contrived) illustration:
Company1 release v1.0 after 6 months. As they improve the product and website and word-of-mouth kicks in sales increase linearly for the next 18 months: 10 sales in month 1, 20 sales in month2, 30 sales in month 3 etc.
Company2 release v1.0 after 12 months. They have the same sales: 10 sales in month 1, 20 sales in month2, 30 sales in month 3 etc.
In 18 months Company1 will sell 1900 licence, whereas Company2 will sell only 910 licences. But surely Company2 will have a better product when the release it? Even if Company2 sales grow twice as fast (20 sales in month 1, 40 sales in month2, 60 sales in month 3 etc) they will still sell 80 less licences than Company1. Also I believe Company1 will probably have a better product than Company2 12 months or 24 months in because they have 6 months more feedback on what customers really want and will pay for.
Conclusion
It is well known that the sooner you catch a mistake in development, the cheaper it is to fix. I believe this is just as true in marketing. A sure way to find these marketing mistakes is to release. You wouldn’t write a thousand lines of code before you tried to compile it. Why would you spend a year or more on development before testing it in the market? Creating software should be an incremental process.
The best time to release is a trade-off between the various factors above. Obviously your software has to be able to solve a real problem, or no-one is going to buy it. This is going to take longer for an air traffic control system than a back-up utility. But I would always try to release v1.0 in less than 6 months of elapsed time if it is my money paying for the development (I don’t write air traffic control systems). Spending a year or more writing something with no real customer feedback is more risk than I am prepared to accept. If you think it isn’t possible to produce something useful in that time, then maybe you aren’t being creative or brutal enough with the feature set. As a rule of thumb, I would say that if you aren’t embarrassed by the lack of features in v1.0, then you didn’t release it early enough.
Successful Software 
I generally absolutely agree – I’ve taken too long for my application. I will say that it’s done me a world of good, though. The main reason? If I was supporting my older version I’d be stuck adding customer feedback to that base instead of the current one, which is significantly better and is something I’m happy to build on.
Having said that, I did release a beta earlier than I wanted to and it was definitely the right move. The feedback has been really useful and it’s great validation knowing I’m on the right track.
Personally I believe releasing a minimally featured version early in the development process is – of course – a good practice, but it also gets a bit frustrating.
At least this is actually what I am experiencing with my current project: I know what I’d like the app to do, so giving the user a list of “TODOs” and a small features set, gives the feeling he maybe won’t really understand the right potential of the app.
On the other hand, late releasing is absolutely unacceptable in business scenarios, and user feedback is way too important since the very first moments of a product’s life cycle, so the “release early, release often” motto surely holds.
Pingback: “Release early, release often”: why bother at all « Meltin’ Posts
top stuff. fully agree!
Pingback: First advice « Startupping echoes
Pingback: Best of Feeds - 37 links - lifehacks, tips, productivity, programming, blogging « Internet Duct Tape
I completely agree with your philosophy. Personally I have just did the same thing with an open-source app. I decided that it was better to just get out a 1.0 version with a minimal amount of features and just take in user feedback and work my way up so that I can continue to have frequent releases. The program is called ZScreen by the way and it is available on my website. It is a C# app that can FTP screenshots and put the URL in your clipboard in a single keystroke.
I fully agree. But really make it stable. It must not have many feature. But stability. Don’t let the banane ripe in the hand of the customer.
maria
Probably very sound advice. Just one note though, releasing often puts an extra burden on the user, since in order to stay up to date and get the most out of your software they are forced to upgrade every time you release. And we all know that when you upgrade change something around, something always breaks no matter how well tested the release was. This is even worse if the versions are not compatible with each other.
Ensi,
I take your point, but I was only talking about releasing v1.0. Not subsequent releases. That will have to wait for a separate article. ;0)
Hmmm… Andy, I think that maybe you should have waited and published this article *after* you added the bit about “subsequent releases*. I.e., You released your article too soon .
I see. Well thats all right then.
Andy,
Great article. You have outlined the approach we are currently taking at Hexawise. Given that our firm produces software to make it more efficient and effective for software testers to find bugs, we have more pressure than most firms to make our V1.0 as bug-free as possible.
Andrew R
Hexawise
More Coverage. Fewer Tests.
You got a version 1.1 of this article, I think the pronunciation could be improved on. Maybe a little more pizzazz. LOL.
I suppose 1.0 doesn’t have to be perfect, as long as your “feature set” (whatever you have decided that it is going to be) is intact in some form and present. Especially if there’s a deadline…you always want to make sure that we’re out of beta and releasing on time.
A really nice article. I can relate my experience with this article. We decided to implement all posssible features in v1.0 of our product. And when we finally went live with v1.0, it definitely was feature rich, but the number of problems /bugs that the user was reporting also increased in the same scale.
Since then, I agree that v1.0 should be out as soon as you can make it stable (even though it does not has a complete feature-base).
Thanks,
Sid
This is so true BUT it’s just as important to submit the software to search engines/shareware downloading sites at the same time otherwise your updating for a very low audience that have on the off chance discovered it or you have told.
see also http://www.codinghorror.com/blog/archives/001313.html
Pingback: And So It Begins
Spot on article. I am the sales guy and trust me I can’t sell nothing…actually I can and have– waiting on programmers to “do a re-write” Get your product and let the stupid know-nothing (paying) customers guide you.
In my personal experience, when I spend a long time writing something, it flops. When I write something fast and hacky, it goes viral. Go figure :)
Pingback: 7 Reasons To Hate Your Code « yield thought
Pingback: Max’ Lesestoff zum Wochenende – 30/2010 | PHP hates me - Der PHP Blog
Pingback: Interessante Links im Netz 13 | DaRaFF's Blog
Pingback: Feel the Fear and Do it Anyway - Synaptic Mishap
good post. Marketing is challenging enough. Mixing it with release dates makes things even more complicated.
I don’t plan on being embarrassed by v1.0, but I’m sure when I release v2.0 I will be ;-)
Pingback: Eventcountdown.com « Successful Software
I often suppose if I release v1.0 too earlier before I’m sure it’s stable enough will cause lots of bad reviews,which will not be good for further business. After reading this article, I think I should try to release v1.0 as earlier as possible go get feedbacks and improve it.
Please note that I have never suggested releasing unstable software (feature poor – yes, buggy – no).
Pingback: The roadmap
Pingback: Hello, Fingerpaintball « Whatever happened to Benjamin Ragheb?