How are great products conceived and developed? In 1991, Clark and Fujimoto's book Product Development Performance[13] presented strong evidence that great products are the result of excellent, detailed information flow. The customers' perception of the product is determined by the quality of the flow of information between the marketplace and the development team. The technical integrity of the product is determined by the quality of the information flow among upstream and downstream technical team members. There are two steps you can take to facilitate this information flow: 1) provide leadership, and 2) empower a complete team.
LeadershipWe have long observed that successful development efforts are highly correlated with the existence of a championa person who deeply understands the customers' job and the technology that will surprise and delight those customers A champion has the responsibility for making key product decisions and the accountability for the results of those decisions. Martin Cagan of the Silicon Valley Product Group says:[14]
When we see struggling development programs, we usually observe that the champion role does not exist. There are several different models for implementing the role of champion. The best models clarify who has responsibility and accountability for the success of the product. The Chief EngineerAt Toyota, a chief engineer is held responsible for the business success of a vehicle family. This leader is a seasoned engineer with an in-depth knowledge of vehicle design. With the assistance of a small staff, he develops a deep understanding of the target customers and what they will value. He looks at marketing research, talks to dealers, and goes to places frequented by his target customer base to watch and ask questions. He checks with advanced development, styling, and production engineering. He gets input from finance and direction from senior management. In the end, however, it is the chief engineer who personally integrates this information, decides what customers will value, writes the product concept, and directs its development.[15]
Consider the Sienna. The first version of the Toyota minivan didn't sell particularly well. When Chief Engineer Yuji Yokoya set out to improve the vehicle, he knew he needed more than focus groups and voice-of-the-customer data. So he followed Toyota tradition of genchi-genbutsu, or "go, see, and confirm." He drove a minivanusually a Siennafor 85,000 km (53,000 miles) through every state in the United States, every province in Canada, and every estado in Mexico. He usually traveled with a key member of the design team, including John Jula, a good-sized engineer who would redesign the seats. As he traveled, Yokoya came to understand what Sienna customers would value: more space, comfortable front seats for parents, a back designed for kids, and family pricing. The resulting 2004 Sienna more than doubled the minivan's sales and raised the Sienna to the top of a crowded pack. We recently bought a Sienna minivan. We seriously considered other vehicles, but we found the foot space in the front passenger seat of competing minivans to be cramped. We drive our minivan for days when we are on vacation, so front seat comfort is really important to us. When we test-drove a Sienna, we could tell that John Jula was thinking of us when he designed the front passenger seat of that car. The chief engineer approach has the advantage of integrating a lot of information in the mind of a single, responsible individual. In addition, the entrepreneurial spirit that ownership creates has a long history of bringing brilliant innovations to the marketplace. Teams love to follow great leaders, because great leaders help make whole teams successful. Most Open Source projects have a "Strong Project Leader" (or Chief Engineer).[16] These Open Source projects start out with the vision of one individual, and even when many volunteers are working on the project, all code is reviewed and "committed" by the project leader or hand-picked assistants.
The chief engineer approach is not a panacea. It is possible for someone with the title of chief engineer to focus on control rather than leveraging the diverse capabilities of the entire team. This is not a problem in Open Source projects, because it is impossible for Open Source project leaders to attract volunteer developers unless they are "leaders" in the best sense of the word. However, it can be a problem in companies that do not have good training grounds for chief engineers or in companies that believe a chief engineer should focus on task management rather than integrating knowledge. Many successful software companies were founded by an entrepreneur who combined technical capability with a clear insight into an unfilled market need. eBay is a good example. In effect, these companies were started by chief engineers. Unfortunately, we have seen many successful chief engineers who founded companies become unsuccessful CEOs as their companies grow. They neglect to create new chief engineers to replace themselves, often turning over the job of defining customer value to a marketing department. After five or ten years, these companies often falter as competitors take over the initial market and there is no chief engineer to envision the future and lead teams to create great follow-on products. Leadership TeamThe goal of development is to fill some need that has thus far gone unfilled, either because a new technology makes it possible to fill the need, the need was not recognized, or some combination of the two. Sometimes the best way to bring these two ideas together is to have two leaders, one with a deep market understanding and the other as a technical lead. At Intuit, for example, the practice of pairing a product marketing expert with a technical expert started with the founders. Scott Cook created the market vision for Quicken while Tom Proulx led technical development.[17]
When there is a third critical piece of the equationmanufacturing for exampleit makes sense to have three leaders for a product development effort. Honda uses a sales, engineering, and developmentor SEDsystem in which leaders from sales, production engineering, and development work as a team to come to key product decisions. Above the SED leadership team, Honda also has a Large Project Leader (LPL), whose role is similar to the Toyota chief engineer. It is important to provide leadership at the most critical points of a product. For example, at Alias (now part of Autodesk), a Toronto company that makes 3-D graphics products, the user experience is a critical feature of every product. Therefore, two interaction designers are assigned to as many teams as possible with full responsibility for customer research, interaction design, and usability testing.[18] A lot of customer feedback is solicited through contextual inquiry, interviews, surveys, and usability testing. But the interaction designer is expected to integrate that input with a deep understanding of the job the software is trying to accomplish, and design a product that will accomplish the job in a superb manner.
Members of a leadership team must be "joined at the hip" so to speak, creating a unified direction for the entire development team. Shared LeadershipThe Chrysler NS minivan platform (Caravan/Voyager/Town and Country) was an instant hit when it was introduced in 1996. It redefined the minivan concept by adding a driver's side passenger door and received Motor Trend's Car of the Year award. In fact, we owned a 1997 Chrysler Town and Country minivan for eight years. This car was not developed by a chief engineer but by a team of experts, who worked together to come to a common understanding of what customers would value. The team conducted extensive market research, did detailed quality function deployment (QFD) analysis, and even developed usability experiments to help make specific decisions. The team was dedicated and colocated, and it spent a lot of time (usually one day a week) reviewing status, educating each other, and solving problems. The team leader's primary job was to manage the development process, fostering cooperation and team building, pushing for consensus decisions, and keeping the team on the right path.[19]
Although it does not bring clarity to who has responsibility and accountability for decisions, the shared leadership approach can work for moderate-sized software development projects. In the Open Source community, Apache is a good example of a shared leadership approach.[20]
Who's Responsible?Good marketing and technical leadership does not preclude an involved team that goes on customer calls together, asks questions from various perspectives, and develops a shared view of customer value. Mary's product development experience was at 3M, where conventional wisdom says that every new product needs a "champion." The champion is usually a technical expert who has found an unmet market need and developed the technology to get the job done. But a champion cannot be successful unless she or he works with a cross-functional team that, in effect, forms a mini business unit to commercialize the new product. The team works together to clarify market needs and determine key product features. This combination of a champion and a team with members from all important business functions has served 3M for decades, generating incredible growth through the introduction of thousands of new products every year. At 3M, the development team generally comes to a consensus on key decisions, but in the end, the champion is responsible for the product and breaks any deadlocks. Similarly, at Toyota the basic principle is, "Teamwork is the key to getting high quality work done, but some individual always needs to be responsible."[21] In "Who Has the D? How Clear Decision Roles Enhance Organizational Performance" Paul Rogers and Marcia Blenko argue that good decision making is the hallmark of high-performing organizations and clarity of the decision-making roles is fundamental to making good, timely decisions.[22]
Complete TeamsComplete products are developed by complete teams. When Intuit executives decided to develop Quicken Rental Property Manager, they established a development team led by a brand champion that included everyone necessary to put the product on the market, "not just software engineers."[23] The team members had worked together beforethey were veterans of 20 years of Quicken upgrades. But this was a first for the team. A new Quicken-branded product would be developed for the first time in many years. The team's charter was to solve the customers' problemno more and no lesswhile developing just enough process to accomplish the task as quickly as possible.
The development team decided that its main job was to learnlearn about the customers' job so they could develop just the right features, and learn about what kind of process would provide just enough structure without any waste. The team checked in with the management team on a regular basis to report on status, receive guidance, and get approval to continue to the next checkpoint. At each of these meetings the development team reported on what it had learned and what it planned to learn by the next checkpoint. Except for guidance received at these meetings, the team made both product and process decisions on its own. The Quicken Rental Property Manager team began by going as a group to interview customers. Team members found that developers asked different questions than did marketing people and that everyone gained a deeper insight because of the various perspectives. They found that the development process didn't require nearly as much paperwork as before, because everyone heard the same thing from customers. Team members were energized by the challenge and became thoroughly engaged in developing a new process and a new product. Within a year, Quicken Rental Property Manager was released to reviews that raved about its clean interface and simple setup and operation. Design for OperationsOne of the big advances in manufacturing quality occurred when production engineers were asked to join the product design team. Every design was evaluated for ease of manufacturing before it was approved, and suddenly we began to see products that were not only easy to manufacture quickly but also easy to service. This was called design for manufacturability.
In software development, the equivalent of design for manufacturability is design for operations. Some of the more underrepresented functions on software development teams are computer operations, networking, maintenance, and customer support. Every development team should have members who will challenge the team to consider what kinds of problems arise when software is actually being used in production and what capabilities are necessary to both avoid and recover from those problems.
|