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.