2000 Product Development Management Columns

Are Your Inmates Out of Touch?

Alan Cooper, author of the provocative book, The Inmates Are Running the Asylum (SAMS, 1999), clarifies why modern software is frustrating to use. Though we might be inclined to blame our own stupidity, Cooper demonstrates that these issues stem from the programmers: they live in another world, and their managers allow them to take up residence there. This would not be so serious if we were just talking about packaged software, such as Windows, Acrobat, or Netscape. Unfortunately, it extends to a much broader group of products that incorporate software: VCRs, ATMs, car-entry systems, telephones, and cameras.

For instance, Cooper, himself an engineer who loves electronic gadgets, has owned several VCRs over a twenty-year period. Today, with all of his experience in using them, his success rate in recording a delayed broadcast is less than 50-50!

Our products can be better. If I go to the ATM at my local (Portland, Oregon) bank, I find it slow and frustrating. However, if I fly halfway around the world, instead of the communication delay I expect due to the distance and language issues involved, I am delighted to find that I can withdraw cash from the ATM in the main hall of the Singapore airport in half the time, with fewer than half the keystrokes, and with a much greater sense of dignity. My USBank ATM always asks me if I want Español, even though I always opt for English; it keeps asking me if I want a receipt, ignoring my track record of always answering "yes;" and it continually asks me if I want to withdraw from checking or savings, when I don't even have a savings account. Once, I did hit the savings key by mistake, and I received a stern warning that I had screwed up, not that USBank had made a mistake in offering me that option.

These issues come to a head with software. This is partially due to the complexity of software development, but also because adding extra features often seems easy—a situation that leads to feature proliferation. However, the root cause is that the folks who develop these products (in this case, the programmers) are out of touch with their users. Cooper shows that programmers live in a world of logic inhabited mostly by other programmers. In this world, it is difficult for them to imagine that anyone would have difficulty in understanding how the software's logic works.

In Developing Products in Half the Time [pp. 94-95], we illustrate how developers build products to meet the needs of surrogate users that exist in the mind of each developer. If developers lack contact with genuine users, the developers themselves serve as the "default" surrogate users. This "default" surrogate user gets replaced only when the developer experiences real users. We offer two principles for building such realistic user surrogates [p. 93]:

The developers themselves—those who are making the daily design decisions—must be the ones in touch with users (not through middlepeople, such as marketing).
This contact must occur before development begins (not on field calls afterwards).

Cooper offers additional tools. These are aimed at software development but could be adapted to hardware projects as well. His most powerful tool is personas. A persona is a carefully constructed description of a user, including a name, a portrait, and a description of certain idiosyncrasies that help render this individual real to the developers. For instance, in designing an airline in-flight entertainment system, the key persona was Clevis McCloud, a crotchety 65-year-old Texan with a touch of arthritis, who had never used a computer. If Clevis could enjoy the system, anyone could. To ensure that the resulting design didn't rule out others, the team also built personas for Ethan Scott, a 9-year-old whose only interest was playing games on the screen from takeoff to touchdown, and Amanda Hopper, the flight attendant who had to keep the system running and the passengers happy throughout the trip.

Notice carefully that these personas turn normal project objectives on their heads. Normally, programmers work to a long list of features required by marketing, offered by competitors, or demanded by certain customers. Here, the goal is unwritten but far more focused: "all" they have to do is make Clevis happy and ensure that they don't annoy Ethan, Amanda and a few other specified personas. The "inmates" featured in Cooper's book are now in touch!

How about your "inmates"?

Return to newsletters | Product development publications | Home

Deploying Product Development Expertise

Consider how you might develop a product, such as a cellular phone, having a highly complex plastic housing. These days, such housings employ organic shapes with no straight lines, and the final product must withstand a harsh environment, including accidental drops. Such products demand a high level of design expertise.

Designing a cellular phone housing requires three kinds of design expertise:

Industrial design, for an attractive, intuitive, easy-to-use product
Mechanical design of the housing, to provide certain product functions while being robust in assembly and final use
Mechanical design of the tooling, which creates the molds rendering both the industrial design and the housing mechanical design.

Traditional practice has been to place these three types of experts in their respective departments and transfer the evolving design from department to department—over the wall, as it is often called. Not only is this sequential process slow, but it is wasteful too. Once the design gets to housing engineering, these engineers are bound to find some industrial design details that they cannot incorporate mechanically, so the project returns to industrial design for modifications. This squanders time and resources, and it also can bruise egos on both sides.

This scene replays as the project moves to tooling design. Inevitably, the tooling engineers discover features of the previous work done that cannot be executed in the tool, so they must return to earlier departments to negotiate a workaround. The process that looked so straightforward on paper is, in fact, riddled with inner loops of redesign.

"Best Practice"

As we will see, "best practice" is a relative term. However, the state of the art for most manufacturers today is to overcome the over the wall process by involving downstream players in the process early. Housing engineers work with the industrial designers while the project is in the industrial design phase to identify and avoid many issues while they are still easy to resolve. Likewise, tooling engineers become involved in earlier stages to ensure that the evolving design is manufacturable.

Companies that aspire to early involvement have discovered that it is not so easy to do in practice. First, there is the question of how early is early enough. Due to workloads in the downstream functions, seldom is the downstream expertise applied early enough. Second, how intensive does the early involvement have to be? We have learned that genuine early involvement requires devoting real mindshare to the upstream design, not just attending a few meetings.

