Thursday, 27 March 2014

Releasing a Software Product to Market

In the desktop software world, we've been used to product versions, bug fixes patches and upgrades. We often hung out for the next release and the promise of what might come, and avoided version 1.0. Upgrades came at a price, and there was a cost/benefit analysis that went on with the bean counters as to whether to buy version 3.0 or wait for version 4.0. Typically, releases were late and timing of product names with a year in the title and the actual year of release often became farcical.

In the car industry we're seeing releases of the subsequent year model several quarters before the New Year - perception and promotional games.

What has this got to do with MUSAC, edge and MUSAC Classic?

Some years ago MUSAC moved to an software lease model. The SMS space has so many compliance requirements and changes to assessment and legislative requirements, that purchasing of new versions just became too hard to manage. When was a change a "user group" fee and when did the feature comprise a new version. Solution - annual lease.

Further to this, MUSAC had multiple modules. It became complex and feature requests then became intertwined among modules, some more advanced than others and the risk of being able to do the same thing two different ways and get different answers depending on configuration. Solution - MUSAC packages. New feature placed in the appropriate module available to all.

Then along came edge. We had addressed some issues with the desktop development paradigm through the lease model and packaging modules together, but ultimately architecture, delivery and focus demanded something very different.

We were introduced to a concept of supplements and compliments. However, the experience of SMS-LMS inter-operability told us that it would be hard - very hard in fact - to keep people happy.

When do you release to market?

We then came across Agile development and the 37Signals group. In short, get something, anything to customers quickly and see what they use. Build on the bits they like. Remove the bits they do not. We had some great feedback very early (before we had invested too much in the product) about things that were good and things we needed to focus on.

The risk of course is the perception that you "released too early" - particularly those stuck in desktop software paradigms. The product has the functionality that it has and may or may not have more soon - there is one version - that live with customers. The reality about getting features out into the customer hands faster is you learn about your success and failures and can adapt sooner. Being in the cloud means you can increment changes very regularly to all customers. The key thing is about having customers on the journey with us and our philosophies.

What is also key is about how we listen to customers. Focus groups usually result in long wishlists of features that when built don't get used. We focus on school outcomes and challenge the status quo, build and then watch what features customers actually use. i.e. we have to listen harder!

With edge we released to market as soon as we could and we got great early feedback. Some very early adopters expectations were misaligned with ours, but that happens.

So, was edge released too early? Definitively not. It should have been released sooner!

No comments:

Post a comment