'When will this stop changing?'
The quality of communication between marketers and engineers is critically important and the structure established to manage communication will affect the quality, cost, and speed of interaction among all the participants in the process.
Is the question in the headline a) an engineering manager pleading with a marketing manager to stop submitting additional requirements for the new product, or b) a marketing manager begging the engineering manager for the product's truly final performance limits? Your answer probably depends on which side of this interaction you generally find yourself. Unfortunately, both are very common and both are symptoms of a new product in trouble.
We all know that communication is the key and we all think that interactions like this one are part of that communication. Maybe, but the message communicated here is not technical, it is just pure frustration. The quality of communication between marketers and engineers is critically important and the structure established to manage communication will affect the quality, cost, and speed of interaction among all the participants in the process.
In small to mid-size companies, and in larger companies in which smaller divisions operate independently, tradition and personality rather than thoughtful structure often dominate the development process. Certainly, some managers are capable of planning and executing development programs, but a company that relies on these few people for every program in every situation will experience serious bottlenecks. Preventing or alleviating these bottlenecks requires a process that defines responsibilities, sets timetables, collects information, determines compliance, resolves disputes, and decrees completion.
Product development processes
Processes like these are required as part of implementation of ISO-9000, in which product design is done, and have long been standard in companies executing large development programs. In large operations, they are often implemented with comprehensive procedures supported by complex software and extensive documentation. Managers in small operations frequently argue that the burden of implementing such processes far outweighs any potential benefit, but often this position reflects more the fear of losing control than an accurate estimate of process cost.
However, the principles of good product-development process, especially at the point of marketing/engineering interface, can be applied with minimal bureaucracy and can incorporate any safeguards a manager thinks need to be included to avoid unexpected costs. The benefits come from ensuring that all participants have their questions asked (if not always answered) at the beginning of a program, and that the unknowns, assumptions, decisions, priorities, and goals are shared.
Many examples of new-product processes are available that fit organizations of every size (see Resources). Generally, these packages include three approval steps, often called Stage Gates or Tollgates, at which the technical and marketing groups come together, supplemented by finance, production, and any other stakeholders in the program, to decide whether the program remains properly defined, currently relevant, and likely to succeed. Typically, these gates correspond to the decisions to start the program, to initiate detailed design, and to build the first pilot run of product. Each stage requires a new resource commitment by the company and usually precludes alternate programs. As such, each is a strategic decision deserving broad, careful consideration supported by convincing data, clear thought, and unanimous commitment.
The quote we started with is symptomatic of a lack of consideration at the first Gate, when the marketing and engineering teams must agree on what they can do together to make happy customers and, thus, profitable products. It is essential to have proper preparation for the meeting at which the decision is made to approve start-up of a new-product program. At this stage many companies have already failed, often by never having the meeting at all. The manager is critical at this stage, not in dictating the outcome of the meeting, but in ensuring that it is held and that important issues are raised, if not resolved.
Both engineering and marketing concerns must be raised and each group must be willing to accept that the other will not be able to provide definitive answers for everything. To facilitate this understanding, here is some advice:
For the marketeers: Define products based on real market information, not a personal vision (see "Using the internal customer," above). Rarely can a small organization succeed at market push. Recent events indicate that even big organizations can fail to know the market. The engineers can recognize this failure when they see it. Remember that engineers have both physics and suppliers to deal with. These two constraints define, for practical purposes, the design space available.
If a new level of performance requires use of a new physical principle—lasers instead of lamps, for instance—the needed design techniques and skills change, as does the supplier base. These changes increase uncertainty in engineering and must prompt reconsideration of the cost and importance of making the leap in technology and placing faith in new suppliers. Work with the engineers while writing a new-product specification to be sure that all parameters are included. Ask the engineers about their concerns: Are there specs not stated that could be significant to users? Which specs might affect reliability, or test yield, or product life? Don't change anything without a clear reason and don't assume that the program can survive all change requests.
For the engineers: Make a serious effort to apply new technology effectively without operating too near the bleeding edge. Many marketers are also engineers and can be very good at detecting both undue conservatism and excessive risk-taking. Match the degree of new design to projected product life. Understand that marketing is not a science and that technical markets are generally so narrow and so fast moving that even traditional (and very expensive) market research techniques usually produce equivocal or inconclusive results. Think flexibly when defining product architectures.
Some things are out of the control of any small organization, so methods of accommodation should be incorporated early. Get help when you need it. Even huge companies use advertising agencies, fulfillment houses, public-relations firms, and trade-show organizers to help with the marketing, so they expect everyone to use outside experts as a matter of course.
For everyone: Understand that others may already be wary of your positions. Cure this by supporting adoption of a good process and then use the process honestly. After a while, the list of questions to be considered will converge, expectations will stabilize, the quality of decisions will improve, and your programs will proceed faster, cheaper, and better.
Center for Innovation in product Development - http://web.mit.edu/cipd/
Product Development Benchmarking Association - www.pdba.org
Society of Concurrent Product Development - www.soce.org
Search the Web for "Product Development" for hundreds of links.
DAVID L. GILBLOM is president of Alternative Vision, P.O. Box 4055, Los Altos, CA 94024-1055; email@example.com
Using the internal customer
One simple tool sufficient to define a new product is the preliminary data sheet. Instead of drawing up a formal, separate internal marketing specification for use
by engineering, write a data sheet suitable for presentation to a knowledgeable customer. This has to contain all relevant technical details for everything from performance to enclosure size. In addition, like any good data sheet, it will list the selling points—features and benefits—that can demonstrate to the design team which attributes of the design carry the highest importance. Using this type of document also steers the marketers away from overspecifying details irrelevant to customers, like what kind of connectors are used inside the box. Finally, once the team accepts the final revision, it will be ready for presentation to outside customers without delay.