seeding creativity

Ways to Quicken Your Product Cycle

An interview with Design News, Feb 24, 1992, pp. 74-77, Copyright Design News

Conducted by Lawrence D. Maloney, Chief Editor

Design News: How important are shorter product cycles to manufacturing success?

Preston Smith: It’s one of the major thrusts of this decade because the sales lives of products are getting shorter and shorter. If the development cycle doesn’t become shorter as well, then too much a product’s life will be consumed in the development stage—and valuable sales opportunities will be lost.

Q: To what extent have U.S. companies embraced this goal?

A: There are many good examples. Xerox reports that it has cut in half the resources and time required to develop comparable products. Honeywell has slashed development time by 50 to 60%, while trimming labor hours 5 to 10%. Deere & Co. has shrunk its seven-year development cycle by 60%, while reducing development cost 30%. Some others that have made good progress include: Buick, Hewlett-Packard, Apple, Warner Electric, and Motorola. The toy industry also has a reputation for being fast to market.

What I see in too many firms, however, is that there are pockets of excellence. A particular group or team will go all out and get one product to market quickly, but the company as a whole has not made the commitment to shorter product cycles.

Q: How do delays in product development hurt profitability?

A: A number of things happen. If you’re six months late, you obviously lose six months of sales. But, in fact, you lose more than that because you delay the whole sales ramp-up—the tendency for sales to build up gradually after a new product is introduced. So you really lose six months of sales from the peak sales period. On top of that, you lose market share because the first company to market has had first crack at establishing accounts and becomes known as the leader. In many cases, too, there may be related products or services that are tied to the product you are introducing—and their sales will be hurt as well.

Also, when you’re first, you get down the learning curve sooner on manufacturing, so you can begin to cut production costs, making for a more profitable operation.

Q: Yet you mention in your book that not every product needs a fast track. How do you decide?

A: Management first must make a thorough financial analysis of a planned product to see if it merits the extra resources often needed to bring a product to market faster. First of all, is it a product in which time to market is absolutely critical? If it is, then what are the product’s essential specifications? Does it have to give the very finest, flawless performance? Does it have to offer a long list of features? If you are developing an entry-level product, you should employ a different development process than you would use for a top-of-the-line item. And, of course, the competitive situation always affects your decision. Time is going to be much more important if your competitor is working on a similar product.

Q: What are the chief culprits that delay product introductions?

A: One very simple one is that things tend to sit around a lot. Whether it be a drawing waiting for approval, or paperwork requesting a prototype build, key items in a product’s development spend far too much time sitting on someone’s desk. A product in development spends 95% of its time waiting in line. So clearly, you must analyze where these bottlenecks occur—and reduce or get rid of them.

Another big thing that takes a lot of time is decision making. I can’t emphasize enough that decisions really need to be made at the lowest level so that product development can proceed in an orderly fashion. But what happens far too often is that decisions get passed up to bosses or middle managers who spend much of their time in meetings or on the road. And that delays everything. I recently did an analysis for a company where top management makes a lot of decisions even on design issues. I found that, on average, the top management team was only in the office one out of every 17 working days!

Q: How about the “fuzzy front end” you cite in your book?

A: What we find on many projects is that a product will spend about half of its development time in what I call the “fuzzy front end” before the organization really gets serious and assigns engineers to work on the project on a dedicated basis. To find out whether your company suffers from this problem, pick a project from the past and analyze when the need for the product was first identified in the marketplace—then look at how long it took your company to really start work on it. Often, the time lag is many months—or even years.

Q: How can design engineers expedite this process?

A: By all means, they should get involved. But in too many companies, management puts engineers in a box and says: I’ll pass on to you the requirements for this product—and you go out and design it. That’s wrong. Engineers really need to be in contact with a product’s ultimate users before and during development. It is extremely difficult to design a successful product without this contact. But the way it is now, the only time many design engineers meet customers is in a fire fighting mode—that is, when they are called into the field because a product isn’t working properly.

Q: So establishing a product’s key specifications must be a joint decision, the result of concurrent engineering?

