On average across the industry, the first release of a software product constitutes only a quarter of the total time investment needed for its entire lifecycle, its Total Cost of Ownership (TCO). That remaining 75% consists mostly of operations and support activities, including answering support issues, maintaining the hosting infrastructure and administration. Out of that 75%, only about 15 - 20% relates to further development.
Putting this into perspective, after the first release, only an estimated 27% of your organisation’s time is available for changing the product with 73% required to run the product. That doesn’t sound like a lot when you reflect on what brings new customers – new features! So how do you make more of the 27% and lower the 73%?
The 3 areas we have helped organisations consider when building new products are:
- Funding efficient operations and support activities, and
- Taking design decisions in your first version that make it easier to add new features later.
The aim of these is to keep as low as possible the time required for support, operations and administration and maximise the value of future development. Let’s take a look at some of the immediate options that arise:
If your team and budget is limited, a common option is to use developers to provide operations and support activities. It doesn’t require any additional manpower, but the downside is that managers need to fully accept that 50% or more of their time could be spent handling ‘urgent’ questions and issues from paying customers. Tasks that will make prediction of subsequent product versions much more difficult. And this can become frustrating when a potential customer is ready to sign up but awaiting news on a feature that they’ve been promised by the sales team. The flipside is to recruit a dedicated support function, to better ring-fence development staff against big impacts to their time, but this requires additional budget, or reduction of the developer pool to resource support.
Think about how you will release new software to customers. Will you support multiple running releases of your product in parallel, or if its web hosted, force everyone to upgrade to the latest in one go? Consider your software architecture and what support you need in place to support the operations processes you want to have. Add simple automation to reduce the amount of time spent doing them, without spending too much time on the automation solution. This will potentially save time and money later.
For first versions of products, make conscious the design decisions that are taken to close doors (or make them more difficult to open) in terms of future features. I’ve had direct experience of products where a subsequent release was more about re-architecting, and less about new features. And that uses up a significant portion of that 27% you have left to spend on feature development.
It’s a fine balance, as the opposite extreme is to build in support for everything you and stakeholders think of while developing a piece of code. Hooks for features that never ever see the light of day. And that can increase cost and time of that first release significantly. Focus back to the target niche of the product and who your ideal customers are, and ask the question – ‘What other features are customers likely to ask for and what are they not likely to need?’ And be specific with the answers. For example, if you know you are selling across different countries or regions, its worth designing into the product the ability in the future to support customers in different time-zones and with a specific set languages. But focus on the specific languages and regions, not all.
The goal of all these focus areas is to maximise the amount of time and value for future feature development. That’s the time that will most likely bring additional income for your organisation. For solutions, there’s no one size fits all. The decisions you adopt depend on what fits best for you, your teams and your organisation. Take some time to be specific on what you really need for your customers now and in the future and be creative with the team and time schedule. For the decisions you make, gain buy in with all stakeholders, and document these for reference. Also put in place metrics to capture how your team and organisation is splitting these activities. This gives more information that can inform planning for future new features and also areas for further optimisations to working practices.
So as you’re focussed on that first release, take a little time to reflect beyond it, and see what decisions you can make now that might give your organisation more time for new feature development.
To learn more about about how these might work for your specific team and working environment, please Contact Us. And sign up for our newsletter to stay informed of new articles, news and events occurring for Inviting Futures.