Nailing Product Requirements

By Bradford L. Goldense

Companies often wonder how they can facilitate cooperation between sales, marketing, engineering, and operations to better understand customer needs and better define product requirements. This issue occurs hundreds or even thousands of time each year and may involve a large number of people. The process is expensive, but not when compared to the cost of doing it wrong. On a positive note, it is not difficult to do it well, provided a short list of values and practices are understood and agreed upon.

For the past 15 years, the management practices of leading companies have shown the most successful definition-specification processes separate the roles of sales and marketing. Sales, which manages customer relationships and coordinates communications with customers, can be a great means of identifying customer requirements. Sales should not, however, be the final authority on what enters the product pipeline. Marketing has this responsibility, with plenty of input from Sales. Management science shows that everyone with a stake should be brought into the mix.

Near and long-term horizons
While Marketing (product management) receives input from Sales, it should also solicit requirements directly from customers and conduct competitor research. Unlike Sales, Marketing has two requirement horizons: a near-term horizon for products about to enter the pipeline, and a long-term horizon for platform and product-generation planning. Events for the near-term horizon are product specific: what goes into the product(s) that will be part of the project. These occur for every product-definition effort. Events for the long-term horizon are usually annual or semiannual but executed quarterly to level the load. Establishing two distinct time horizons enables cross-functional thinking and the application of management science.

Marketing should assemble a team to gather near-term product requirements. The team should consist of marketing personnel (40%), engineering (40%), and operations (20%). Note that sales is not included in this step. These are not sales calls, and sales already has sufficient opportunity to articulate what it identifies as requirements. A salesperson should be involved with setting up these meetings but, if attending, they should act as a liaison or an observer only.

A team made up of an equal number of marketing and engineering personnel should gather long-term customer requirements. Operations is not as critical for gathering long-term requirements. As always, Sales, or Account Management, has a primary or at least equal hand in managing customer visits. Agendas for discussion should be agreed upon in advance and safeguards put in place to limit any discussion of near-term needs. The team should consist of highlevel managers. On the engineering side, only fellow engineers, senior engineers, product architects, and chief technology officers should participate. Only strategy managers, brand managers, portfolio managers, and senior product planners should make up the marketing team.

Get it right the first time
In the 1990s, Ashok Gupta published an article in California Management Review claiming that 71% of everything that goes wrong in product development can be attributed to a failure to identify requirements. Even if we reduce that figure by half, it remains a compelling statistic. Unless a company gets product requirements right, up front, all else will be based on flawed assumptions.

There are two categories of flaws. The most costly is error of omission. In statistics, this is referred to as “Type One Error.” “Type Two Error” is the implementation of wrong or incomplete requirements. To avoid these, a crossfunctional listening group must hear all that is said during requirements gathering.

Before 1990, decisions about which new product ideas to pursue involved a single-step process in which estimates of requirements bubble up from lower functional departments. A more senior committee would then meet and make a go/no-go decision. Since then, a formalized 2-step process has evolved. Companies now capture “light bulb” or new-product ideas in the initial half-step. Then comes funding a definition activity (the first full step) and reviewing results (the second and last step). This formalized process ensures a focus on requirements.

Techniques for gathering requirements
Fifteen years ago, there were no “best practices” for either near or long-term requirements gathering. Today, there are a host of near-term techniques for product definition, requirements gathering, and specification writing. The best known of these is the “Voice of the Customer” (VOC) technique. In best industry practice, the product-development core team (definition team) conducts and documents requirements.

An effective near-term VOC study provides detailed documentation of customer requirements as articulated by the customer, synthesis of customer requirements to identify the “marquee” features, a common language and set of values for the development team going forward, primary input for selecting appropriate design specifications for the new product, and a springboard for product innovation.

On the long-term side, there’s the long-standing, effective (but rarely used) “Lead User Analysis” developed by MIT’s Eric von Hippel in the 1980s. It remains the most poorly understood of requirements-related practices. Yet those companies that use it find it a powerful tool.

Lead User Analysis directs companies to seek out organizations or individuals with an immediate need for a new product months or even years before the rest of the marketplace. The company works with lead users to modify existing products or create new ones. And the lead users benefit significantly. The company then determines how the timing of the bulk of the market differs from that of lead users.

Another aspect of the productdefinition process is specialized training for those involved with product definition in the area of intellectualproperty (IP) protection. Seeking to impress customers, engineers can be far too forthcoming about their knowledge, especially in meetings with long-term horizons. What not to say can be as important as what to say. This becomes more critical as the value of IP grows.

Inner voices
Besides formal teams, a company can glean information from any function that has customer contact or is part of the development and commercialization of a product. Marketing should tap internal departments such as Engineering, Field Service, and Sales Engineering for feedback. Warranty, Repair, and Customer Service know a product’s strengths and weaknesses. And Marketing and Engineering should listen to “the street” to avoid undesirable attributes.

Functions with little direct customer contact should also be asked for their input. Operations, Purchasing, Test Engineering, Production Test, Quality, and others are experts in performance envelopes and constraints. The whole Design-for-Manufacture & Assembly body of knowledge — now called Design for “X” or “DFX” — arose because requirements were being specified by personnel in fuzzy front-end activities.

While I’m focusing on “marketpull” requirements gathering, “techpush” is becoming increasingly important. Build it and they will come. Lead User Analysis helps build confidence around tech pushes.

Self-inflicted injuries
Feature creep, the tendency for product requirements to increase during development, is a real pitfall. Engineering, Sales and sometimes Marketing tend to overspecify. Overspecifying returns little to the top line while inflating costs which, in turn, reduces the bottom line. The best way to avoid “creeping elegance” is by establishing a strong front-end requirements process. When everyone agrees upon requirements, it is easier to resist the temptation to overspecify.

As marketing guru Philip Kotler said, “Proper planning prevents poor performance.” Companies should recall the Five Ps during the fuzzy front-end activities of market-pull product definition. By eliminating a succession of physical builds, companies with strong front-end processes can reduce project-development expenses by 20 to 50%. All it takes is the patience to gather requirements and the wisdom to incorporate them.