EISEVIER

0000

Integrating Customer Requirements into Product Designs

Antonio J. Bailetti and Paul F. Litva

Despite all best efforts, the design process often leads to the introduction of
products that do not meet customer expectations. Although the design team typ-
ically applies customer-related information from several sources, the product
design somehow fails to satisfy customer requirements. Clearly, we need to
develop a better understanding of the process by which designers in large devel-
opment organizations transform information about customer requirements into
the final design specification. To improve our understanding of this process,
Antonio J. Bailetti and Paul F. Litva examine design managers’ perspectives on
the sources of customer requirement information.
During the evolution of a product design, the design team applies information
that is endorsed by marketing and product management. Common sources of such
information include commercial specifications, inferences from existing products
and services, deployment studies, and external standards.
When this management-endorsed information is deemed inadequate, designers
supplement it by creating and sharing their own customer-related information.
This local information includes the results of benchmarking function and perfor-
mance, the designers’ perceptions of a service provider’s installed base of equip-
ment, and validations of intermediate designs. Marketing and product manage-
ment cannot easily review the local information that designers create and share
in evolving a final design.
This article highlights the importance of creating mechanisms for ensuring that
customer requirement information from various sources is internally consistent.
To meet this goal of consistency, organizations must ensure that customer re-
quirements information produced by marketing satisfies the information process-
ing requirements of the design community. In addition, the knowledge that de-
signers actually apply to produce a design must incorporate customer
requirement information endorsed by marketing and product management at all
stages of product development.

Address correspondence to Antonio I. Bailetti, Department of Systems

and Computer Engineering, Carleton University, Ottawa, Canada KIS
5BS.

J PROD INNOV MANAG 1995;12:3-15

0 1995 Elsevier Science Inc. 0737-6782195/$9.50
65.5 Avenue of the Americas, New York, NY 10010 SSDI 0737-6782(94)00021-7
 J PROD INNOV MANAG A. .I. BAILETTI AND P. F. LITVA
1995;12:3-15

