How do you know when software is ready to release? This article discusses one piece of knowing when the software is ready to release--knowing what a successful release would look like.
Geoffrey Moore discusses a model of high-tech marketing-what your customers expect and when-from the introduction of a product through its growing acceptance to the product's end of life.
Bob Grady describes the three possible goals of any software project: 1) meeting a specific time to market, 2) some feature set that would make the customers happy, and 3) keeping defects low. According to Grady, there is only one primary goal for a given project, and the other goals are managed within the constraints of that goal.
It makes sense to me that different customers have different project goals, depending on where the product is in the product lifetime. Table 1 (below) describes the intersection of where your market is with your possible project goals. If you're just starting out with a product, you have technology enthusiasts as your primary customers. They want the software fast. The software has to do something, and not be too shabby, but the enthusiasts don't need a lot of product, it just has to do something well.
Once you've increased your market to include the visionaries, you have slightly different concerns. Although the priorities are frequently similar, your customers are early adopters. They have a specific problem, and they want your software to fix that problem. Unfortunately, it seems as if each early adopter has his own problem, and that the problems are sufficiently different that you may be able to use a core product, but you have several one-off solutions to address each of your early adopters' problems. The Early Adopters drive the demand for quick releases with new desired features. If your competitors release a product with a few more features, and then you release a product with those features plus a few more, you've seen the product leapfrog game, an example of Early Adopters in action.
|
Market description |
Introduction |
Early Adopters |
Mainstream |
Late Majority |
End of Life |
|
Who buys the software |
Technology Enthusiasts |
Visionaries |
Pragmatists |
Conservatives |
Skeptics |
|
Time, features, defects, ranked by importance |
1. Time to Market 2. Feature Set 3. Low Defects |
1. Time to Market 2. Feature Set 3. Low Defects |
1. Low Defects 2. Time to Market 3. Feature Set |
1. Low Defects 2. Feature Set 3. Time to Market |
1. Low Defects 2. Feature Set 3. Time to Market |
Table 1: Project priorities based on where you are in the product's lifecycle
Once you hit the Mainstream, the pragmatists take over. Pragmatists want your software to work. They care about upgrade availability, but not as much about installing upgrades or new versions as you do. (Installing upgrades costs them money and time, and they have perfectly good software to use until they choose to upgrade.) In fact, once your software has reached the late majority, even though it's still in the mainstream, your customers don't want releases from you any more often than they absolutely have to take them. The skeptics may or may not buy your software, but even if they buy it, nothing says they'll actually use the software.
Let's take word processing software as an example. Back in the '80s, there were several successful and competing word processing software packages. However, once PCs were available for the work and home markets, people wanted to use word processing software that was easier than using a markup language under Unix. Many companies, including Wang, Xerox, Corel, Microsoft, and Lotus, made word processing software. During the late '80s and early '90s, each of these companies released numerous versions of their products. In my opinion, the word processing wars were won with Microsoft's release of Word 5.1. At the