Going Further

Even with clear, adequate requirements for 'how early?' and 'how intensive?' some issues still do not get caught soon enough. Moreover, this consultative role teaches the players only a limited amount about what really goes on in the other departments. This is still a sequential process with a few Band-Aids applied at critical junctures.

Product Development Technologies, Inc. (PDT), a Lincolnshire, Illinois developer of sophisticated plastic parts and molds, takes a major step beyond today's "best practice." PDT organizes into the three departments described above. However, they routinely cross-train their designers by transferring them between departments for the life of a project in that department. For instance, a housing mechanical engineer becomes a full-time member of the industrial design team while the project is in industrial design. Not only does the mechanical engineer get to "walk in the industrial designer's shoes," but he or she is also there to provide instantaneous monitoring and consultation on potential downstream issues. The cross-training goes both ways between all three departments. Such cross training is the expectation at PDT: designers in all departments are hired, promoted, and rewarded in accordance with it.

This cross training is relatively easy at PDT, simply because the firm is so fast in developing products; designers can co-locate with another department for the length of a phase and still not be away from their home department for long. PDT can complete industrial design, housing mechanical design, tool design, and tool building of a complex housing in about eight weeks. Nevertheless, this is a technique that firms in other industries can apply to move beyond "best practice;" if they are not as fast as PDT, it would represent a bigger commitment for them. However, the benefits are substantial, with respect to both time-to-market and more effective use of resources.

Return to newsletters | Product development publications | Home

Want Virtual Results? Use A Virtual Team

Increasingly, managers are turning to virtual teams to develop new products. But increasingly, they are displeased with the outcomes: mediocre performance or lackluster products. There is a more effective alternative: co-location. But first, we must understand why virtual teams have become so popular.

Virtual teams sprout from two sources. One is new communication technologies— everything from overnight express to the Web— that allow activities to be carried out at a distance. The other factor is subtler but more disturbing. In my experience, many companies are fragmenting their operations geographically. Through acquisitions and mergers, they unwittingly split their product development resources among dispersed sites, believing that technological patches will cover any gaps created.

Even without acquisitions, most manufacturers are becoming more global. Sales and marketing activities now span oceans, and manufacturing is done offshore to cut costs. Consequently, we now design products for markets on various continents, in several time zones, for people in many cultural traditions, speaking many different languages. The same complications often arise when integrating design with global manufacturing.

Management seems to presume that virtual technologies will advance fast enough to effectively overcome geographic dispersion. To some extent, this is true. Videoconferencing saves travel expense, time, and jetlag. E-mail allows us to work in multiple time zones and easily broadcast information to as many individuals as desired. However, e-mail also allows critical decisions to sit in an in-box indefinitely. Worse, we have no idea whether our e-mail message was understood or is being acted upon. Yesterday's phone tag has become today's e-mail tag.

Recent books, such as Mastering Virtual Teams (Duarte and Snyder) and Virtual Teams (Lipnack and Stamps), suggest how to work with virtual teams. But these books seem to presume that physically co-located teams are impossible. These authors show us how to survive with what we seem to be stuck with. Yet, all the managers I know who have experienced the power of co-location would employ it again if time-to-market were critical. These managers will go to great lengths to provide as much co-location as possible for their development teams.

So, how do we provide co-location in a fragmented, global world? First, recognize that if speed to market is critical, time is money. Calculate the cost of delay (Chapter 2 of the book Developing Products in Half the Time: New Rules, New Tools, [John Wiley & Sons, 1998] shows how). Be willing to spend money to get the team together. For example, Carrier Corporation couldn't co-locate a team developing a new air conditioner because they were assigned a manufacturing site and a test facility in different regions, that they could not move. They compensated by conducting liberal team training at the project's outset, spending generously on travel for the whole team, and pre-booking eight hours of videoconference time every week for the duration of the project. Carrier essentially bought time through co-location.

If you can bring the team together for only part of the project, make it the initial portion, for several reasons. The team needs time together initially to build trust. At this time they should explicitly establish the work methods they will use throughout the project and decide on roles and responsibilities. With this groundwork in place, the team will feel comfortable moving much faster later in the process.

Another reason for an emphasis on early face-to-face communication is that this is the stage of the project when the issues to be communicated are the most ill-defined. In-person communication will help greatly in quickly and accurately resolving this fuzzy material.

Think about who most needs to be co-located. You can obtain much of co-location's benefit at a reasonable price by analyzing your teams to discover the intensive communication links, then co-locating these partners.

Finally, realize that the alternatives to co-location are not equal. Consider them in terms of the electrical engineering concept of bandwidth. E-mail requires very little bandwidth to communicate electrically, but it can't communicate graphics, emotions, sounds, or tempo. The telephone requires more bandwidth, but provides some communication richness. Video is broader bandwidth still, and is also richer. The ultimate in both measures— bandwidth and richness— is face-to-face presence. The books listed above will help you judge when each medium is needed.

Now that I have used co-location liberally, I should define it, because I find that many people who haven't yet accepted it tend to water it down— getting watered-down results in return. A co-located team is one in which marketing, engineering, and manufacturing (at least) are located in a 30-by-30-foot area, such that they can see each other while working and overhear each other's conversations.

Return to newsletters | Product development publications | Home