Software Product Maturity

I asked our CTO, Dave Moss, if he fancied writing a few guest posts on this blog, on the topic of developing a software product.

I think blogs should represent the views of the author and that there should be a single author.  However, you may recall me saying that Dave is the “techie” I respect the most of all I have met.  So having read his first effort (below), three comments sprung to mind:

  1. I totally agree with his views in this instance and, therefore, since they exactly match my own, I am happy to put them on this blog in my name.
  2. Dave is one of those rare CTOs who has acute commercial focus and places the highest emphasis on customer need, when evaluating product development objectives.
  3. The writing is in Dave’s hand and his analogies stink!  So I refute responsibility for the way the message is communicated.

Here is Dave’s post:

Alastair has been gently pushing for a guest blog from me for while, and I’ve resisted up until now.  But a discussion during a recent scoping workshop with our development team has prompted me to put keyboard to blog as it were.

We were talking about the various stages of product development and the challenges that designers face during each stage.  The stages of product evolution are closely tied to the evolution of the company that is developing the product, but different challenges are presented to the ‘engineers’ than to the board.

Let me dive in and share some examples – at this point I want to row across to analogy island (private joke) and imagine my product is a fruit.

New products, like growing fruit, are full of potential not yet ready for consumption.  Innovators have a vision for what their product might become, and a few forward thinking consumers jump on-board, accepting the faults and gaps in functionality, because the new product is ground-breaking.

Over time (and the length of time depends on the number and quality of the team and the commitment of your innovative “early adopters”) the product becomes market ready, the gaps are filled and so are the promises – the product delivers and the customers are happy.  My fruit is ripe.  Still rowing?  Good.

The challenge that we face now (and after a number of years of development, refinement, delivery and further development our product is definitely ripe) is how to prevent the product (or fruit – I think) over-ripening.

The temptation as designers is to continually push out releases, adding the bells and whistles that everybody asks for without major steps forward.  This inevitably leads to over-complication – more configuration than execution – and a product that still does what it did in the beginning – is static – but is so feature rich that nobody can find anything anymore.

Within our development database, fault reports that start with the phrase “Wouldn’t it be nice if….” are invariably early warning signs of bloatware approaching.

But in software, what you can’t do is freeze the fruit, or can it, or dry it or whatever you do to fruit to preserve it.  Apologies – my boat has a leak somewhere.

Each release has to push the boundaries and implement the next innovation – the next idea, the next step forward, without over-developing the software.  The objective is to keep the product ground breaking despite the passing of time and also to keep your competitors – who have seen what you have done – at bay, giving customers more reasons to buy your product.

That’s my challenge at the moment; we can all see software products – some of which you might be using now – which are full of so many requests for functionality from different audiences that they are over-ripe, past maturity and no longer what they once were.

That’s one of the later stages of product maturity, however, and we’ve still got several ideas that will keep our fruit ripening in the sun for a while yet.

We’ve reached the island……for now.

Dave Moss

Leave a Reply