What does it mean?
It is the stages that a new or redeveloped software product goes through, from its very beginning until it’s launch, and then through every stage thereafter. We generally think of the life cycle in 4 key stages: introduction, growth, maturity, and decline, and each one requires a slightly different strategy if you are going to have a long application lifespan.
Often the most exciting part of any software development – building something from scratch, with a USP and a unique opportunity to create something amazing. Companies therefore invest a lot of time and money in this stage to get it right – after all, the initial release has to be good if it’s going to be successful.
A strong product roadmap, detailed prototype and designs, and a very good development team are therefore crucial to a products success, and all of this needs time to plan effectively.
This plan should include an initial phase – so what you absolutely want to have in the initial product offering, followed by a phase 2 and 3, that can be worked on as soon as phase 1 has launched. Staging it properly can make or break a software release, and one of the most overlooked stages, marketing, should always be factored in.
The initial release of your application went well, and you have developed more features in line with your product roadmap. In fact, things are going so well, that you now have a bigger team to look after, support and develop it. But have you thought of speed, country access and uptime stability?
We all spend a lot of time at the beginning of a development project getting it right, and trying to think of all the things that need to be implemented to ensure a successful application. However we don’t always spend a lot of time working on a plan for software growth.
This should go beyond your product plan, and should include what your growth plan is (so how many users you want on the platform by y for example), so that you can look at infrastructure, data security, and software updates that cater for a global user base instead of just a local one (if that is in your overall strategy).
So your product is doing well, you have a large, successful user base, you’ve been ironing out the bugs as you go, and new features and functionality have been added over time. All of which is a good thing, but have you taken the time to complete a software review at the end of every release cycle to see how well all the code, and your infrastructure, is stacking up?
With every review, the aim is to take a look at what needs improving, upgrading and replacing, to ensure that the integrity of your application remains top notch. And for the very good reason that if you want to keep your software running for as long as possible (so to increase it’s lifespan if you like), it needs to keep up with moving technologies and be able to support new features.
Hopefully this won’t happen to your software overall, but it will happen to parts of your software over time. This isn’t always a negative though – user patterns change, become more refined, are impacted by new technologies and so forth. The key, is to identify the parts of your software that are in decline (so having a measurement tool built in is very important), and have a plan for them. Essentially a deprecation plan –
- Over what period of time are you going to deprecate the feature?
- How? So will it be put into bug fixing only mode, or will you still be spending build time on it?
- How will it be communicated to end users
- What, if anything, is it going to be replaced with etc.
If you do or don’t have a software plan in place, do consider what we have outlined above, and if you have any questions at all, we would be more than happy to help!