Product Life Cycle and the ROI of Agile Development

The product life cycle is a description of the presence or behavior of a product in the marketplace over time. The framework for description is a function of the sales volume of the product versus time. Over time, products are created and introduced, and sales grow, peak and decline. The product life cycle uses phases to describe these different periods in the life of a product. Understanding the product life cycle is also key to calculating the ROI of agile development.

The Five Stages of A Product Life Cycle

There are five product life cycle stages. The stages are defined as having different sales-growth characteristics

1. Development Stage. In the development stage, there are no sales – the product is being created and is not available.
2. Introduction Stage. The introduction stage starts with the first sale and then sales begin to grow. Sales growth is slow at first but accelerating.
3. Growth Stage. This is the period of rapid growth in sales for the product.
4. Maturity Stage. This phase is characterized by growth as well, but the sales growth is decelerating. Sales volume reaches its maximum at the end of the maturity stage.
5. Decline Stage. This phase represents the period of declining sales – they may still be very high, but they are declining.

Here is the product life cycle diagram [credit to wikipedia and NetMBA for both using this approach to drawing the graph]:

The area under the curve is total sales. This model was developed with traditional product development in mind.

What About Agile Development?

Agile development uses an approach of incremental delivery to deliver a partially-completed product to market earlier. As long as the product is “complete enough”, it will shift the curve to the left. By shortening the period of time with no product revenue (aka Development), we spend more of our time in the last four stages of the product life cycle.

Think of beta releases of software. GMail, for example, was released as a beta a few years ago. The product was just finally released to the general public in the last month. Think of all the advertising revenue that Google earned during the beta period – while GMail was being completed. If they had waited until the product (and infrastructure) were complete, and not released GMail until last month, Google would have lost all that revenue.

If we take the most conservative approach to modeling sales with an agile process, the graph would look like the following:

The sales volume curve is shifted to the left without changing its shape. The exact same growth curve applies to the product (this is the conservative assumption). The decline in sales continues to decline. The difference is that our previous time horizon (which remains fixed) now includes additional sales.

The time horizon stays fixed because releasing the software earlier neither reduces or increases our ability to predict the future. Our net present value calculations will be based on time, not “time with a product in the market.” In a concrete example: Assume we are willing to base our financial decisions on a five year forecast. Having an incremental release six months before the product is complete does not have any effect on our decision to look out five years.

It may be that sales are increased by getting to market earlier, but that is a less-conservative assumption. By getting to market earlier, when we are in a race to capture market share, we may ultimately capture more of the market. An example might be Intel’s recent multi-core processor launch. By getting to market faster than AMD (with a comparable product), Intel will probably sell more CPUs than they would had their launch been delayed until AMD was ready with a competitive product.

It may also be reasonable to assume that sales will peak at the same (fixed) point in time in the future. This would further increase the benefits of incremental delivery. One way this might make sense is if our product is filling a temporary hole in the market, and we know that the hole is going to be filled on a given date. An example might be an emulator that allows people to run Windows Vista programs on Windows XP. The time-table for transitioning to Vista is unchanged by our release schedule, and is the dominant factor in our sales forecast. Therefore our forecasted peak would be unchanged.

Conclusion

This is a handy visualization for the conservative calculation of ROI of agile development. Note that this only shows sales, it does not show costs. The costs of agile (versus non-agile) development will be the topic of another article. This is only half of the picture.