Realese Early, Release Often

As Lachlan has also concluded, releasing earlier with a reduced feature set and improving from there with customer feedback is a very good idea.

I might not have any experience in the commercial software business yet, but in corporate and bespoke software I see this happening all the time. Release something that gives a good base to work from, based on initial customer requirements, let the customer see and work with what they have asked for. You’ll then get lots of feedback that will improve the application for the customer, which is the most important source of feature specification you can get, feedback. A tricky part in writing bespoke software is stopping the customer asking (or rather insisting on) the bells and whistles that are unlikely to be used, and that take a lot longer to develop for. The obvious answer is to quote high for these things, which inevitably leads to them being dropped from the initial requirements and pushed into a second delivery phase. What usually happens is that once the customer gets their hands on the application, even in User Acceptance Test, they see that they can work just as well without these extras, and can identify far more important improvements to take their place in a second delivery.

Again, the feedback loop is the key here, the shorter it is, the better, which just so happens to be a key principle of eXtreme Programming (XP) and most of the Agile methodologies.

I believe this is the only way to go if you want to make a sustainable software business, I might yet be proven wrong, but as long as you have a product that on initial release has just enough features to make a good portion of the potential market take interest, the feedback you get from them will be hugely important and will steer your subsequent development for quite some time.

Deciding what is a good initial feature set is however very important, it needs to be enough that you satisfy some need of your potential customers, but not so much that it takes a decade to write the software. This is obviously tricky to get right. In my product my feature set is quite skimpy in a particular area that I think I will get lots of requests for, I know I will, but I also know that it will take a lot of time to get it right (and may require some expenditure for a third party component). In the mean time, the similar feature that I think is going to be more important will be there, almost in full, and that feature is the core that will be built on and expanded in later releases. There are important features that I intend to introduce along the way that will further improve the application, some I expect to introduce before the one that may require a third party component, they all build up to give the user flexibility in this area, and ultimately many users may not even want this key feature because they can integrate other tools into their workflow that they already own and know, and can do a lot better than my app can initially. When I get the feedback, I’ll be able to decide what’s next on the list, what’s the most efficient new or improved feature that will make my existing customers happier and will maybe win new customers.

You need to think organic, grow your software slowly as your customer base grows; this is one of the primary principles and advantages of being a micro-ISV. Nurture your software, feed it, water it, and keep an eye on the leaves and fruits to determine what is needed to keep it fruit bearing for a long healthy future.

No comments.

  1. Funny… that’s exactly what I’m trying to do now… *gets back to coding before heading into his regular job…*