For several years, great interest has been shown by new products people in shortening the time it takes for the product development process. That process is usually defined as the time from when the idea is fairly well clarified to that point where the item is available on the shipping dock. It thus eliminates most of the so-called fuzzy front end and the marketing phase.To achieve speed, many techniques have been proposed. But most of the support has come from anecdotal experience and small study case samples. The authors of this report tell how they scanned the literature to gather a list of the 12 techniques most often urged, and then studied a sample of electronics firms to see how use of those techniques has helped shorten the time of development. Data on techniques used and time shortened were gathered for one project in each firm, and correlations were run between the variables.The 12 techniques lie in three categories--product strategy, development process, development team structure. Here are the techniques; for each, take the hypothesis as As the use of (technique) increases, development time decreases. Ideally, the answer to all 12 would be yes. Product Strategy Follow an incremental product change strategy, making frequent, incremental changes rather than periodic radical changes. No. This factor was not significant in reducing development time. Using parts reduction, fewer parts relative to previous models. No. This factor was not significant.Process Development Process Overlap development activities traditionally done sequentially. Maybe. This factor was not significant in one analysis and was significant in another. It appears so intuitively logical that the authors accepted it as one of the significant techniques. Freeze the product design early, and limit the number of voluntary design changes that occur late in the process. No. This factor was not significant. Reduce the number of suppliers and involve the remaining ones more actively. No. This factor was not significant. Increase the portion of parts design done by suppliers. No. This factor was not significant.Development Team Structure Use a team consisting of members representing all key functional groups, especially marketing, engineering, and manufacturing. Yes. This factor is clearly significant. Use dedicated team members, or at least more dedicated than in the past. Yes. This factor is clearly significant. Locating team members close together (colocation) to facilitate communication. No. This was not a significant factor. Decreasing the number of decisions for which approval is required outside the project team--use empowerment. No. This factor was not significant. Increase the level of senior management support for the team. No. This factor was not significant. Set and manage time as an explicit project goal. Yes. This factor was clearly significant.The overall conclusions are that four factors are helpful--explicitly combine stages or steps rather than letting them be sequential, use cross-functional teams, have the people full-time (dedicated) on their projects, and have the activities time managed. Oddly, two of the factors actually came out as time-stretchers, not time reducers--using fewer suppliers and having top management support. The authors caution, however, that there may be reasons, in individual cases, where a technique would not work. For example, reducing the number of suppliers is initially time consuming and labor intensive, and close relationships have to be built. Too, there may be reverse cause and effect in many cases--for example, sometimes top management makes a point of giving support to projects where they anticipate trouble.The authors caution that their study was confined to electronics firms, used single respondent reporting for each firm, and involved 44 firms. But the data suggest there should be more intensive study of the limitations of the various proposed techniques before they can be accepted as ready to use.