Whether it's a kitchen gadget, a device for playing recorded music, or a software system, almost every product has a lifecycle associated with it. The lifecycle of a product takes it through distinctive phases. From cradle to grave, it breaks down to five predictable stages:

• New Product Design and Development—This stage is generally expensive and produces no revenue. Moreover, only about 35% of commercial software systems written ever make it out of this stage. Yep. That's right. Fully 65% of software systems that are developed are never released.
• Market Introduction—This stage is also marked by high costs and low sales. Advertising and other expenses can be considerable as there is little market awareness and little demand. Correspondingly, there is usually very little competition.
• Growth—This is the first stage that has a payoff. Costs are going down because of increasing economies of scale and cheaper sources of production. Demand, sales, and profits are going up as more and more people become aware of the product. Competition is beginning to be a factor.
• Maturity—These are the golden years in which product sales are driven mostly by momentum. The product may even have become a de facto standard. Advertising and other costs are very low. Competition is strong and various producers are striving to show feature differentiation. Eventually, competition will drive prices to zero-profit equilibrium.
• Decline—Sales and profits decline. Minimizing cost becomes the primary means of generating a profit. Eventually, the product is replaced or withdrawn from the market altogether.

The challenge, then, is to be aware of the characteristics of the product lifecycle and to work with them to minimize the bad times and maximize the good times—a practice called Product Lifecycle Management (PLM).

It's New, It's Improved, It's Old-Fashioned

A given product may have a lifecycle, but often that product exists within a larger industry that will have a much longer life or may even may be immortal (like blue jeans.) Consider the humble television. In the 1950s, sales of black and white televisions thrived but came onto hard times with the advent of affordable color TVs in the '60s. Color TVs evolved to various formats and then to flat-screen and then high-definition technologies. Through each of these small or "micro" product lifecycles, the television industry, as a larger or "macro" enterprise, has remained strong.

In the maturity stage of the lifecycle, there are sometimes too many competitors in the market. When this happens, prices go down and producers start trying to make their product appear different from all of the others. This can be an unfortunate turn of events as truly strange designs and overloading of features often result. A good example of a bad example is digital watches. What was a poor design in the first place, due to a lack of natural mappings for the buttons used to set the time, was made worse with the confounding addition of a built-in stopwatch. That wasn't different enough, so a calculator with tiny buttons was added that no one ever used. But it was different and probably marketable.

Software Obsolescence

Inevitably, a software product will have to be continually updated and enhanced as the environment it runs in evolves. Just keeping a product current with changing technology requires repeated iteration of the development cycle. It's been my experience that a software product must be redeveloped every two to three years, even without the addition of new features, just to keep it working. But this might not always be a bad thing.

One would think that the longer a product's lifecycle, the better. This may not always be true, especially for the developers of a product like software. Software, like recorded music, is very easy to steal or replicate without benefit to its creator. In this regard, software obsolescence can cause an unauthorized user to turn legitimate. For example, consider a software package that interfaces with another software system like Windows or Java. For the user running an unauthorized version of the software, everything's fine for awhile, but then the user moves up to a new PC and things start to go wrong. Operating system features can't be found, or maybe stronger security in Java now limits the software functions. Suddenly the user, who has come to rely on the unauthorized software, has a change of heart and decides to actually pay for the newest version of the package.

Product Lifecycle Management (PLM)

It's been shown that the lifecycle process can be predicted and even managed. For instance, take product promotion: When a product is first developed, if it's truly innovative, nobody knows what it is. It might be easily understood, once explained, but it's still new to the consumer and will require some advertising, promotion, or endorsement. Time and money should be budgeted for this predictable process.

Similarly, periods of little or no revenue must be expected in the development and product introduction phases. There's just no way around it. This reality may be mitigated, however, and the negative impact minimized by applying engineered development techniques to minimize costs and to bring the product to market in the least possible time. Through agile software engineering techniques, like extreme programming, the software development process can be shortened, and overlapping phases engaged concurrently where possible. This will help get the product to the important point where it is generating revenue as quickly as possible. Further, the effort to minimize production costs can be moved along more rapidly toward the point where economies of scale and improved production techniques have a positive effect.

At the other end of the lifecycle, when the product is nearing the end of its life, sound management techniques will recognize the impending decline and plan accordingly. Good management will dictate that as one product is nearing its end, another, newer product must be begun.

Design Is Key

In my opinion, the most important aspect of good product lifecycle management is application of good design practices before the product is brought to market. Software in particular must be extremely well-designed to have any chance of becoming a success.

People who use software don't read. They don't read error messages, and they certainly don't read program documentation. They need software that works the way that they expect it to work—without having to read anything and without training.

This expectation of how software should work is called the "user's conceptual model." If a software product does not accommodate the user's conceptual model, it is doomed to failure. For example, imagine how you would feel about using a Web site that required you to actually read instructions explaining how to do things before you could successfully proceed.

According to Joel Spolsky in User Interface Design for Programmers, a software user interface is well-designed when it behaves exactly as the user expects it to—that is, when the program model conforms to the user's conceptual model. The exception occurs when the user's model is incomplete or broken. In this event, a good software design will provide both constraints that politely narrow the user's range of choices and selections that invite the user to follow the correct course.

In general, a good design should do the following:

• Make it easy to tell what actions are possible at any given time
• Make things visible, including the conceptual model of the system, the alternative actions, and the results of actions
• Make it easy to evaluate the current state of the system
• Follow natural mappings between intentions and the required actions, between actions and the resulting effect, and between the information that is visible and the interpretation of the system state.

And, ironically, a good design process cannot be accomplished by designers. John Culkin said, "We don't know who discovered water, but we're certain it wasn't a fish." That's because a fish, being immersed in water, will be completely unaware of it. Likewise, a good product design requires a strong influence from outside the development environment.

Going Through the Process Again and Again

It's commonly held among software engineers that the design and development process for software should be iterative and incremental. That is, the process of producing a software product is ongoing, a circular exercise in which the product is enhanced and adapted repeatedly over time. With that sort of predictable repetition, an engineered approach to product lifecycle management must be considered.

Chris Peters has 27 years of experience in the IBM midrange and PC platforms. Chris is president of Evergreen Interactive Systems, a software development firm and creators of the iSeries Report Downloader. Chris is the author of The i5/OS and Microsoft Office Integration Handbook, The AS/400 TCP/IP Handbook, AS/400 Client/Server Programming with Visual Basic, and Peer Networking on the AS/400 (MC Press). He is also a nationally recognized seminar instructor and a lecturer at Eastern Washington University. Chris can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

Chris Peters has 32 years of experience with IBM midrange and PC platforms. Chris is president of Evergreen Interactive Systems, a software development firm and creators of the iSeries Report Downloader. Chris is the author of i5/OS and Microsoft Office Integration Handbook, AS/400 TCP/IP Handbook, AS/400 Client/Server Programming with Visual Basic, and Peer Networking on the AS/400. He is also a nationally recognized seminar instructor and a lecturer in the Computer Science department at Eastern Washington University. Chris can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Chris Peters available now on the MC Press Bookstore.

		i5/OS and Microsoft Office Integration Handbook Harness the power of Office while exploiting the i5/iSeries database. List Price $79.95 Now On Sale

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails