2003 Product Development Management Columns

It's Not About the Technology

This past summer, bicycle racer Lance Armstrong won his fifth Tour de France, cycling's equivalent of the Super Bowl. Armstrong has written his amazing story, insightfully entitling it It's Not about the Bike.

Yet, if you wander into your local bike shop, you are likely to find some guys in the corner debating the merits of clincher tires versus tubular tires, rather than being out on the road exercising with whatever tires they happen to possess. Or you will find a customer agonizing over upgrading to a Dura-Ace crankset for $270 to pare 43 grams from the weight of her bike, totally ignoring the PowerBar (i.e., candy bar) she just ate, which itself weighed 65 grams.

As with cycling, in product development it is easier to dwell on the technology and ignore the behavioral issues that render it effective. In fact, product developers are more susceptible to this than the general population, because the techies, who normally inhabit product development teams, are even more inclined toward technical solutions to problems.

In a recent book, Experimentation Matters: Unlocking the Potential of New Technologies for Experimentation, Stefan Thomke describes a host of recent technologies to enhance simulation, modeling, testing, and prototyping for product development. However, he states, "... it is not necessarily what the technology is that matters but how it is used (Page 145)." The key to effective utilization is the accompanying behavioral, cultural, and organizational changes that enable the new technology to function effectively.

Thomke doesn't provide much guidance on making these critical behavioral changes, but his colleague at Harvard Business School, John Kotter, the guru of organizational change and leadership, does. In his book, The Heart of Change, Kotter identifies eight steps necessary for enduring organizational change, based on extensive research, and he provides case studies illustrating how organizations have either executed such steps or failed to follow them. I'll outline his eight steps briefly:

Create a sense of urgency. Unless people recognize that the current situation is unacceptable and things must change, then start telling others this, your change program is unlikely to get off the ground.
Build a guiding team. Its members must possess the relevant knowledge, know how the organization works, provide credibility and authority, and know how to lead. A single manager, at any level, has neither the time nor the knowledge to do it all.
Create a vision and supporting strategies. Although the vision may rule out certain areas as unnecessarily risky, it must be bold and ambitious, making clear that extending the status quo won't work. It must also provide an imperative for speed (see step number 1).
Communicate the vision. This vision must be spread throughout the organization, via multiple media, in terms that people can understand. The goal is to build buy-in so that the program extends beyond the guiding team.
Empower individuals to take action. This amounts to identifying and removing barriers. Often, an important one is the reward and compensation system: are people receiving bonuses for making the change or for resisting it? Are they apt to lose their job if the change prevails?
Create short-term wins. You must build momentum at this point, and complete victory may be so far off that people lose interest. A solution to this is to identify some quick, highly visible illustrations that change is occurring. This will also provide valuable feedback to the guiding team and marginalize the naysayers.
Keep your foot on the accelerator. The pitfall of short-term wins is that people start believing that they are victorious prematurely. Once you have picked the low-hanging fruit, the rest will be harder. At this point, you can start jettisoning some of your old baggage, which will provide more time to make the remaining changes - and ensure that you can't go back!
Make the change stick. Unfortunately, even if you achieve your goal completely, you will not have achieved enduring change. Tradition has amazing staying power, so people tend to revert for some time. Among other things, the compensation, hiring, and promotional system all must be realigned with the new mode.

In summary, installing a new technology or new concepts, as fantastic as they may seem, will be of little value until you successfully deal with the accompanying behavioral changes. Fortunately, Kotter provides a path to follow.

Return to Newsletters | Return to Publications | Return to Home

Do It Wrong the First Time

Computers allow us to do many wonderful things today but, in many cases, our thinking about how to use this tool wisely hasn't caught up with rapid advances being made in the technology. It's like the horseless carriages of a century ago: they still looked like, and were operated much like, horse-drawn carriages!

A similar thing could be said about prototyping, a vital tool of product development. Prototyping has received more attention lately, in part from Professor Stefan Thomke of Harvard Business School (See "Enlightened Experimentation: The New Imperative for Innovation" in the February 2001 Harvard Business Review). He and others are finding that the new prototyping tools available today can only be exploited by rebuilding our product development process - and our mindset - to take advantage of what modern prototyping can do.

For example, using modern computer technology, you can "do it right the first time" by completing a great deal of design, analysis, simulation, and checking of a new part on the computer. This means that the first time you actually make the part, it is "right," at least in an engineering sense. As the engineers are going down this route to perfection, however, the design is hidden from customers, partners in the distribution channel, suppliers who will have to make it, and even the test engineers who must design a test for it. Engineers - all of us, actually - prefer this approach because it comfortably shields us from criticism of our half-baked ideas.

What Thomke, et al., are discovering is that it is actually faster, and more accurate, to do it wrong the first time. Get something - almost anything - out there and let others react to it and tell you what is wrong with it before you go down a path that won't delight them. Expose your ignorance, but do it quickly so that you can then move forward more surely. Furthermore, this line of thinking suggests that you keep exposing your ignorance as you go, continually drawing in others whom you will eventually have to satisfy.

Unfortunately, developers of computerized prototyping tools are mostly pursuing other objectives. Rather than rapid, cheap prototypes that allow you to expose your ignorance early, they are developing prototyping tools that will build an elegant, expensive, "perfect" part later. There are some important exceptions to this trend, but you will have to search to find them, and you will have to be clear about what you're seeking.

What is more difficult is that you and others in your organization will have to think about product development and "failure" quite differently in order to take advantage of modern prototyping capabilities. It is useful to think of product development as a series of decisions or forks in the road. Prototypes and experiments help you navigate these forks. The trick is to design the prototype or experiment that gives you clear guidance at each fork so that you can get past it, and on to the next one, quickly and accurately. Whereas, in the past, prototyping technology was generally too expensive to make a prototype at every fork, today there are affordable technologies that enable developers to do just this. The figure illustrates the difference between making a few elegant, expensive prototypes versus numerous expendable ones.

Using this mode of operation, each prototype is aimed at answering only one question, and it is only good enough to answer this question. When the question is answered, you toss the prototype and move on the next one. To do this effectively, you will also have to be sensitive to building consensus and commitment as you go. If you have traveled a great distance in your journey, and an executive who hasn't been involved wants to revisit a much earlier fork in the road, you will have lost much of the advantage of this approach to prototyping.

One warning. This "do it wrong" approach is not the best method in all cases. For example, if you are designing a memory chip, the requirements can be laid out objectively at the outset, without further customer involvement, while the cost of making a mistake is very high. In such cases, it pays to get it right the first time. However, most product development projects will benefit from a more interactive approach, and cheap, quick prototypes are perfect for this.

Return to Newsletters | Return to Publications | Return to Home

Not All Teams Are Created Equal

A decade or two ago, the concept of a cross-functional team for product development was considered quite revolutionary. We have gotten used to the idea and virtually all organizations developing products today use "teams" drawn from different departments. Such teams are old hat and we have moved on to more advanced topics such as virtual teams—which seldom if ever actually meet in person—and co-development teams—which include suppliers, customers, development partners, and others from outside the organization.

In my experience, having worked with many organizations to improve product development, I believe that, as yet, few organizations are handling the basics very well, despite their claims to the contrary. They do indeed draw together—for meetings—individuals from several departments such as procurement, quality, testing, and regulatory. These meetings, which nowadays usually have a clear leader, a set and preannounced time, and an agenda circulated in advance, are more effective than they were before.

I believe that a real team is more than a group of individuals who have effective meetings. Because cross-functional interplay is the essence of product development, companies that aim higher than merely having effective meetings can develop better products faster than the competition.

Jon Katzenbach and Douglas Smith have devoted a whole book, The Discipline of Teams, to the distinction I've just drawn (this is a follow-on to their earlier book, The Wisdom of Teams; a review of The Discipline of Teams is available on another page).

They quite specifically define a team as, "A small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable." This doesn't sound too radical, but, for those who take these words seriously, its implications are profound. "Small number" means less than ten. "Common purpose and performance goals," among other things, means common work products; in product development, for example, this could mean a single product specification document rather than separate marketing requirements and engineering specifications documents. "Mutual accountability" implies that individuals on the team cannot fail individually, because all members of the team are locked into mutual purposes, goals and work products.

Consider, for instance, the area of goals and responsibilities. Most teams I have worked with want to define roles and responsibilities up front so that they know where they stand as individual contributors. If the team doesn't define its roles and responsibilities, then management will insist that it do so with sufficient clarity. But the beauty of a cross-functional team with complementary skills is that roles can shift over time to accommodate the workload and the skills available.

Katzenbach and Smith are clear in Discipline (more so than in Wisdom) that a team is not the right answer for all projects. Many projects simply do not require the mutual accountability and joint work products that are the defining characteristics of a real team for the simple reason that the extra effort needed to obtain these qualities will not pay off. In such cases, work groups can use a way of organizing their work that is far more common, and easier to institute what Katzenbach and Smith call a single-leader discipline. In the single-leader discipline, a leader is responsible for assigning members to tasks and coordinating work products. In short, this leader becomes the "glue" that binds together the various activities in cases where mutual accountability and joint work products are not required. The current interest in project management tends to be in this direction.

The single-leader discipline, being easier to institute, is popular because it is sufficient for many types of projects. However, it is the nature of product development projects that they can often benefit greatly from the more intimate interplay that a real team affords. I believe that product developers can gain an advantage by employing a more powerful form of organization than would be completely satisfactory for their compatriots on customer service "teams," sales "teams," etc.

Katzenbach and Smith tie it all together with a diagram that is in the shape of a capital Y. The lower, common arm is effective groups, which is where most companies are today: they have effective meetings that provide limited cross-functional collaboration. The left arm is the single-leader discipline, which is one possible extension of effective groups, while the right arm is the real team, which represents an alternative. You are wise to be clear about which arm you are on.

Return to Newsletters | Return to Publications | Return to Home