I
n this article we examine the integration of cus- testing functional specifications, and transferring a
tomer requirements into the designs of complex manufacturable design to production [ 141.
industrial products by large design teams. The two Third, we conclude that there is a need for a frame-
objectives of this article are first, to provide a concep- work to suitably explain how the information that de-
tual framework for examining the integration of cus- signers produce during the design process incorporates
tomer requirements into a product design and second, the information on customer requirements that mar-
to identify the various sources of customer require- keting and product management produce. Frequently,
ment information that are used by designers. information produced by designers leads to the intro-
Firms must incorporate the needs and interests of duction of products that do not meet customer expec-
customers into the designs of their products. The lit- tations, even though they generated this information
erature on product development has focused on: (1) from the information produced by marketing and prod-
the ways to provide operational definitions of cus- uct management.
tomer requirements [1,2,7,10,13,15,20,22,25-281, Research findings indicate that one of the most se-
(2) the problems of integrating marketing and R&D rious barriers to R&D and marketing integration is the
groups [ 11,12,23,24], and (3) the interaction of design way information about customer requirements is per-
and customer concepts [4,6,17-191. ceived by R&D. Managers of R&D believe that mar-
We make three important conclusions from the re- keting provides insufficient high quality information
view of the product development literature. First, the about customer requirements [ 1 l] and does not under-
most important task for a development organization stand key issues about product development [12]. The
when both the product and its context are complex and results of marketing produced information not meeting
changing is the integration of customer requirements the information processing requirements of the design
into the details of the product design [5,6]. community are increased development intervals, fric-
Second, the study of design is underdeveloped. The tion within the firm, and higher R&D costs [3,21].
management literature has de-emphasized the study of In the next section we develop a conceptual frame-
the design process. The domain of design is seen to be work that can be used to examine the integration of
coextensive with the domain of problem solving. This customer requirements into the desired design. In sub-
drains the word design of most, if not all, meaning [9]. sequent sections we describe an exploratory research
For the most part, the literature has assumed that de- study undertaken to identify salient features of this
signers are mere recipients of information on customer domain. We provide conclusions in the last section of
requirements as provided by marketing and product the article.
management functions, and that their role is limited to
performing technical tasks such as the production of
drawings, working models, and prototype designs, Conceptual Framework
A product design is a model that specifies the means
by which the product will provide the desired func-
BIOGRAPHICAL SKETCHES
tion. A design model provides nondesigners with all
I
Anronio J. Bailetti is Associate Professor in the School of Business the necessary detailed information about the way the
and the Department of Systems and Computer Engineering. Car- product can be physically realized in terms of known
leton University, Canada. He received his M.B.A. and Ph.D. de- components, techniques, processes, and rules [ 161.
grees from the University of Cincinnati. His research focus is the
development of technology-driven opportunities, product design The design process is used to evolve a set of work
and development, and the creation and operational management of objects that contain unorganized and simple informa-
technological infrastructures. He has published recently in the tion into a different set of work objects that contain
Journal of Product Innovation Management, R&D Management,
complex and well organized information. We concep-
and IEEE Transactions on Engineering Management.
tualize the design process as a series of information-
Paul F. L&a is Manager, Strategic Planning in the Data Commu- producing cycles carried out by designers to increase
nications Products Grow at Northern Telecom. He holds a B.Sc. the level of detail in the design model to the point
in Engineering Physics from Queen’s University in Canada and a where it can be implemented and replicated by non-
M.S. in Management from the MIT Sloan School of Management.
His research interests include new product and new business de- designers. Considerations of performance and realiz-
velopment in technology-based firms. ability with high degrees of confidence are integral to
the design process [ 81.
INTEGRATING REQUIREMENTS INTO PRODUCT DESIGNS J PROD INNOV MANAG 5
1995;12:3-15

Eiements of the Design Cycle in the problem domain are enclosed in the squares with
the sharp edges. For example, the designer can be
Figure 1 shows our representation of a basic design described in terms of age, education salary, experi-
cycle, the building block of the design process. The ence, and so on. The designer is responsible for ap-
six elements of a basic design cycle are: (1) the de- plying knowledge to derive Design Model,, i from
signer; (2) the customer requirement information en- Design Model,.
dorsed by marketing and product management; (3) the Conceptualizing the basic design cycle as shown in
crjstomer requirement information produced and used Figure 1 enables a concise description of how cus-
lalcally by the designer’s work group; (4) a design tomer requirement information is integrated into the
model that is an input to the cycle (Design Model,); (5) design of the desired product. During the design cycle,
a idesign model that is the output from the cycle (De- the designer (1) transforms customer requirement in-
sign Model, + r); and (6) a f ormal proof that establishes formation endorsed by management, customer re-
th #atDesign Model, and Design Model, + t are equiva- quirement information shared locally by designers,
le!lt. The last three elements were first identified by and the Design Model, into Design Model, + r , and (2)
[I@. establishes the equivalence between Design Model,
In Figure 1, the key attributes that describe each and Design Model, + r.
element are enclosed in the rectangles with the Customer requirement information endorsed by
rc unded edges; and the responsibilities of the element management comprises the goals and intentions that

Figure 1. Basic design cycleitl.

formally included in

- Establishes formal
I DESIGNER
\
constraints for the
design cycle i+l / \
/ * Attributes of designer
such as age, education,
/‘-- derives * Constraints
, salary , experience etc. ,
f DESIGN MODEL i I - Formal system model

- Embodies output
from design cycle

0 Embodies input to
6 J PROD INNOV MANAG A. J. BAILETTI AND P. F. LITVA
1995;12:3-15

describe the desired product. It is elaborated substan- the design language statements used to manipulate the
tially in discussions with customers and is included in net-list and cell-library macros.
the official plans of the product development organi- A proof is used to establish that Design Model, and
zation. Design Model, + i are equivalent. For this purpose, the
Customer requirement information endorsed by designer uses a validation method in the mind domain,
management, however, does not provide all the re- a verification method in the formal domain, and a test
quired information to derive the design. It establishes method in the physical domain [ 161.
the constraints, at a high level of abstraction, for the
evolution from Design Model, to Design Model, + i,
Design Model Evolution
but does not determine Design Model, + i.
Frequently, in development projects characterized During the design process, the designer transforms
by high task uncertainty and high newness, design customer requirement information into informal state-
groups produce and use their own information on cus- ments about constraints expressed in a natural lan-
tomer requirements. This local information is pro- guage or pictorial information. Subsequently these are
duced because customer requirement information transformed into formal statements expressed in de-
made available to them by marketing and product sign languages. Initially, the design model comprises
management is perceived as being inadequate to sup- a set of ambiguous informal statements and contains
port the performance of design tasks. few formal statements that can be used to realize the
The main difference between customer requirement product. Gradually informal statements are detailed
information endorsed by management and customer and transformed into formal statements. The design
requirement information shared locally by designers is process ends when the designer produces a formal
that the former is readily subject to scrutiny by man- system model with all the detailed information re-
agement, whereas the latter is not. Local information, quired to realize the required product.
however, also establishes important constraints to the During the design process, designers make many
evolution of the design model. trade-offs that are not visible to marketing and product
The design model represents the transformation of managers. For example, a customer requirement for
customer requirement information to a specification “compactness” is transformed into various statements
from which the product can be derived. Following in natural languages and pictorial information. These,
[ 161, we conceptualize the design model comprising in turn, are transformed into hundreds of formal state-
two sets of statements. First, there is the set of state- ments in design languages. During this transformation
ments about the relevant properties of the desired process, designers highlight certain aspects associated
product (functionality, behavior, performance, struc- with this specific customer requirement and de-
ture, cost, maintenance) expressed in natural lan- emphasize others.
guages and pictorial information. These statements de- Figure 2 shows two ways to derive the customer-
scribe the constraints of the design and evolve during related knowledge (K) that the designer uses to evolve
the design process. For instance, the statement that the the design model. Figure 2a illustrates the instance
“system shall have a maximum dissipation of 3 where K is derived solely from customer requirement
Watts” can evolve to the statement “given x and y, information endorsed by management (K,,). K,, com-
set z to be the minimum of x and y. ” prises statements defining customer requirements that
The second set of statements consists of formal have been agreed to by managers of marketing, design
statements expressed in design languages that enable and product management personnel. In Figure 2b, K is
computer support for symbolic reasoning, simulation, derived from evolving K,, using the local information
and analysis (mathematics, programming languages, about customer requirements created by design
layout description languages) and allow for unequiv- groups, (K*).
ocal communication between designers. For instance, The problems that arise when K,, does not accu-
the following is a statement expressed in a design rately incorporate customer requirements are well un-
language known as Calculus of Communicating Sys- derstood in the literature on product development. Se-
tems: m = {T}if x > y - > z: = x fi {R:z 3 x /“/Z rious problems also arise when K, K,,, and K* are not
3 y>. Now consider the case of an integrated circuit. internally consistent with each other. Details of the
The integrated circuit can only be manufactured from design may end up reflecting K* more than K,, in high
IhrEGRATING REQUIREMENTS INTO PRODUCT DESIGNS .I PROD INNOV MANAG I
1995;12:3-15

Kc, Kcr
Mi
K*
i Mi 1
Y-
K K

:-
i
Mi+l
Mi+l

2(a) 2(b)
K,, is used to evolve design model K* and K,,are used to evolve
design model

KP customer requirement information endorsed by management in the development organization

K* -- customer requirement information produced and used locally

K = customer-related knowledge applied by designer to evolve design model

Fi:;ure 2. How the customer-related knowledge applied by designers to evolve the design model is derived.

uncertainty projects. Given that the knowledge actu- organization?), and (2) the kinds of local information
al ,y applied by the designer to evolve the design model about customers that designers create to evolve the
is not readily visible to marketing and product man- design model (what are the types of K*?).
agement, it is difficult to ascertain whether K,, is con-
sistent with K or whether K,, deviates significantly Sample
frcam K as a result of K* .
The unit of analysis was a large project leading to the
There is a need to better understand how to make K,
development of complex telecommunication systems.
K,,, and K* consistent with each other during the de-
Five development projects undertaken by a large
si;:;n process. Key to this understanding is the identi-
worldwide supplier of telecommunications equipment
fication of the various sources of customer require-
were selected for the study. The projects in the sample
mznt information used by designers and the types of
provided a reasonable cross-section of the types of
1o::al knowledge design groups create to supplement
projects undertaken by the equipment supplier. Each
th:: information provided by these sources.
project was design intensive, had a duration of over
two years, involved more than 100 designers, and
Exploratory Research Study sought to develop innovative telecommunications
The purpose of this exploratory research study was to products. For each project in the sample, Table 1
structure our understanding of the domain where the shows the number of senior design managers who pro-
dclminant task is the integration of customer require- vided information, the number of designers involved
m,:nts into detailed designs of complex industrial in the project, the target market for the product, prod-
products. The study examined design managers’ per- uct description, and the new technology incorporated
spectives on: (1) the sources of customer requirement in the product.
information endorsed by management (where do de-
signers in large development teams obtain the K,, that Development Projects
has been scrutinized by marketing and product man- Advanced Network (ATN). The ATN project was
agers and included in the plans of the development based on a concept first proposed by a service-
 .I PROD INNOV MANAG A. J. BAILETTI AND P. F. LITVA
1995;12:3-15

Table 1. Project Description and Number of Managers Interviewed

Number of
Designers Target Market
in Project Description Product Description New Technology

Advanced network 200 Service-providers in Infrastructure to Limited use of new

(3 respondents) North America, Europe promote rapid hardware technology
and Australia deployment and
development of new
services for end-users
Fiber network 1500 Service-providers in Replacement products Extensive use of
(3 respondents) North America for existing network “leading edge”
infrastructure hardware technologies
significant enhancement
and extension of
existing network
infrastructure
Custom gateway 100 Single North American Interface between Limited introduction of
(3 respondents) service-provider vendor product and new technology
service provider
computing platforms to
provide service
differentiation
Personal 200 North American End-user handset and New hardware and
communications service-providers service provider signal processing
(5 respondents) network products to technology
extend the capabilities
of voice telephony
Key telephone system 200 Small businesses and Improved version of a Use of new digital
(3 respondents) divisions within large well-established product integrated circuit
corporations technology

provider to promote rapid development and deploy- ing three products. The three products were based on
ment of new services in service-provider networks a standard that was being developed in parallel. The
and reduce the maintenance costs for existing services. standard was to promote a multivendor environment in
The high-level concepts for the product had been fiber-optic network equipment, a service-independent
adopted by standards bodies, manufacturers, and ser- network infrastructure, and to provide new network
vice providers around the world. capabilities that were not supported by the existing
A product that had already been deployed in service infrastructure.
provider networks supplied designers some informa- The FWD was one of the largest development pro-
tion on service provider expectations for the ATN jects ever undertaken by the company. A radical ar-
product. However, designers did not have access to chitectural innovation guided development efforts.
knowledge of the specific services that service provid- High level concepts for the products were derived
ers intended to provide end-users. Service-providers from dozens of deployment studies. In these studies,
did not wish to reveal this information because it could the systems engineering group of the equipment sup-
be used by potential competitors to implement similar plier worked with service providers’ network planners
services. In the absence of direct knowledge of the to understand the types of traffic their networks carry
end-user requirements, designers generated ideas of and the manner in which they intended to evolve their
the types of existing services that would be deployed networks to accommodate new services and increased
in the ATN equipment. traffic.
Fiber Network (FWD). The FWD project involved Custom Gateway (MCD). The MCD project en-
the development of a complete product line compris- tailed the development of a custom software product
IKTEGRATING REQUIREMENTS INTO PRODUCT DESIGNS I PROD INNOV MANAG 9
1995:12:3-15

for a single service provider in a highly competitive ican market and then subsequently introduced to over
market segment. The custom software was developed fifty countries. A single platform was configured for
to extend the functionality of an existing platform in sale in various markets through software that is down-
the service provider network. Although the custom loaded to the platform at the factory.
scftware facilitated the development of new features The NST product replaced analogue technology
ar d services, it did not in itself deliver new services with digital technology. The design team had a good
ar d features to the end-users. understanding of the capability of the new digital tech-
The MCD product comprises a stream of individual nology prior to the start of the product design. Many
scftware features developed by a design team dedi- of the customer requirements for the product were well
ca ted to the development of custom software for the understood by the team, because the product was a
service provider. The custom development agreement replacement product. A major concern of the design
h2 d been in place for over a decade and had resulted in team was not only satisfying the requirements of end-
several million lines of code being developed. The users of the product but also satisfying the distribution
se;-v:ice-provider’s staff conceived the new services channels’ requirements for the product. Simplicity for
ar d features that would be offered to end-users. Typ- the end-user, distributor, and manufacturer was the
ic,4y, the service-provider specified a requirement concept that guided much of the development for the
fol: more custom features than the dedicated team NST product. Guided by this concept, the design team
cculd support. Development activities were then ne- developed a computer simulation of the end-user in-
gotiated as the service-provider set its priorities and terface to the product that was tested extensively with
:: design managers tried to maximize the number of end-users. The user’s ability to access features was
high priority items that could be developed given the observed using the simulator and new ways to config-
si::e of the design team. The functionality required was ure the end-user interface were determined. The sim-
specified in detail in documents that were created ulations were significant in that the design team
jo ntly by the service-provider’s staff and the equip- learned what simplicity actually meant to the end-user
mmt supplier. The platform simulator was updated and incorporated this learning into the design details of
ccntinuously to reflect changes to the interface with the product.
th’ : service-provider’s equipment. The development
te;m received continuous feedback from the service-
provider in the form of customer satisfaction reports. Data Collection and Analysis
Personal Communications (PCD). The PCD proj-
eci. entailed the development of products both for the Semistructured interviews with senior design manag-
service-provider networks and private networks that ers provided the data used in this study. The inter-
were intended to deliver a fundamentally new service views were conducted with twelve senior design man-
to end-users. The service was to be accessed by end- agers who were directly responsible for ensuring that
users through the use of specially designed handsets design specifications incorporated customer require-
thiit were also a part of the PCD development project. ments. Some of the senior managers had direct expe-
PCD products were being developed for a highly rience with more than one project in the sample. Two
un’certain and immature market. Many of the service- of them had experience with all five projects. Inter-
pr Jviders, corporate customers, and end-users that views lasted between one and three hours. The data
comprised the target markets for the PCD products did were collected over a five-week period.
not have experience with other similar products or The two senior managers who were directly familiar
se-vices. The development project was large and with all projects in the sample were asked to rank
based on a new and evolving technology. There were order the five projects in terms of their complexity in
many competing product concepts in the marketplace. integrating customer requirement information into de-
Key Telephone System (NST). The NST project sign specifications.
focused on introducing a customer premise equipment The data for this study comprised seventeen re-
product for the small business market. It targeted sponses provided by twelve senior design managers to
small businesses, franchises, branch offices, and de- six questions and the ranking of the five projects in
partments within large organizations. This is an ex- terms of project complexity. Data were examined in
tremely competitive and price-sensitive market. The three steps.
product was originally developed for the North Amer- In the first step, for each project, specific instances
10 J PROD INNOV MANAG A. J. BAILETTI AND P. F. LITVA
1995;12:3-15

of organizational processes during which customer re- of-requirements that were identified in some but not in
quirement information was created and disseminated all projects were tabulated by project. Projects were
within the design community were identified from the ranked in terms of their complexity in integrating cus-
responses by the design managers to four questions. tomer requirements into design specifications for the
Each instance was identified by the mechanism the purpose of this tabulation.
development organization used to anchor the informa- The inputs to the third step were the ranking of the
tion creation process (a trial, study, prototype) and five projects on the basis of their complexity in inte-
was referred to as a source-of-requirements instance. grating customer requirements into design specifica-
Source-of-requirements instances with similar charac- tions and the set of source-of-requirements instances.
teristics were grouped into classes across the five pro- The output from the third step was a table showing
jects. the relationship between instances of sources of infor-
The inputs to the first step were seventeen responses mation and project complexity.
provided by twelve senior design managers to the fol-
lowing questions: (1) how were the definitions of cus-
tomer requirements that were included in the develop- Results
ment plan created and made available to designers?
(2) what was the organizational effort used to match Sources of Customer Requirement Information
the details of product design to the expectations of
target customers? (3) what were the critical infor- Analysis of the replies from the design managers iden-
mation assets used to match design details with cus- tified thirty-three instances of processes during which
tomer requirements? (4) what were the information customer requirement information had been created by
sources of the concepts that guided the development the development organization and made available to
effort? the design community. The thirty-three instances were
The outputs from the first step were: (1) a set grouped into nine classes. Table 2 shows the nine
of source-of-requirements instances where each in- classes of source-of-requirements identified in the
stance anchored the creation of customer requirement analysis, their definitions, and the projects where their
information; (2) a set of classes of source-of- instances were observed. Table 2 shows that designers
requirements where each class described a group of used from five to nine different sources of customer
instances with similar properties; and (3) definitions requirement information in each project.
for these classes. Each instance in Table 2 is differentiated according
In the second step, for each project, the types of to whether the process it anchored was used to identify
local information about customer requirements that service-provider or end-user requirements. For exam-
designers created in order to detail designs were iden- ple, trial with customers is a class used to define all
tified from content analysis of the responses to two instances whereby trials with customers led to the cre-
questions. The types that were common for all projects ation of customer requirement information. Table 2
were identified. Each type was defined using state- shows that three instances for this class were identi-
ments made by the design managers. fied, two of them were trials with end users (ATN and
The inputs to the second step were seventeen re- PCD projects) and one was a trial with service-
sponses provided by the same twelve seniors design providers (PCD project).
managers to the following questions: (5) what infor- Table 2 shows that instances of four classes (com-
mation about customers did designers create within mercial specifications, inferences from existing prod-
their work groups to detail design specifications? and ucts and services, deployment studies, and externally
(6) what local information did designers in the project set standards) were identified in all projects. Instances
use to match customer expectations with product de- of the other five classes were identified in some but
tails? not in all projects. Commercial specifications and in-
The outputs from the second step were: (1) a set of ferences from existing products and services were
types of local information that designers applied to used to define both end-user and service-provider re-
detail designs in each of the five projects and (2) def- quirements. Deployment studies and externally set
initions for these types. standards were solely used to define service provider
In the third step, instances of the classes of source- requirements.
IrEGRATING REQUIREMENTS INTO PRODUCT DESIGNS J PROD INNOV MANAG 11
1995;12:3-15

Table 2. Sources of Customer Requirement Information IJsed by Designers in the Five Projects
Projects Where
Source-of-Requirements
Instances Were Observed
Source of Customer
Requirement Information Definition ATN FWD MCD NST PCD
-
Cc mmercial specification Accumulated text description of product concept s s S E, S E, S
and high-level functionality
Inl‘2rences from existing Accumulated inferences about requirements for E, S E, S S E E, S
prc: ducts and services new products and services generated from
examining existing products
Shared product Accumulated text that describes agreement between S
requirements document equipment supplier and service-provider regarding
functionality, requirements, and design work plan
Tr al with customers Accumulated direct experience from extensive E E, S
customer use of an intermediate implementation of
a design
Prototype Accumulated direct experience from using a E E
physical model that embodies key concepts of a
product to be developed at a later stage
Simuation of Accumulated experience from exposing customers E
en&user/product interface to a computer simulation of the interface between
the end-user and the product
De Tloyment study Accumulated text that describes how a new product S S S S S
can be deployed within the technical infrastructure
of the customer
Exieraally set standard Accumulated text that defines characteristics of a S S S S S
standard such as function, performance, and all
relevant technical parameters
Pirtform simulator Computing platform used to emulate the interface S
between the product and the network of the
service-provider to accumulate experience from
customer use
Number of sources used 6 5 6 7 9
Number of instances identified in the five projects: 33
-.
An E and a S are used to indicate whether the instance identified anchored a process during which definitions of customer requirements that were created
ant’ made available to designers pertained to end-users or service-providers.

Types of Customer Requirement Information heterogeneity in customer requirements, and (5) per-
Created Locally ceptions of the level of abstraction of the definitions of
customer requirements provided by the development
Content analysis of the responses from the senior de- organization.
sign managers indicated that there were five types of A result of benchmarking function and performance
local information on customer requirements that were is information about parameters of the critical success
created by design groups and used to evolve the design factors that designers perceive must be exceeded. The
in each of the five projects. The five types of local results suggest that designers determine the factors
information identified were: (1) results of benchmark- that are critical to the design and then compare their
ing function and performance, (2) perceptions of ser- designs on those factors to those of current or potential
vice provider’s installed base of equipment, (3) vali- competitors. The goal is to exceed the best competi-
dation of intermediate designs, (4) perception of tion in the critical success factors.
12 J PROD INNOV MANAG A. J. BAILETTI AND P. F. LITVA
1995;12:3-15

Perception of service-provider’s installed based of information that designers use, and (2) the types of
equipment is information about the technical infra- local information on customer requirements that de-
structure of telephone companies and interconnect car- signers create in order to evolve the design model.
riers . Examination of responses from twelve senior design
Requirements of a diverse set of customers were not managers led to the following main findings: (1) de-
always homogeneous. Heterogeneity in customer re- signers acquired customer requirement information
quirements refers to information used to differentiate from nine sources endorsed by management, four of
customers according to the extent to which their re- which were used in all projects; (2) in each project,
quirements were similar. Example, the set of require- designers used from five to nine different sources of
ments for a single service-provider was differentiated customer requirement information endorsed by man-
from the set of requirements that referred to many agement as well as created five types of local infor-
service-providers with heterogeneous requirements. mation to supplement it; (3) the sources of customer
Perceptions of the level of abstraction of the defi- requirement information were of two types, those that
nitions of customer requirements provided by the de- required the implementation of an intermediate design
velopment organization is knowledge of the layers de- to capture definitions of customer requirements and
signers use to organize customer requirements. This those that did not; and (4) intermediate implementa-
attribute can take values such as high, medium, and tions of designs were used to provide definitions of
detailed level of abstraction. customer requirements in ways that varied noticeably
from project to project.
Sources of Definitions of Customer Requirements Figure 3 shows the nine sources of definitions of
and Prqject Complexity customer requirements and the five types of local in-
formation about customers that were identified in the
Table 3 shows instances of the five classes that were study.
not identified in all projects as a function of the rank-
Commercial specifications, inferences from exist-
ing of projects according to their complexity in inte-
ing products and services, deployment studies, and
grating customer requirements into design specifica-
externally set standards provided customer require-
tions. It is apparent from this table that instances of the ment information in all projects in the sample. They
class trial with customers were used solely when a can be thought of as the common set of formal sources
project’s complexity was perceived to be high. More- of definitions of customer requirements used by de-
over, instances of the classes, shared product require-
signers in all complex development projects.
ments document and platform simulator, were used
The knowledge that designers apply to evolve the
when the project’s complexity was perceived to be design model is derived from formal sources as well as
relatively low. information created locally. Designers acquire infor-
mation about definitions of customer requirements
Discussion of Results of Exploratory from multiple sources, not just one. When this infor-
Research Study mation is deemed to be inadequate, design groups cre-
The exploratory study examined design managers per- ate local information about customers locally. This
spectives on: (1) the sources of customer requirement local information is shared by designers but is not
subject easily to examination by marketing and prod-
Table 3. Classes That Were Not Used in All Projects uct managers.
and Project Complexity Table 4 suggests a possible association between the
type of information that design groups create locally
Complexity in Integrating Customer Requirements into
Design Specifications and the formal information it is intended to supple-
ment. We postulate that design groups create informa-
Least Most tion through benchmarking function and performance
Complex Complex to supplement information provided in organizational
MCD FWD NST PCD ATN documents that describe inferences about existing
l Shared 0 Prototype 0 Trials l Trials products and services. Likewise, perceptions of het-
documents l Simulation 0 Prototype erogeneity in customer requirements are created to
0 Platform
mediate information describing commercial specifica-
simulator
tions and shared product requirements. Perceptions of
 \
INTEGRATING REQUIREMENTS INTO PRODUCT DESIGNS J PROD INNOV MANAG 13
1995;12:3-15

Specification
Inferences from Existing Products
Deployment Studies
External Standards
Shared Documents
Trials
Prototypes
Simulation
Mi \ Platform Simulator /

r .
Y--K*- Results of Benchmarking Function and
Performance
Perceptions of Service Provider’s Installed
Base of Equipment
Validation of Intermediate Designs
Perceptions of Heterogeneity in Customer
Requirements
Perceptions of Level of Abstraction of Kcr
Mi+l \

Figure 3. Sourcesof customerrequirement information usedby designersto evolve designmodel.

service-provider’s installed base of equipment medi- Table 4. Association Between the Type of Information
ate information in deployment studies and the imple- That Design Groups Create Locally and the Customer
mentation of externally set standards. Validations of Requirement Information Endorsed by Management
They Are Intended to Supplement
int;-rmediate designs seem to be used to detail the
information about definitions of customer require- Type of Local Information Sources of Customer
ments acquired through trials with customers, simula- Customers Created by Requirement Information
Work Groups Endorsed by Management
tions, prototypes, and platform simulators.
‘We also postulate that a design group’s perceptions 0 Results of benchmarking l Inferences from existing
of the level of abstraction of the definitions of cus- function and performance products and services
tomer requirements provided by formal sources deter-
l Immediate managers’ l Commercial specification
mine the amount of effort that is devoted to create commitments l Shared product
local information as well as the type of local informa- 0 Perceptions of requirements document
tion that should be created by the design group. heterogeneity in customer
-2our sources of customer information required that requirements
an intermediate design be implemented in order to 0 Perceptions of service l Deployment study
capture definitions of customer requirements. These provider’s installed base of l Externally set standard
we’re: trial with customers, simulation of end-user/ equipment
product interface, prototype, and platform simulator. l Validation of intermediate l Trial with customers
Hi;;her levels of designer effort were associated with designs l Simulation of
instances that required the use of an intermediate im- end-user/product interface
plementation of a design to create knowledge about l Prototype
l Platform simulator
customer requirements. These instances required de-
sign and implementation effort in order to elicit greater l Perceptions of the level of
abstraction of customer
knowledge of customer requirements.
requirements provided by
Why do projects use certain intermediate designs to development organization
develop definitions of customer requirements and not
14 J PROD INNOV MANAG A. J. BAILETTI AND P. F. LITVA
1995:12:3-15

others? The results suggest that trials were used in the Product development organizations in general, and
more complex projects. The two projects that ranked marketing and product management personnel in par-
highest in terms of complexity, ATN and PCD, used ticular, must ensure that the formal definitions of cus-
trials to learn and develop definitions of customer re- tomer requirements, the information about customers
quirements. Trials defined a problem space for joint created by design groups locally, and the customer
problem solving that led to the provision of richer def- related knowledge actually applied by designers to
initions of customer requirements than those available evolve the design are internally consistent. Otherwise,
from other sources. Learning came about as a result of there is a risk that the output of the design process will
extensive experimentation and joint problem solving not be entirely congruent with the definitions of cus-
that involved designers and customers. tomer requirements that had been scrutinized by man-
Platform simulator and shared product requirement agement .
documents were used to provide definitions of service- There must be recognition that designers frequently
provider requirements in the project that was ranked as need to create local information about customers in
the least complex of the five in the sample. A platform high uncertainty projects. The formal information
simulator is a computing platform that enables the which satisfies the needs of marketing and product
equipment supplier to continuously emulate, at a very management functions may not be sufficient to satisfy
detailed level, the environment of a service-provider. the needs of the design community. Local information
Thus, it provides information for a broad range of is created because designers perceive the formal
technical dimensions at a very low level of abstrac- knowledge of customer requirements as being inade-
tion. What if scenarios can be readily simulated by the quate. Once created, local information becomes an
equipment supplier and the detailed simulation results indispensable component of the design environment.
discussed with the customer. These simulators do not It is recommended that firms survey the sources of
address end-user requirements directly. customer requirement information that designers use
Two projects used simulations and prototypes solely and the types of local knowledge that designers create
to incorporate end-user requirements into designs. The to evolve their design models so that plans can be
interviews indicated that the quality of the information developed to ensure their external and internal consis-
generated through simulations and prototypes varied tency .
directly with the experience end-users had with con-
cepts similar to those embodied in the new product.
References
1. Akao, Y. Quality Function Deployment: Integrating Customer Re-
Conclusions quirements into Product Design. Boston, MA: Productivity Press,
1990.
In this article we argue that there is a need for a better 2. Bailetti, A. J. and Guild, P. Designers’ impressions of direct contact
understanding of the process that designers in large between product designers and champions of innovation. Journal of
Product Innovation Management 8(2):91-103 (June 1991).
development organizations use to incorporate cus-
3. Burgelman, R. A. and Sayles, L. R. Inside Corporate Innovation.
tomer requirements into the desired product design. In New York: The Free Press, 1986.
Figure 1 we propose a model of the basic design cy- 4. Clark, K. B. The interaction of design hierarchies and market con-
cle-the cornerstone of the design process. It can be cepts in technological evolution. Research Policy 14:235-251 (1985).
used to facilitate communication about how a designer 5. Clark, K. B., Chew, B. and Fujimoto, T. Product development in the
world auto industry. Brookings Papers on Economic Activity 3:129-
incorporates customer requirement information into 771 (1987).
design specifications and to structure our understand- 6. Clark, K. B. and Fujimoto, T. Product Development Performance.
ing of the design environment for reuse from project to Boston, MA: Harvard Business School Press, 1991.
project. The model can be refined to account for many I. Crawford, C. M. Protocol: new tool for product innovation. Journal
real world situations. of Product Innovation Management 2:85-91 (1984).

Designers apply customer related knowledge to 8. Eastman, C. M. Recent developments in representation in the science
of design. In: Proceedings of the Eighteenth Association for Comput-
evolve a system level design model. Figure 2 illus- ing Machinery and Institute of Electronics and Electrical Engineers
trates that designers in large development organiza- Design Automation Conference. Washington, DC: Institute for Elec-
tronics and Electrical Engineers, 1981, pp. 13-21.
tions acquire customer-related knowledge from multi-
9. Goel, V. and Pirolli, P. Design within information processing theory:
ple sources of customer requirement information. the design problem space. Al Magazine 19-36 (Spring 1989).
They also use local information created locally within 10. Griffen, A. and Hauser, J. R. The voice of the customer. Working
design groups. Paper 91-2, MIT Sloan School of Management, Boston, 1991.
INTEGRATING REQUIREMENTS INTO PRODUCT DESIGNS J PROD INNOV MANAG 15
1995;12:3-15

11. Gupta, A. K., Raj, S. P. and Wilemon, D. The R&D-Marketing In- 19. More, R. A. Developer/Adopter relationships in new industrial prod-
terface in High-Technology Firms. Journal of Product Innovation uct situations. Journal qf Business Research 14:501-517 (1986).
Management 2112-24 (1985). 20. Pugh, S. Total Design. Reading, MA: Addison-Wesley, 1990.
12 Gupta, A. K. and Wilemon, D. Improving marketing relations: 21. Rubenstein, A. H. Managing Technology in the Decentralized Firm.
R&D’s perspective. R&D Managemenf 20(4):277-290 (1990). New York: John Wiley & Sons, 1987.
13. Hauser, J. R. and Clausing, D. The house of quality. Harvard Busi- 22. Smith, P. G. and Reinertsen, D. G. Developing Products in Half the
RUSS Review 66:63-73 (May-June 1988). Time. New York: Van Nostrand Reinhold, 1991.
14. Hise, R. T., O’Neal. L., McNeal, J. U. and Parasuraman, A. The 23. Souder, W. E. Managing relations between R&D and marketing in
effect of product design activities on commercial success levels of new new product development projects. Journal of Producf Innovation
industrial products. Journal of Product Innovafion Management 6( 1): Management 5:&i9 (1988).
43-50 (March 1989). 24. Souder, W. E. and Chakrabarti. A. K. The R&D/Marketing interface:
15 King, B. Better Designs in Half the Time: Implementing Quality results from an empirical study of innovation projects. IEEE Truns-
Function Deployment in America. Methuen, MA: GOAL/QPC, 1989. actions on Engineering Management EM-25, 4:88-93 (1978).
16 Koomen, C. J. The Design of Communicating Systems. Boston, MA: 25. Urban, G. L. and von Hippel, E. Lead user analyses for the devel-
Kluwer Academic Publishers, 1991. opment of new industrial products. Management Science 34:569-582
17 Leonard-Barton, D. Implementing new production technologies: ex- (May 1988).
ercises in corporate learning. In: Managing Complexity in High Tech- 26. von Hippel, E. The Sources ofInnovation. New York: Oxford Uni-
nology Qrganizarions, M. A. Von Glinow and S. A. Mohrman versity Press, 1988.
(eds.). New York: Oxford University Press. 1990, pp. 16@187. 27. von Hippel, E. Lead users: a source of novel product concepts. Man-
18 Meyers, P. W. and Athaide, G. A. Strategic mutual learning between agement Science 32:791-805 (July 1986).
producing and buying firms during product innovation. Journal of 28. Wilson, D. T. and Ghingold, M. Linking R&D to market needs.
Product Innovation Management 8:155-169 (1991). Industrial Marketing Management 16:207-214 (1987).