Developing Products on Internet Time

The rise of the World Wide Web has provided one of the most challenging environments for product development in recent history. The market needs that a product is meant to satisfy and the technologies required to satisfy them can change radically—even as the product is under development. In response to such factors, companies have had to modify the traditional product-development process in which design implementation begins only once a product’s concept has been determined in its entirety. Instead, they have pioneered a flexible product-development process that allows designers to continue to define and shape products even after implementation has begun. This innovation enables Internet companies to incorporate rapidly changing customer requirements and evolving technologies into their designs until the last possible moment before a product is introduced to the market. Flexible product development has been most fully realized in the Internet environment because of the turbulence found there, but the foundations for it exist in a wide range of industries where the need for responsiveness is paramount. Product developers in industries from computer workstations to banking increasingly face dynamic and unpredictable environments characterized by rapidly evolving technologies, changing customer tastes, and sweeping regulatory changes. In these industries, companies that have begun to adopt more flexible product-development approaches are setting new competitive standards. What’s involved in increasing the flexibility of the product development process? Many of the companies we studied have adopted a coherent set of mechanisms that allow product developers to generate and respond to new information about what customers want and about how technology has evolved over the course of a project. These mechanisms not only enable a continuous flow of information about customer needs and new technologies but also reduce both the cost and the time it takes to integrate that information into the evolving product design. They allow designers continually to sense customer needs, to test alternative technical solutions, and to integrate the acquired knowledge into a coherent product design. This flexible process continues iteratively throughout the development process. The traditional development processes that many companies use are highly structured. A future product is designed, developed, transferred to production, and rolled out to the market in clearly articulated, sequential phases. Such processes usually begin with the identification of users’ needs and an assessment of the various technological possibilities. Then a detailed set of product specifications is created and, once approved by senior management, is set in stone. At that point, attention shifts to implementation as a functionally integrated team translates the concept into reality. If the up-front work has been done correctly, inherently expensive changes to the product’s specifications are kept to a minimum. Indeed, the number of engineering changes is often used as a measure of a project’s effectiveness: many changes signify an inferior effort. In contrast, flexible product development delays until as late as possible any commitment to a final design configuration. The concept development phase and the implementation phase thus overlap instead of following each other sequentially. By accepting the need for and reducing the cost of changes, companies are able to respond to new information that arises during the course of a product’s development. Systemic changes in a project’s definition and basic direction are managed proactively; designers begin this process with no precise idea of how it will end. (See the chart “Two Approaches to Product Development.”) Two Approaches to Product Development Speed is a subtle concept in this model. Total lead time—the time taken to fulfill the initial objectives of the project—is clearly important; but concept time and response time are critical measures themselves. Concept time is the window of opportunity for including new information and for optimizing the match between the technology and its application context. Response time is the period during which the window is closed, the product’s architecture is frozen, and the project is unable to react to new information. Although the total lead time is the same for both processes above, the flexible process has a shorter response time and is therefore preferable in rapidly changing environments. Today a rigid, sequential development approach can risk creating an obsolete product. When technology, product features, and competitive conditions are predictable or evolve slowly, a traditional development process works well. But in turbulent business environments, a sequential approach to product development is more than inefficient; it risks creating an obsolete product—one that fails to address customer needs and to make use of the latest technologies. When new competitors and technologies are likely to appear overnight, when standards and regulations are in flux, and when a company’s entire customer base can easily switch to other suppliers, businesses don’t need a development process that resists change—they need one that embraces it. A Flexible Process at Work Not every company interested in developing a flexible product-development process would have to go to the extremes that Netscape did. But by looking at Netscape’s experiences, we can see how a highly flexible process works. Founded in 1994, the company pioneered the easy-to-use Web browser: a software interface that provides access to the World Wide Web. The Web browser has transformed the Internet from a communications channel for scientists and technicians into a network connecting millions of ordinary users across time and space—and thus into an industry in its own right. But Netscape faced no easy task in developing its Web browser, Navigator. In the rapidly evolving Internet industry, many alternative technologies and applications compete for attention, and product development is a project manager’s nightmare. The major challenge in the development of a Web browser is the level of technical complexity involved: a typical program rivals a traditional word processing or spreadsheet application in size, and it must work seamlessly with myriad different hardware and software platforms. The level of uncertainty is so high that even the most basic decisions about a product must be continually revised as new information arises. And the fact that industry giant Microsoft, which had already developed its own flexible product-development process, was readying a product to compete with Navigator only added to the complexity and urgency of Netscape’s development effort. Netscape introduced Navigator 2.0 to the market in January of 1996 and immediately thereafter began to develop the next version of the Web browser, Navigator 3.0, which was to be released in August of the same year. (See the chart “The Development of Navigator 3.0: A Timeline.”) The Netscape development group—which included staff from engineering, marketing, and customer support—produced the first prototype quickly. By February 14, just six weeks into the project, it had put a Beta 0 version of the program up on the company’s internal project Web site for testing by the development staff. Although many of the intended functions were not yet available, the prototype captured enough of the essence of the new product to generate meaningful feedback from members of the development group. On February 22, less than two weeks later, the team posed an updated version, Beta 1, again for internal development staff only. In early March, with major bugs in the product worked out, the first public release, Beta 2, appeared on Netscape’s Internet Web site. Additional public releases followed thereafter every few weeks until the official release date in August, with gradual refinements appearing in each beta iteration. The Development of Navigator 3.0: A Timeline The sequence of beta versions was extremely useful to Netscape because it enabled the development team to react both to feedback from users and to changes in the marketplace while the team was still working on the Web browser’s design. Beta users by and large are more sophisticated than Netscape’s broader customer base and therefore are a valuable source of information. Most useful among them are developers from other Internet software companies, who tend to be extremely vocal customers. Because many of these customers use the Navigator browser as part of the environment in which their own products operate, they are often the first to find the more complicated bugs—bugs that are revealed only when the product is stretched to the limits of its performance in complex applications. Getting input from users was one way in which the Navigator team generated new information during the course of the project. During the seven-month development cycle, however, the team also paid careful attention to competing products. As the largest and most powerful software developer in the industry, Microsoft was considered a very serious threat to Netscape’s then-dominant position in the browser market. The software giant had just undertaken a dramatic—and very public—switch in strategy, refocusing its formidable talents squarely on the Internet. As a result, Netscape continually monitored the latest beta versions of Microsoft’s competing product, Explorer, to compare features and formats. Based on the information that it gathered, the Netscape team would often add format or feature changes to the current beta version of its own product. In order to respond to the constant stream of new information being brought into the development process, the team carried out extensive experimentation and testing. Subgroups working on individual features went through numerous design-build-test cycles, gradually adding functionality to the product. As features were completed, the team integrated them into the evolving product, then conducted tests to ensure that the new feature did not produce unwanted interactions with other parts of the system. These so-called system builds occurred with increasing frequency as the project progressed; they were performed at least daily in the run-up to the official release. To facilitate the integration of the vast amounts of information generated during the project, Netscape set up a project Web site on its intranet. The site contained the product’s development schedule and specifications, each of which was updated as target dates changed or new features were added. In addition, it contained bulletin boards through which team members could monitor the evolution of various parts of the design, noting the completion of specific features and logging problems in the existing version. Once the Navigator moved to public beta testing, these intranet features became especially valuable because an increasing amount of information then had to be received, classified, and processed. Netscape built into its product-development process considerable flexibility to respond to changes in market demands and technology. And what is already true of companies in the Internet industry is becoming true of companies elsewhere. Our research on the computer-workstation-and-server industry has shown that there, too, a more flexible process is associated with greater performance. In this environment, companies with a faster response time, as measured from the construction of the first physical prototype to commercial shipping, clearly outperform those with slower response times. The use of sophisticated simulation tools allows teams to work with a virtual prototype for much of the project—in effect, creating a significant overlap between the concept and the design implementation phases. According to Allen Ward and his colleagues in “The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster” (Sloan Management Review, Spring 1995), there also is evidence that a more flexible model has emerged in the automotive industry. Toyota’s development process allows it to delay many design decisions until later in the development cycle. The development team creates several sets of design options and, finally, through a process of elimination, selects only one for implementation. As a result, Toyota can respond to changing market conditions at a later stage than many of its competitors. The Foundations of a Flexible Process How should companies create a flexible development process? The experiences of leading companies suggest that senior managers first must understand what gives the process its flexibility. Product development flexibility is rooted in the ability to manage jointly the evolution of a product and its application context. The goal is to capture a rich understanding of customer needs and alternative technical solutions as a project progresses, then to integrate that knowledge into the evolving product design. The faster a project can integrate that information, the faster that project can respond to changes in the product’s environment. The value of flexible product development, however, is only as good as the quality of the process it uses to generate information about the interaction between technical choices and market requirements. Unlike traditional development projects, which rely on periodic bursts of input on users’ needs, projects in turbulent business environments require continual feedback. To acquire and use this information, the development process must be able to sense customer needs, to test alternative technical solutions, and to integrate the knowledge gained of both markets and technologies into a coherent product. (See the chart “The Structure of a Flexible Product-Development Process.”) The Structure of a Flexible Product-Development Process As we describe how leading companies have achieved a more flexible development process, many of the examples we cite come from our work with several software companies that have recently launched Internet products or services. But bear in mind that this is not the only industry in which these lessons apply. We also describe specific practices from other, more traditional industries to illustrate that the approaches used are not unique to the Internet. In fact, they represent cutting-edge practice across a range of environments where change is—or is becoming—the norm. Sensing the Market. The first element of a flexible process is sensing the needs of customers and the market. Flexible projects establish mechanisms for getting continual feedback from the market on how the evolving design meets customers’ requirements. They do so by creating intensive links with the customer base—links that range from broad experimentation with many customers to selective experiences with a few lead users. Furthermore, these customers do not have to be external to the company: leading companies make extensive use of internal staff and resources to provide a test bed for evolving new products. Gaining continual feedback from customers was particularly critical at Netscape because of its dramatic head-to-head race with Microsoft. Netscape’s broad-based release of multiple beta versions to its entire customer base allowed users to play a significant role in the evolving product design. At the same time, it allowed Netscape to test an extremely complex technical product. Although not all Netscape’s customers actually experimented with beta versions, the Web browser’s most advanced users had to because they themselves were creating products that needed to work seamlessly with the Navigator release. And their feedback clearly had an impact: a significant portion of the new code, features, and technology that were integrated into the new release was developed only after the first beta version went public. Microsoft, Netscape’s chief rival, was slow to recognize the opportunities offered by the World Wide Web. Not until the end of 1995 did the company begin to focus on developing Internet products. Yet when Bill Gates and the rest of the senior management team finally acknowledged the need for a strategic shift, Microsoft’s development expertise was unleashed with astonishing speed. In the six months from the end of 1995 to the middle of 1996, the company went from having no presence in the critical browser market to offering a product that several industry experts claimed was comparable to or better than Netscape’s Navigator. Microsoft was able to react quickly because its existing product-development process had been founded on the rapid iteration of prototypes, early beta releases, and a flexible approach to product architecture and specification. (For a detailed account of Microsoft’s development process, see Michael A. Cusumano and Richard W. Selby, Microsoft Secrets [Free Press, 1995].) The process that Microsoft followed in developing its Internet Explorer was similar to Netscape’s but was more internally oriented. With more than 18,000 employees to Netscape’s 1,000 at the time, Microsoft could test successive Explorer beta versions extensively just by putting them up on its own intranet. “Everyone around Microsoft is encouraged to play with it,” explained a Microsoft program manager. “Internal testing means that we release it to thousands of people who really hammer away at it. We use the product much more heavily than the average Web user.” Microsoft combined broad internal testing by employees with carefully staged external beta releases, using only two or three in contrast to Netscape’s six or seven. The company thus limited the risk that imperfections in early releases might damage its reputation. A similar flexible philosophy can be used in the development of services. Consider Yahoo!. Founded in 1995, the company offers search, directory, and programming services for navigating the World Wide Web. As a service provider, the company believes that before a new offering is released to the outside world, it needs to be more robust than the typical Internet software beta. The market risk of broad, public testing is too high: users who try a new service once and have an unsatisfactory experience with it either are unlikely to return or, worse, may defect to competitors. Furthermore, Yahoo! assumes that competing companies will copy the innovative features of a new service once it has been released. These factors suggest delaying external testing to late in the development cycle. For these reasons, Yahoo! puts early versions of new services on-line for internal use only. Given its development team’s technical skills and breadth of experience, these trials expose any major technical flaws in the service and provide additional suggestions for improving functionality. Only then does Yahoo! begin a “soft release” of the offering: the service is put up on Yahoo!’s Web site but without any links to highly frequented parts of the site. As a result, only the more technically aggressive users are likely to find and use the service at this stage. Yahoo! also asks some of the 30,000 users, who have volunteered to be beta testers, to try the new service—thus exposing the service to rigorous external testing without revealing it to unsophisticated users who might be frustrated by a slow, incomplete, or error-ridden version. The Netscape, Yahoo!, and Microsoft examples illustrate several approaches to sensing customer and market needs: broad consumer testing, broad internal testing, and testing by lead users. Companies adopting a flexible development approach should consider the merits of each, as well as the potential for using a balanced combination of all. It is important to emphasize, however, that these techniques are not unique to the Internet. Advances in information technology now allow companies to sense customer needs in ways not possible a few years ago. Leading companies in many industries have begun to use these new capabilities. Fiat, for example, used a broad, external testing approach, not unlike Netscape’s, to evaluate several automobile concepts. A link on the company’s Web site directed customers to a page aimed at evaluating users’ needs for the next generation of the Fiat Punto, its highest-volume car, which sells about 600,000 units per year. Customers were asked to fill out a survey indicating their preferences in automobile design. They could prioritize the following five considerations: style, comfort, performance, price, and safety. Then they were asked to describe what they hated most in a car and to suggest ideas for new features. Next the software allowed customers to design a car themselves. They could select from a variety of body styles, wheel designs, and styles for the front and rear of the automobile. They also could examine different types of headlights, details, and features. In this way, users could experiment with different designs and see the results immediately on the screen. The software captured the final results; in addition, it traced the sequence that customers went through in evaluating and selecting options. This information told designers much about the logic customers used to evaluate features, styles, and characteristics in order to arrive at a given design solution. Fiat received more than 3,000 surveys in a three-month period, each comprising about ten pages of detailed information. The ideas suggested ranged from clever (an umbrella holder inside the car) to significant (a single bench front seat). Fiat used the information to inform a variety of styling and concept decisions for the next-generation Punto. And the total cost of the exercise was only $ 35,000, about the cost of running a few focus groups. Moreover, Fiat executives claimed that the surveys provided them with precisely the data they needed. The profile of the survey’s participants—trend-setting individuals with high incomes, who are 31 to 40 years old and frequent car buyers—was the target segment most useful to Fiat. General Motors’ Electro-Motive division has adopted a similar philosophy in its new virtual-product-development process. That process allows engineers to give customers digital tours of next-generation locomotives even as their development proceeds. Although the GM system is still evolving, the aim is to move to an all-digital environment in which the product moves electronically through concept design, analysis, prototyping, and manufacture, and along the way makes several stops on the customer’s desktop for feedback. Testing Technical Solutions. Sensing customer and market needs as a project progresses is one element of a flexible development process. If companies are going to allow a product’s design to evolve well into the design implementation phase, however, they also must adopt mechanisms that lower the cost of changes, speed their implementation, and test their impact on the overall system. Such mechanisms allow companies to evaluate and test alternative technical solutions at a rapid rate: the second element of a flexible development process. Early prototypes and tests of alternative technologies are critical to establishing the direction of a project. Consider NetDynamics, a company that develops sophisticated tools for linking Web servers to large databases. The single most important technical decision confronting NetDynamics during the development of its second product release was the early choice of language in its product. Either the company could develop a proprietary language, or it could use Java. At that time, in early 1996, the Java programming language had received a lot of publicity, but it was still highly unstable, relatively immature, and little understood. “We knew Java was going to be big,” recalled chief engineer Yarden Malka, “but it was still only available as a Beta 1 version. This meant that the development tools that went along with it were either terribly buggy or nonexistent. If we chose it, we knew we also had to develop many of our own tools.” NetDynamics’ commitment to an open platform tended to favor Java. If there was a standard—either existing or emerging—it should be used, and Java appeared to be that standard. To make the decision, however, NetDynamics’ engineers spent considerable time experimenting with various options, trying to become as comfortable as possible with the benefits and risks of each language. They began by developing simple prototypes and gradually migrated to more complex programs, attempting to gauge the advantages each would give the user. This “user-centric” approach to prototyping and experimentation was critical to the final choice and stands in stark contrast to the approach often adopted by high-tech companies in which technologies often are evaluated purely on the basis of the advantages they give the design team. As a project progresses, the design team must have the capacity to evaluate and test alternative design solutions quickly and cheaply. Yahoo! can easily do just that because of the way it has elected to provide its Internet service. The company meets its processing needs with many inexpensive computers instead of a few large (and expensive) servers. The small investment required for each machine allows Yahoo! to scale up its capacity smoothly to meet new demand. It also means that Yahoo! can easily run experiments to test different design options. According to Farzad Nazem, the vice president of engineering, “Our Web site setup works just like a spigot valve. If we want to test out a new product or feature on several thousand users, we promote it on the home page of only a few machines. As users access the service and we reach the required volume, we can turn off the promotion on each machine. We can also conduct comparative experiments by running multiple versions of the same service on different computers in the network, then track the results to see which version attracts more customers.” To reduce the cost of testing alternative design choices, companies outside the software industry increasingly have invested in new technologies for virtual design. By designing and testing product designs through simulation, for example, companies achieve the flexibility to respond to new information and to resolve uncertainties by quickly exploring alternatives. Computer-aided design software also has dramatically reduced the cost of design changes, while at the same time speeding up experimentation. At Boeing, for example, the all-digital development of the 777 aircraft made use of a computer-generated “human” who would climb inside the three-dimensional design on-screen to show how difficult maintenance access would be for a live mechanic. Such computer modeling allowed engineers to spot design errors—say, a navigation light that would have been difficult to service—that otherwise would have remained undiscovered until a person negotiated a physical prototype. By avoiding the time and cost associated with building physical prototypes at several stages, Boeing’s development process has acquired the flexibility to evaluate a wider range of design options than was previously possible. Integrating Customer Needs with Technical Solutions. It’s no good knowing what customers want in a product under development if the development team can’t integrate that information with the available technical solutions. As a result, all the organizations we discuss have established dynamic integration mechanisms. Some of them are based on well-understood concepts, such as using dedicated teams—an approach adopted by Netscape, NetDynamics, and Microsoft. Others are less traditional. All three companies, for example, use their intranets to integrate tasks, synchronize design changes, and capture customer information as projects evolve. Thus project teams are able to keep track of the evolving relationships among tasks, schedules, and design changes in a dynamic way. Such integrating mechanisms are essential for managing a flexible process, given the many rounds of experimentation and the wide range of information generated. Without a way of capturing and integrating knowledge, the development process can quickly dissolve into chaos, with ad hoc design changes creating masses of rework because of unanticipated interactions with other components in the system. In the Internet world, integrating mechanisms are dictated by the nature of the product—software. Each of the projects we describe adopted sophisticated design-integration tools to hold the master version of the emerging product. As team members went to work on individual components, they checked out the code for that part of the system. Once finished, they had to run a series of tests to ensure that the component did not create problematic interactions with the rest of the system. Only then could they check in the new component. At the end of each day, when all the new components had been checked in, engineers ran the program. Any problems that occurred had to be corrected before new code could be permanently integrated. Similar approaches are found in projects outside the Internet world where new information systems allow companies to share knowledge more effectively. At Silicon Graphics, a leading manufacturer of workstations and servers, a new product-introduction process makes extensive use of the company’s intranet to coordinate development activities. Managers and engineers throughout the world, who respond daily to the problems of current customers, provide input during the concept-generation stage. In addition, lead users in target application segments (referred to as “lighthouse” customers) are linked directly to the development teams, allowing the teams to get fast and effective guidance on critical decisions as the project evolves. The intranet also is used to integrate design tasks on a daily basis. Project engineers work from a shared body of software that simulates the hardware design. As with the Internet projects, when team members want to make a change, they check out the relevant code, make the desired design improvements, test it for errors and unanticipated interactions, then check it back in. Such approaches are not limited to high-technology products. Booz Allen & Hamilton, a management consulting firm, approaches the problem of integrating a diverse and geographically dispersed knowledge base by using its intranet. The intranet allows consulting staff quickly to locate and contact industry experts with specific skills and to identify previous studies that are relevant to current projects. In this way, the collective experience of the organization is available to all employees online. The intranet also allows the company to develop its intellectual capital. In management consulting, new-product development consists of developing new frameworks, industry best practices, performance benchmarks, and other information that can be applied across projects. By having these products on-line during development and thereafter, Booz Allen can integrate new information and experiences into its knowledge base. Integrating within the company, however, is not always sufficient. In some cases, the ability to integrate knowledge across networks of organizations may also be important. For Internet software companies, given the novelty and complexity inherent in their products and the rapidity of their development cycles, no single organization can research, make, and market products alone. Instead, they take advantage of technical possibilities that are beyond the boundaries of any individual company; those technologies can then be integrated into their own core products. (Internet users will be familiar with Java applets and Web browser plug-ins.) Doing so, however, means that just as the technologies must be seamlessly integrated into a product, so must the organization accommodate a changing cast of players. The companies we describe have built alliances with third-party developers, engaged in joint development projects, and worked hard to foster open product architectures and modular designs. And such arrangements are not peculiar to software. Workstation manufacturers such as Sun, Hewlett-Packard, and Silicon Graphics frequently engage in joint development efforts with other hardware companies (such as Siemens, Intel, Fujitsu, Toshiba, and NEC) to leverage the performance of their systems. Putting Flexibility to the Test In combination, the foundations of a flexible product-development process allow a company to respond to changes in markets and technologies during the development cycle. We found a striking example of how that is done in a setting that is about as far from the typical high-tech world as one can get: the America’s Cup. In 1995, a small team from New Zealand dominated the races from start to finish. Team New Zealand’s effort shows how the mechanisms we have described can be combined to dramatic effect in a flexible process. A flexible approach allows companies to respond to changes in markets and technologies during the development cycle. Team New Zealand recruited Doug Peterson, who had been on the winning America’s Cup team in 1992, as its lead designer. It also recruited an experienced simulation team to make use of advanced design software. Although Peterson’s extensive experience drove the initial concept design, once the team’s yachts were constructed the emphasis shifted to evaluating design changes through thousands of computer-simulated design iterations. The simulations were run on a small network of workstations located a few feet from the dock. To ensure rapid feedback on the performance of design changes, the team built two boats. Each day, one of them was fitted with a design change for evaluation; then the two boats raced each other to gauge the impact of the change. Team New Zealand’s flexible process sensed “market needs” through the two-boat testing program, which generated feedback each day on how the evolving design fit the racing environment. It tested alternative designs through a simulation program that was directed by one of the world’s most experienced yacht designers. And it integrated knowledge by making the resulting information available locally. The crew, design team, and management were therefore able to make suggestions for the design, to see the impact of potential changes, and to know what to expect when those changes were tested on the water. The U.S. boat that Team New Zealand faced in the final race had been designed on the latest super-computers with the support of large, well-heeled corporations. Although the U.S. team could test a massive number of experimental designs, the computers were located hundreds of miles from the dock. As a result, there were significant delays between detailing a design and getting feedback on results. Furthermore, the team had only one boat on which to test design changes; given the varying sea and wind conditions, it took far longer than its rival to verify the impact of a change. Team New Zealand’s approach had better mechanisms than its U.S. rival for sensing, testing, and integrating what it had learned. Its flexible process produced a yacht of superior design, which many observers believed to be a full generation ahead of its competitors’ boats. As Paul Cayard, skipper of Team New Zealand’s opponent in the final race, remarked, “I’ve been in some uphill battles in my life. But I’ve never been in a race where I felt I had so little control over the outcome. It’s the largest discrepancy in boat speed I’ve ever seen.” Using a flexible development process, Team New Zealand produced a superior yacht—and beat its U.S. opponent. We have seen a similar pattern throughout many environments we have studied. Organizations that have adopted a flexible product-development process have begun to transform the very industries that forced them to adopt it. They have implemented strategies that companies clinging to traditional approaches cannot follow. Competitors without flexible development processes will almost certainly find their industries growing more and more turbulent in appearance. And in such an environment, their products and services will always seem to be one step behind those of their more flexible rivals.

Developing Products on Internet Time

Partner Center