A: That’s absolutely true, but is easier said than done in many companies. Product specifications are really the road map for the whole development effort. If the road map turns out to be vague or confusing, it’s going to be pretty hard to find your way. When you look at the specifications, it really involves a lot of fundamental design decisions. What are we going to make this product out of—metal or plastics? Will it be electromechanical or microprocessor controlled? These are not purely technical issues, nor are they purely marketing or manufacturing issues. They involve a bit of each. That’s why it’s vital for all of those functions to participate equally in setting specifications.

Q: Do companies also delay their development cycles because they want to introduce “perfect” products?

A: Yes. It’s a lofty objective to develop a product that fulfills all possible requirements. But when you do that, you usually add too much complexity, which will increase your design effort. It is much better to introduce a simpler product, then add complexity in future versions of that product line based on what the customer tells you. This incremental approach to product development is much more effective than trying to predict all the features that customers will eventually want.

Japanese companies in particular have enjoyed much success by following a policy that freezes a design as early as possible, gets the product to market fast, then adds new features in subsequent versions of the product. One of the best examples is Casio, with its huge line of wrist watches. There are countless variations of the product, but all keep time plus or minus 15 seconds per month. And every one of them is water resistant to 50 meters. The basic functions of a wrist watch are always fulfilled, but they keep changing the other features, depending on customer preferences.

Q: But aren’t companies adding to their delays by taking on too many projects?

A: It depends on how they approach these projects. It is better to develop products sequentially, rather than simultaneously. For example, if you find that your company’s resources will allow you to handle three new projects at a time, stick to that—even though you may need to develop nine. Introduce the first three, then go back and tackle three more, and then the final three. This sequential approach in the end will enable you to get all your nine products to market faster. It also gives you more flexibility to respond to market conditions and change your product plans because you have not over-committed yourself.

Q: How do you go about forming a development team that will bring a product to market fast?

A: The most important requirement is to pick the right leader, and he or she can have either an engineering or a marketing background, as long as this person understands that the project is a business proposition—not a technical or marketing exercise. Then, beware not to build a team that is loaded with specialists or bit players who come in for a couple of weeks and leave, which ruins a project’s continuity. Instead, it is better to have broader-based people who are capable of doing a lot of things and who will stick with the project.

Q: Is co-location essential to speedy product development?

A: Absolutely. MIT’s Sloan School of Management once did a study that showed that if technical people were separated from each other beyond easy conversational distance, key technical issues don’t get raised. Oftentimes, important issues get dropped if you have to pick up the phone or get out of your seat. E-Mail and video conferences can help, but there’s nothing like personal contact.

Q: How about the skunkworks concept? Isn’t it becoming more popular as a way to speed development time?

A: The idea of locating a team offsite should be the decision of the team leader, and sometimes it makes a lot of sense. But be careful how you go about accomplishing this task. If you locate the team too far from your headquarters, you may add to your development time, because you will need to use the resources of the main office from time to time. Sometimes, it’s better to find your team a remote corner in the same building, rather than locate them off site.

Q: How valuable are modern engineering tools, such as CAD and stereolithography, in getting products to market faster?

A: Both of those tools can be a great help. CAD can accelerate the design process by five times over conventional methods. But as I said before, this time savings does you little good if requests for CAD drawings or completed drawings sit on the shelf for long periods before they are reviewed. The same goes for rapid prototypes produced through stereolithography and other processes.

Similarly, project management software can be a big plus, if you can avoid the pitfalls of getting caught up in needless updates and reports that will cut into the time you spend on design work or in communicating with other team members. The best way to use these programs is to produce a giant schedule chart, such as a Gantt or PERT Chart, and post it on the wall in a team area for all to see. This will provide a quick measure of the progress you’re making.

Q: With the steps you’ve described, do you really believe that cutting development time in half is doable?

A: Yes, because companies are doing it. But actually cutting the time in half depends on how hard you work at it, how serious you are, and where you are on the learning curve when you start. Companies must also do a thorough analysis of how key decisions are made in the development process to reduce the many delays that occur. Finally, it takes the commitment of top management, which I believe will occur more and more in the ‘90s if firms are to survive and grow.

(c) Copyright 2013 Preston G. Smith. All Rights Reserved.