The Customer-Focused Organization


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.

[13] Kim Clark and Takahiro Fujimoto, Product Development Performance, Harvard Business School, 1991.

Leadership

We 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]

[14] "Behind Every Great ProductThe Role of the Product Manager," by Martin Cagan, Silicon Valley Product Group; white paper downloaded from www.svproduct.com. February 7, 2006. Used with permission.

Behind every great product there is a person with great empathy for the customer, insight into what is possible, and the ability to see what is essential and what is incidental. This person has a deep understanding of the customer as well as her own teams' capabilities. She operates from a strong basis of knowledge and confidence. She thinks in terms of delivering superior value to the marketplace, and she defines good products that can be executed with a strong effort. This person may have the title of product manager or may happen to be anyone on the product team from an engineer to a company founderthe key is that this role must exist and the responsibilities carried out by someone with the skills and talents the tasks demand.

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 Engineer

At 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]

[15] Information in this paragraph is from Chapter 7 of Durward Kenneth Sobek II's "Principles That Shape Product Development Systems: A Toyota-Chrysler Comparison," a dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Industrial and Operations Engineering) at the University of Michigan, 1997.

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.

[16] See Eric S. Raymond, "The Cathedral and the Bazaar," www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/, 2000.

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 Team

The 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]

[17] See Suzanne Taylor and Kathy Schroeder, Inside Intuit, Harvard Business School Press, 2003.

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.

[18] Lynn Miller, director of user interface development, Autodesk, Toronto, "Case Study of Customer Input for a Successful Product," Experience Report, Agile 2005.

Members of a leadership team must be "joined at the hip" so to speak, creating a unified direction for the entire development team.

Shared Leadership

The 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]

[19] Sobek, Ibid. Sobek personally observed this team in action and reported on it in his thesis.

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]

[20] See Roy T. Fielding, "Shared Leadership in the Apache Project," Communications of the ACM, April 1999.

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]

[21] James Morgan and Jeffrey Liker, The Toyota Product Development System: Integrating People, Process, and Technology, Productivity Press, 2006, p. 103.

[22] Paul Rogers and Marcia Blenko, "Who Has the D? How Clear Decision Roles Enhance Organizational Performance," Harvard Business Review, January 2006.

Assigning a Decision Maker

I was the champion for several new products at 3M. I found it to be a very challenging and rewarding role.

Disagreements naturally arose during our weekly product development team meetings, because different functions have different perspectives. Sometimes I wondered if quality ever wanted to release a product to the market or if marketing appreciated that developing a product was hard work. I noticed that the disagreements often focused not on the merits of the decision, but on who got to decide.

Therefore I found it very helpful to appoint a decision maker. I chose the function most appropriate to make the decision on the tablequality would approve final release, marketing would decide which shows we would be in, development would decide if a technical feature was easy or difficult, and so on.

I found that once I appointed a decision maker, the tenor of the discussion immediately changed. Team members started lobbying the decision maker to see their point of view. The decision maker changed his or her viewpoint to be more inclusive of others. And the subsequent discussion usually focused on the merits of the decision, not on who got to make it.

Mary Poppendieck


Complete Teams

Complete 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.

[23] Reported by Soni Meckem at the Lean Design & Development 2005, Conference, Chicago, March, 2005.

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 Operations

One 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.

Design for Manufacturability

Long ago in our plant, video cassettes were assembled by hand. The plant manager asked all department heads to spend time working on the line, so I worked an occasional late-night shift assembling video cassettes. There was one screw that had a piece of plastic that got in the way of a screwdriver, so we had to use a specially-made angled screwdriver for that screw. Every time I had to reach for that special tool and fiddle to position the screw, I dreamed about getting the designers on the line to assemble a few cassettes themselves.

Later when design engineers reported to me, I always required that their designs be reviewed by manufacturing before they were finalized. At first the designers found this puzzling, but in no time they gained a healthy respect for the reality of manufacturing. Soon they were bringing their drawings to the manufacturing supervisor for his comments every couple of days. Needless to say, the new designs were easy to assemble.

Mary Poppendieck


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.

Everything That Can Possibly Go Wrong Eventually Will Go Wrong

A friend and former developer, who is now an operations manager, has a favorite saying for developers to keep in mind: "Everything that can possibly go wrong eventually will go wrong in production, and we need ways to find and contain the problem and then recover from it." Recently he wrote to describe his latest problem.

"A company 'XZY' is rolling out new releases of their software basically every week. These releases tend to be feature complete and not exhibit too many regression bugs. The main problem is that the software is unstable either over time or under load. When it passes functional testing in QA, it is often unready for the demands of production."

I suggested a root cause analysis of the cause of each failure. Turns out, he was way ahead of me.

"Thorough postmortem analysis is absolutely a part of every single problem response. What we are finding is not a single, recurring failure, but a pattern of failures that are all ultimately related to unsafe coding practices. The application developers at XZY find new ways to crash the site nearly every week."

Unfortunately, the development team no longer felt responsible for the software and was uninterested in the results of the failure analysis.

Mary Poppendieck





Implementing Lean Software Development. From Concept to Cash
Implementing Lean Software Development: From Concept to Cash
ISBN: 0321437381
EAN: 2147483647
Year: 2006
Pages: 89

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net