Product Lifecycles

Editor's Notes

1. This model, used by many, and discussed recently by Geoffrey Moore, shows an adoption curve that is a member of the “normal curve family.” The early and late majority generally fall within one standard deviation of the mean, with early adopters and laggards at two standard deviations, and a population of innovators at about 3 standard deviations. Appealing to different groups requires different tactics and timing. Innovators – ready to try anything; use them for concept exploration Early adopters –tolerant of change and revisions; use them for pilots and champions Early majority – practical people; want to see evidence this is useful; get them the results of the pilots and management support Late majority – they want to wait until the change is an established standard, management push and rewards may be necessary Laggards – want nothing to do with the new approach; will avoid as long as they can; don’t focus here The chasms shown here is one of two pointed out by Moore. There is also a smaller chasm between the early and late majority, reflecting the different approach to these two groups. However, the one between early adopters and early majority is more significant – those to the left are able to handle revolutionary change, while those to the right need evolutionary change.
2. Role 1: Research and Exploration Ideas that end up in a product are often initially created by a group that is guided by spon­tane­ity and inspiration [Olso93]. This group works best following an evolutionary model, that is, building bits and pieces and tying them together into a less than completely coherent work product, often called a “proof of concept.” The emphasis of such a group lies in innova­tion. Exploration (of new technologies and ways to apply it) and redoing are encouraged. Control is lax, although these groups usually work un­der a fixed budget. Whatever they turn out is usually well received. The goals are set in long term visions. The costs incurred in research are sunken costs to the company, that is, they are incurred without immediate accountability. Role 2: Engineering The economic viability of a software product lies in its quality and in its develop­ment costs. If quality is low, the product is not viable (see role 3 for an explanation.) If the development costs are too high, there might not be enough market to compensate these costs. When people work in this role they should be less concerned about innovation and more about quality. This role is best managed through a well defined process model, in which a requirements-gathering phase precedes the design phase, that in turn precedes the imple­mentation phase. (Although this so-called “waterfall model” is strictly se­quential, it is seldom the case that the developers “run” the activities in such clear-cut or­der. They usually go back and forth from requirements to design. They might even move forward to im­plement a little, then back to gathering requirements. However, the nature of each activity and where each belongs in a documentation scheme should be kept clear at all times.) Exploration is dis­couraged and rework is considered a necessary evil. Control is strict, and budgetary con­straints are strongly tied to project man­agement. Goals are now midterm, counted in the order of months, not years. The costs of activities performed in this role are fixed, but not sunken. A product is ex­pected as an outcome, and the costs of the product are indirectly (as we shall see when we look at Role 3) dependent on the ex­penses of the phase. Role 3: Quick Fixes Under this role, only urgent patches are tackled. Larger fixes and enhancements are then rewoven into the fabric of the product through newer versions developed in an iteration of role 2 (version n, n>1.0). In role 3, the process changes to “fix and ship,” the emphasis at this time residing in immediate response. Exploration and redoing are now punished, because otherwise control is even less attainable. The lack of control tied to this role is linked to the fact that the costs for the role are a function of the quality of the product. Products with poor quality are harder to maintain and enhance, incrementing the costs of repair. This is truly bad, since now these costs are variable costs, a function of both the number of problems found during operation and the number of corresponding calls received.