J PROD INNOV MANAG 2005;22:303–321
r 2005 Product Development & Management Association
Interfirm Modularity and Its Implications for
Product Development
Nancy Staudenmayer, Mary Tripsas, and Christopher L. Tucci
Industries characterized by interfirm modularity, in which the component products
of different firms work together to create a system, are becoming increasingly
widespread. In such industries, the existence of a common architecture enables
consumers to mix and match the products of different firms. Industries ranging from
stereos, cameras, and bicycles to computers, printing, and wireless services are now
characterized by interfirm modularity. While the increasing presence of this context
has been documented, the implications for the product development process remain
underdeveloped. For the present study, in-depth field-based case studies of seven
firms experiencing an environment of interfirm modularity were conducted in order
to deepen understanding of this important phenomenon. What unique challenges did
this context pose and why? What solutions did firms experiment with, and which
seemed to work?
Based on an inductive process of data analysis from these case studies, three
primary categories of challenges raised by this environment were identified. First,
firms were frustrated at their lack of control over the definition of their own products. The set of features and functions in products were constrained to a great extent
by an architecture that the firm did not control. Second, while an environment of
interfirm modularity should in theory eliminate interdependencies among firms since
interfaces between products are defined ex-ante, the present study found, ironically,
that interdependencies were ubiquitous. Interdependencies continually emerged
throughout the product development process, despite efforts to limit them. Third,
firms found that the quantity and variegated nature of external relationships made
their management exceedingly difficult. The sheer complexity was daunting, given
both the size of the external network as well as the number of ties per external
collaborator. Partners with whom control over the architecture was shared often
had divergent interests—or at least not fully convergent interests.
The solutions to these challenges were creative and in many cases counter to
established wisdom. For instance, research has suggested many ways for a firm to
influence architectural standards. While the firms in the present sample followed
some of this advice, they also focused on a more neglected aspect of architecture—
the compliance and testing standards that accompany modules and interfaces.
By concentrating their efforts in a different area, even smaller firms in this sample
were able to have some influence. Instead of focusing on the elimination of
Address correspondence to: Christopher Tucci, Ecole Polytechnique Fédérale de Lausanne, EPFL-CdM-CSI, Odyssea 1.04, Station 5, CH-1015
Lausanne, Switzerland. Tel.: þ 41.21.693.0023. Email: christopher.tucci@epfl.ch.
We wish to gratefully acknowledge the support and feedback we received on this article from the editor of JPIM, Abbie Griffin, two anonymous
JPIM referees, Lynda Applegate, Michael Cusumano, Michael Hitt, Alan MacCormack, Spencer Palocz, and Lori Rosenkopf. We also wish to
thank the Hartman Center at The Fuqua School of Business, Duke University, the Ecole Polytechnique Fédérale de Lausanne, and the Division of
Research at the Harvard Business School for funding this research.
304
J PROD INNOV MANAG
2005;22:303–321
N. STAUDENMAYER, M. TRIPSAS, AND C. L. TUCCI
interdependencies, it was found that firms benefited from concentrating on the
management of interdependencies as they emerged. Finally, while layers of management and ‘‘bureaucracy’’ are often viewed as unproductive, these firms found
that adding structure, through positions such as Relationship Manager, was highly
beneficial in handling the coordination and control of a wide range of external relationships.
Introduction
T
he importance of the product development
process, its complexity, and the resulting
managerial challenges have been widely acknowledged by academic scholars and practitioners
(Terwiesch, Loch, and Niederkofler, 1998). The
BIOGRAPHICAL SKETCHES
Dr. Nancy A. Staudenmayer was assistant professor of management at Duke University’s Fuqua School of Business since 1997.
She graduated magna cum laude from Wellesley College in 1986
with a B.A. degree in mathematics and economics, and she was inducted into Phi Beta Kappa. She earned her M.A. degree in applied
statistics from the University of California at Berkeley and her
Ph.D. from the Sloan School of Management at the Massachusetts
Institute of Technology. A specialist in corporate strategy, she
taught the Foundations of Strategy course to first-year students at
Fuqua. Nancy passed away in November 2000.
Dr. Mary Tripsas is assistant professor of business administration in
the Entrepreneurial Management Unit at the Harvard Business
School. She earned her Ph.D. from the Sloan School at the Massachusetts Institute of Technology, an M.B.A. from the Harvard
Business School, and a B.S. from the University of Illinois at Urbana. Dr. Tripsas’ research examines how radical technological
change affects organizations and overall industry evolution. She
studies both innovation in established firms and entrepreneurial
opportunities with her recent work focusing on the relationships
among firm capabilities, managerial cognition, and inertia. She explores these issues through in-depth, longitudinal industry studies
and is currently studying the emergence of digital imaging.
Dr. Christopher L. Tucci is associate professor of management of
technology and chair in corporate strategy & innovation at Ecole
Polytechnique Fédérale de Lausanne. He received the degrees of
B.S. in mathematical sciences, B.A. in music, and M.Sc. in computer
science from Stanford University. He also received a master of
science in technology and policy from Massachusetts Institute of
Technology (MIT) and a Ph.D. in management from the Sloan
School of Management at MIT. His prior work experience was as
an industrial computer scientist at Ford Aerospace, where he was
involved in developing Internet protocols and applying artificial intelligence tools to industrial problems. Dr. Tucci’s primary area of
interest is in technological change and how waves of technological
changes affect incumbent firms. He is also studying how the technological changes brought about by the popularization of the Internet affect firms in different industries. He was recently elected to
the division leadership track of the Academy of Management’s
Technology and Innovation Management Division.
inherent nature of the process creates complexity in
that it requires the simultaneous coordination of multiple functional areas within the firm and multiple
constituents external to the firm. This coordination
often takes place in an environment of high uncertainty, rapid change, and competitive pressure (Brown
and Eisenhardt, 1998). While a number of tools for
better managing the product development process
have been identified, including quality function deployment (QFD) (Griffin, 1992), matrix organizations
and cross-functional teams (Kahn, 1996; Larson and
Gobeli, 1988; Swink, Sandvig, and Mabert, 1996),
heavyweight product managers (Clark and Wheelwright, 1992), technology integration (Iansiti, 1998),
standardized product platforms (Cusumano and
Nobeoka, 1998; Meyers and Lehnerd, 1997), tightly
integrated supplier relationships (Dyer, 1996), and
close user relationships (Athaide, Meyers, and Wilemon, 1996; von Hippel, 1986), relatively little research
has focused specifically on the increasingly common
industry context of interfirm modularity. This article
explores the implications of this context for product
development, shedding light on yet another layer of
complexity in the product development process.
Drawing upon the work of Baldwin and Clark
(2000), Langlois and Robertson (1992), and Schilling
(2000), the present article defines an industry as being
characterized by interfirm modularity when different
firms are responsible for designing and developing the
various subsystems of the industry’s products. In this
context, a given firm’s product is but one component
of an overall product system, and it must interconnect
with components developed by a variety of other
companies in order to have value. For instance, a
Sanyo receiver, Sony compact disc (CD) player, and
Bose speakers all work together to create a stereo system. The decentralized set of relationships among
components is guided by what Baldwin and Clark
(2000) called ‘‘design rules’’ that describe how different parts of the system will interact, ensuring
compatibility among system modules produced by
multiple firms. Interfirm modularity thus results in
MODULARITY AND PRODUCT DEVELOPMENT
the creation of a set of subindustries containing
products that are only useful when combined with
products from the other subindustries that are part of
the overall product system. In this environment, users
can customize their own systems, mixing and matching component modules from different firms.
Some industries, such as stereo systems and bicycles, have long been characterized by interfirm modularity. However, this decentralized industry structure
has become increasingly common, driven by higher
levels of specialization and the movement to open interface standards that enable products from multiple
firms to work together relatively seamlessly (Langlois
and Robinson, 1992; Matutes and Regibeau, 1988).
The shift in the computer industry from a set of vertically integrated firms to a set of horizontal subindustries including central processing units (CPUs),
disk drives, monitors, printers, and software is one
commonly cited example of interfirm modularity
(Baldwin and Clark, 2000; Yoffie, 1997). More recently, industries ranging from televisions, digital
cameras, and personal digital assistants (PDAs) to
telecommunications services are all characterized by
interfirm modularity requiring the coordination of
multiple parties, sometimes numbering in the hundreds (Iansiti and Levien, 2004).
While the increasing presence of interfirm modularity has been documented, the implications for the
product development process remain underdeveloped.
What unique challenges does this context pose? What
solutions have firms experimented with in order to
address those challenges? What solutions seem to
work and under what circumstances? Using data
from a set of field-based exploratory case studies at
seven firms, the present study examines the implications of interfirm modularity for the product development process. This context first is characterized.
Next, based on data from the present field research,
the article summarizes the most challenging issues
confronted by managers and useful practices for addressing those challenges across three domains: product definition, interdependency management, and
relationship management.
Characterizing the Environment
The article begins by developing a taxonomy with
which to distinguish differing types of interfirm modularity. The focus is on two dimensions that affect the
product development environment: (1) the number of
J PROD INNOV MANAG
2005;22:303–321
305
organizations involved in defining and/or controlling
the architecture of the system; and (2) the number of
firms involved in producing a ‘‘systemic’’ product, regardless of who controls the architecture. For this
study’s purposes, the architecture of a system comprises three elements, based on Baldwin and Clark’s
(2000, p. 78) three categories of design rules:
Module partitioning: The definition of what the
modules in the system will be and what function
each will perform. As part of defining the modules,
decisions are made about which modules are ‘‘hidden’’ and which are ‘‘visible.’’ The internal architecture of a hidden module is independent of the
rest of the system, so changes within the module
do not affect other modules. Visible modules, on
the other hand, have interdependencies with other
system modules.
Interface specification: The delineation of how modules will work together. The interface specification
will typically include multiple levels including, for
instance, the physical connection or ‘‘pipe’’ between
components, the communication protocols, and the
format of the content that travels down the pipe. It
is possible for the interface specification to change
independently of the modules themselves changing
(Henderson and Clark, 1990).
System compliance and testing: The definition of
standards for testing modules in the system for both
performance and compatibility with other modules.
Control over the architecture and its subsequent
evolution can, at one extreme, be directed by a single
firm, a centralized industry trade organization, or
specific governmental body. At the other extreme,
no single firm, institution, or coalition of firms defines
the system architecture, but instead a broad range of
players are involved in a highly decentralized process,
with different players defining different interfaces.
A single system may incorporate architectural standards developed by formal institutional standards
bodies [e.g., International Telecommunications Union (ITU)], industry-sponsored standards bodies (e.g.,
the W3C or World Wide Web Consortium), industry
consortia (e.g., the Compact Flash association for
flash memory), individual firms (e.g., Adobe’s Postscript printer page description language), or communities and nonprofit foundations (e.g., Linux)
(O’Mahoney, forthcoming). There also may be multiple competing and/or coexisting design rules for any
given system, or even a specific interface. The direct
connection between a personal computer (PC) and
306
J PROD INNOV MANAG
2005;22:303–321
N. STAUDENMAYER, M. TRIPSAS, AND C. L. TUCCI
a printer can be accomplished with at least three
different standard connections: a serial port, a parallel port, and a universal serial bus (USB) port (of
which there are at least two different plugs).
The second dimension of interest is the number of
firms involved in producing a product. At the low end,
a single firm controls the production of an entire system. This firm may use subcontractors or suppliers to
produce specific modules, but those suppliers simply
comply with a set of requirements defined by the focal
firm; they do not experiment or innovate in the development of the component module. The suppliers
also do not sell directly to the user—the overall product is still sold by a single firm. At the other extreme,
different firms might produce and sell each of the
modules of a system.
Figure 1 combines these dimensions into a matrix
and provides diagrams of product examples from each
cell of the matrix. The boxes in each diagram represent
modules in a systemic product, and the letters in each
box denote the organization producing that module.
Lines connecting the boxes represent interfaces between modules, and the letter above each line denotes
the organization(s) that define these interfaces.
Appliances
Products in the ‘‘Appliance’’ quadrant of Figure 1
(Langlois and Robertson, 1992) are low on both
Q
QKP
S
S
S
S
STU
High
KM
QOP
R
JN OR
N
M
U
P
J
J
KR
K
STV
TUV
T
T
SS
J PQ
O
QOPR
JKN
Number of
firms
involved
in defining
the system
architecture
Low
Partial Integration
Development Web
Eg. printer-camera bundle
Eg. digital camera, cell phone
D
D
AA
A
A
A
A
B
E
C
C
C
C
G
C
C
F
Appliance
Single-apex Cluster
Eg. toasters, autos, photocopiers
Eg: stereo system,
plug-compatible
mainframe system
Low
dimensions: the number of organizations defining the
system architecture and the number of firms producing
modules. They represent the base case of little or no
interfirm modularity. Examples include not only appliances such as washing machines or toasters but also
many other products such as photocopiers, portable
cassette players (e.g., the Sony Walkman), and automobiles. In the example from Figure 1, a single firm
(Firm A) decides upon a set of features and an overall
architecture for the product (low on the y-axis) and
also produces the entire product (low on the x-axis).
Firm B produces a subcomponent but, as discussed
already, simply meets the specifications supplied by
Firm A. Within the industry other firms producing the
same product may have entirely different architectures,
but since each system is self-contained, these differences are transparent to users. Consumers may either accept or reject any of the preset packages offered, but
they do not configure their own products.
The overall design of ‘‘appliances’’ may still be
modular even if the design is controlled by a single
firm. In fact, modular design principles have been
shown to create value in a number of ways. They can
significantly improve the communication and coordination within single-firm product development projects (Ulrich and Eppinger, 2000), can increase the
potential for reuse of components—thus improving
the efficiency of product development (Garud and
Kumaraswamy, 1995)—and can create option value
by enabling module-level experimentation and innovation (Baldwin and Clark, 2000).
High
Number of firms involved in
producing the “systemic” product
Figure 1. The Evolution of the Boundaries of the Product Development Process (Adapted from Baldwin and Clark, 2000;
Langlois and Robertson, 1992)
Single-Apex Cluster
In the ‘‘Single-apex cluster’’ quadrant (cf. Baldwin
and Clark, 2000), an individual or small set of organizations defines the system architecture (low on the
y-axis), but different firms produce the components
(high on the x-axis). For instance, the interfaces between components of a stereo system are centrally
agreed upon by all firms in the industry, but different
firms produce the components. Sometimes a single
firm dominates an industry and defines the architecture. IBM’s System 360 mainframe computer architecture was centrally controlled but allowed for other
firms to produce ‘‘plug compatible’’ components such
as disk drives, creating a number of subindustries
(Baldwin and Clark, 2000). In the ‘‘Single-apex
cluster’’ diagram of Figure 1, firm C would be the
equivalent of IBM, both defining the interfaces and
producing some modules. Other firms (e.g., D, E, and
MODULARITY AND PRODUCT DEVELOPMENT
F) also produce modules in the system and sell those
products directly to users.
Partial Integration
In the ‘‘Partial integration’’ quadrant of Figure 1
firms have chosen to ‘‘reintegrate’’ and to produce
multiple components of a system even though definition of the overall system architecture is decentralized,
and multiple players could produce those different
components. Firm S in the diagram is producing three
modules of the system and has taken back ownership
of the interface between those modules. But ‘‘S’’ has
followed the decentralized design rules for other interfaces, and the other modules of the product system
are made by firms T and U. An example of this type of
interfirm modularity is found in the realm of digital
imaging. Digital cameras have standard interfaces
with PCs, printers, memory cards, and PDAs. Some
firms, such as Canon, however, have created proprietary elements in the interface between their digital
cameras and printers to optimize the functionality
and, they hope, to gain market share.
Development Web
In the top right quadrant is found the most complex
form of interfirm modularity. This context is called
here a ‘‘Development Web’’ insofar as it evokes the
image of a spider’s web or complex network of relationships. The complexity of this quadrant is best
illustrated with an example. In February 2003, Motorola announced a cell phone that incorporated ‘‘the
ideal features of a mobile phone with the capabilities
of a PDA, digital camera, video player, MP3 player,
speakerphone, advanced messaging, instant Internet
access, and Bluetooth wireless technology (Motorola
Incorporated, 2003). In the development of this product, Motorola clearly did not control many aspects of
the cell phone’s architecture. Compatibility with multiple existing standards constrained the firm’s design
process. The most obvious constraint was in the kind
of cellular communications network available in various countries around the world. Cellular network
standards could be established by national telephone
carriers, government-sponsored standards bodies, private consortia, or dominant firms. However, the constraints on the architecture exceeded the simple choice
of network. In storing a digital photo, Motorola could
J PROD INNOV MANAG
2005;22:303–321
307
theoretically have developed its own proprietary file
format, but then only people with the correct decoding software would have been able to look at the
photo. Instead industry standard file formats were
used. Likewise, Bluetooth compatibility was used
for short-range identification of and communications
with digital devices/appliances. Bluetooth was originally developed by Motorola’s competitor Ericsson,
but since 2000 Motorola has been involved in the further evolution of Bluetooth. That involvement, however, involves coordination with at least eight other
firms, including Ericsson, IBM, Intel, Nokia, Toshiba, 3COM, Agere (Lucent Technologies), and Microsoft. In fact, each ‘‘feature’’ of this new cell phone
was actually a different technology that was part of a
larger system, each interface controlled by parties external to Motorola or at best with Motorola’s interdependent involvement.
Methods and Data
To better understand the implications of each of these
quadrants for the product development process, an
exploratory field-based study of seven firms was conducted. This study’s description of the challenges and
potential solutions associated with product development in the context of interfirm modularity is thus
inductively derived, initially based on informal observation of changes in product development and subsequently supported and modified based on a set
of structured interviews at these firms (Glaser
and Strauss, 1967; Yin, 1984). The present authors’
collective experience in new product development
(NPD), assorted media articles, cases, and anecdotal
comments from industry insiders suggested significant
implications for the management of product development. The goal of this research was to explore the
challenges posed by this context and some potential
solutions to those challenges. It is therefore important
to note that the aim of this study is not to establish the
validity or statistically test the generalizability of any
particular approach. Nor can conclusions be drawn
about product or project performance, although the
data are suggestive of some outcomes.
Seven firms were selected in which to conduct interviews: Red Hat, Lucent Technologies, The Gale
Group, InterWorld Corporation, Adobe Systems,
Motorola, and Lexar Media (see Table 1). Every
firm that was approached agreed to participate
in the study. Since this study sought to improve
308
J PROD INNOV MANAG
2005;22:303–321
understanding of the phenomenon, the decision was
made to focus on the technology and telecommunications sectors where interfirm modularity was more
pronounced. As shown in Table 1, some variability
was introduced in the sample in order to refine understanding of the phenomenon (Eisenhardt, 1989;
Yin, 1984). For example, The Gale Group is a major
business unit of an established publishing firm and
develops subscription-based information services for
the World Wide Web. Red Hat coordinates development of ‘‘open source’’ software and related services
and support from a single North Carolina location.
Motorola is a large, established communications and
electronics technology firm with a global presence.
Thus, the firms varied in terms of size (number of
employees), geographic location (North Carolina,
East Coast, West Coast, global), type of business (telecommunications, PC operating systems, publishing),
relative age (startup, spinoffs and older firms), and
how much control they had over the system’s architecture.
Nineteen interviews were conducted from the summer of 1999 through spring of 2000. To ensure that this
study’s observations were not simply an artifact of interviews coinciding with the Internet bubble, a second
set of 11 interviews was conducted during the winter
and spring of 2003. In choosing the interviewees within
each firm, individuals were selected from a mix of functional areas as well as multiple levels of the hierarchy.
Among the titles of the study’s subjects were director of
new product development, vice president of new product development, founder and chief technology officer,
and director of strategic alliances. Each interview lasted
more than an hour, and confidentiality was guaranteed
at the subject and project level. Thus, the name of the
firm is disclosed in the study’s illustrations and quotations except when such disclosure might compromise
the identity of the speaker. The interviews were taped,
with permission of the subjects, and were transcribed
by a professional transcription service.
Before conducting the interviews, profiles of each
of the firms were developed, based on public data such
as Annual Reports, press releases, marketing literature, trade journals, and the business press in order to
have a basic understanding of each firm’s business. An
interview protocol also was developed that defined a
common introduction and description of the research
goals and purpose and a set of specific questions. The
interviews had three parts. First, interviewees were
each asked to describe the process for two or three
completed product development projects in an open-
N. STAUDENMAYER, M. TRIPSAS, AND C. L. TUCCI
ended fashion. Second, detail was gathered on how
each product fit into an overall system—how it
worked with products of other firms and how the
interfaces with other firms’ products were defined.
Third, the interviewees were probed for information
about external relationships with questions such as,
‘‘What interactions did you have with external firms
throughout the development process? What was the
purpose, form, depth, and duration of each interaction?’’ In most cases it was possible to corroborate
information about specific projects with more than
one individual at each firm.
Data analysis began with a simple inductive process of category creation (Glaser and Strauss, 1967;
Yin, 1984). Each researcher began by searching the
interview transcripts from the set of firms for which
they were responsible, identifying both common
words and common topics in order to highlight important issues and to classify them according to a
common scheme. Some of the classifications were
identified in advance based on related research (e.g.,
relationship management), while others emerged as a
result of their ubiquity across the interviews (e.g.,
product definition). To improve the reliability of the
study’s conceptual scheme, the interviewers subsequently traded transcripts and repeated the sorting
process. The primary researchers then met and compared the results, reconciled any differences, and repeated the categorization again. Overall, the analysis process went through four iterative rounds of
culling the interviews, discussion, adjustment, and refinement (Aldenderfer and Blashfield, 1984).
Challenges and Potential Solutions
Based on analysis of the interviews, the challenges
posed by interfirm modularity and potential solutions
to these challenges were classified into three domains:
(1) product definition; (2) managing interdependencies; and (3) managing relationships. Key points are
summarized in Table 2.
Product Definition: Challenges
Many studies in product development research carry
an implicit assumption that individual firms maintain
control over their product architecture—the basic set
of components and interfaces present in the product.
Constraints on product development therefore are
considered primarily internal, imposed by technological barriers, market analysis, or cost/resource
Suppliers
Customers
Durham, NC
‘‘Open source’’
software products
and associated
service and support
1993
Expand market
share of Linux OS
and increase
revenues from
services and
support
Suppliers
Customers
Geographic Locations
Primary Products or
Services
Founded
Strategic Challenge
Examples of Key Types
of External Partners
Integrate recent
acquisitions;
manage very large
software and
hardware
development
projects
Result of corporate
breakup of 100year-old firm in
1996
Communications
equipment (e.g.,
digital switches) for
wired, wireless and
cellular phone
services
New Jersey,
Illinois, Denver,
and several
international
locations
Large (n 5 25,000–
35,000 employees)
Small (n 5 160
employees)
Size (Approximate
Number of Employees)
Spinoff of AT&T
Bell Labs; develops
real time global
telecom equipment
and services
A software firm
that introduced
open source
software strategy
Lucent
General Description
Red Hat
Table 1. Summary of Firm Sample
Customers
(librarians)individuals
Content suppliers
Transition from
print to electronic
information
products
1995 in three-way
merger
Electronic
subscription-based
information
services
Farmington, MI
Medium (n 5 1800)
A major
independent
business unit of
an established
publishing firm
The Gale Group
Semiconductor
manufacturers
Camera
manufacturers
Managing through
the uncertain
evolution of new
industries such as
digital imaging
1996
Removable digital
storage media for
digital photography
and consumer
electronics
Fremont, CA
Small (n 5 200)
Cirrus Logic
spinoff that makes
removable memory
for digital
photography and
other markets
Lexar Media
Technology
development
partners
Channel partners
Managing channel
partnerships to
allow EDI and
other kinds of
electronic
commerce in a
variety of firms;
manage growth
1995
Custom software
enabling companies
to engage in
electronic
commerce
New York
Small (n 5 200)
Startup in
electronic
commerce
Interworld
Media/content
companies
Customers
Suppliers
Establishing their
technologies as
world-wide
industry standards,
establish strong
position in wireless
Internet access
Adapting imaging
strategy for the
Internet
Graphic designers
1928
Communications
and computer
components,
cellular telephones,
pagers
Chicago, IL,
Austin, TX,
Phoenix, AZ, and
several
international
locations
Large
(approximately
100,000)
Established
electronics
company that is
transitioning into
consumer telecom
products
Motorola
1982
Electronic
document formats,
graphic design, and
imaging software
San Jose, CA
Medium (n 5 2700)
Established
software company
Adobe Systems
MODULARITY AND PRODUCT DEVELOPMENT
J PROD INNOV MANAG
2005;22:303–321
309
Other wireless
device producers
Other SW
companies
Standards
institutions
Standards
institutions
Digital camera and
scanner producers
Printer and
image-setter
manufacturers
N. STAUDENMAYER, M. TRIPSAS, AND C. L. TUCCI
Software
developers
Distributors
Hardware
producers
Other firms
developing
software in system
architecture
Complementary
Standards
technology partners institutions
PDA, cell phone
manufacturers
Specialized
knowledge and
technology
suppliers
International
governments
Open source
developers
Examples of Key Types
of External Partners
(Cont’d.).
Table 1. (Cont’d.)
Red Hat
Lucent
The Gale Group
Lexar Media
Interworld
Adobe Systems
End-user hardware
companies
J PROD INNOV MANAG
2005;22:303–321
Motorola
310
constraints. Much work in the realm of operations
management related to product design and mechanical
engineering has focused on optimizing development in
this context (e.g., Nelson, Parkinson, and Papalambros, 1999; Papalambros, 1995). Given a requirements
specification that outlines the desired performance and
cost of the product, developers follow a process that
provides the best match between technology and the
requirements. For instance, Nelson, Parkinson, and
Papalambros (1999) described the conditions under
which it might be optimal to share a component across
two designs, given that the performance of one or both
designs might suffer due to the design changes. In this
case, the implicit assumption is that the firm controls
the interface between the component and the product
for both possible products.
In the presence of interfirm modularity, however, an
increasing proportion of the crucial architectural decisions are imposed on companies by external firms and
institutions. The system-level product architecture—
the modules and interfaces—is often not within the
control of the firm. Instead, the definition of the system
architecture, and the associated ownership and control
issues, become areas of intense negotiation. Dominant
market players, formal standards bodies, and informal
alliances among companies therefore have a strong influence on any given firm’s product architecture.
The firms in the present sample recognized that they
were operating in an environment where key architectural decisions were often out of their control. As an
executive at Interworld noted, ‘‘[Our products] fit into
a broader system or existing system. Whether they
were payment processing systems, or order-fulfillment
systems, or inventory systems, or accounting systems,
they were plugged into . . . an existing infrastructure
and had to connect to those existing infrastructures . . .
[we control] essentially nothing of the broader system
. . . we had to have adapters to SAP . . . into financial
systems and for order fulfillment.’’
Given that much of the product architecture was
outside of their control, firms were frustrated at
their inability to provide what they considered
the best product for the customer. As one executive
summarized succinctly, ‘‘There are balances to what
we do . . . We end up sacrificing performance to accommodate an industry standard more and more of
the time.’’ Firms also found it challenging to differentiate their products given the constraints of the
commonly shared interfaces imposed on them. Consumers sometimes had difficulty distinguishing products of different firms, depending upon how much
MODULARITY AND PRODUCT DEVELOPMENT
J PROD INNOV MANAG
2005;22:303–321
311
Table 2. Operating in an Interfirm Modular Environment: Concerns and Potential Solutions Identifieda
Concerns Raised
Potential Solutions Identified
Product Definition
Product definition and design are constrained by interfaces that
1. Attempt to influence key parts of the system architecture to your
other firms or institutions control
advantage
Invest in firms producing complementary products
Firms cannot always optimize performance of their modules
Share personnel on product development teams with other firms
Differentiating products is difficult given the need to
Focus on ‘‘neglected’’ parts of the architecture such as testing
accommodate common standards
standards
The location of value/intelligence in the system becomes an area of Reintegrate across modular boundaries in order to optimize
performance
negotiation.
2. Given an existing architecture, differentiate within ‘‘hidden’’
module subindustries
Develop intellectual property
Bundle value-added services
Interdependency Management
Even though the system architecture is modular, hidden
3. Develop fluid task structures and emphasize experimentation
interdependencies remain
Changes made by other firms can affect the performance of a 4. Create a modular organization within the firm that is flexible and
given firm’s product
accommodates change throughout the development process
Changes made by other firms can occur in the middle of a given
firm’s development project and impose changes in product
5. Use internal–external teams with longer lead times to plan module
design
upgrades
Coordination of systemic change—upgrading multiple modules
simultaneously—is difficult
Relationship Management
Decentralized multiparty networks of relationships are highly
6. Recentralize control over formal product development alliance
complex and difficult to coordinate
management
External firms simultaneously hold both convergent and divergent
interests
7. Categorize and manage relationships by tiers
Firms often have multiple concurrent, yet uncoordinated,
relationships with a single external firm
Multiple interfaces exist at all levels of the organizational
hierarchy
Individuals often lack knowledge of other relationships
Relationships are both formal and informal
a
The solutions do not correspond line by line with the concerns but rather section by section. Solutions are numbered for expositional purposes in
the conclusion.
unique value could be communicated. Despite efforts
to clarify product differences in the UBS Flash Drive
market, Lexar found that many consumers simply
categorized the product as a ‘‘floppy disk replacement’’ not understanding the additional features that
flash drives could offer.
Product Definition: Potential Solutions
An important decision for firms in this environment
was which of two strategic paths they should follow:
should they attempt to influence at least part of the
overall architecture to their advantage, or should they
simply optimize given the existing industry architecture? Firms with more market power, such as Motorola in the paging domain, attempted to influence the
overall architecture, whereas smaller firms, such as
Lexar Media in removable storage media, were more
inclined to accept external architectures.
The first response was basically an attempt to move
from the ‘‘Development web’’ quadrant closer to the
‘‘Single-apex’’ quadrant by controlling key parts of the
architecture. This strategy is discussed in some depth in
the literature on complementary products and standards (McGahan, Vadasz, and Yoffie, 1997; Sengupta,
312
J PROD INNOV MANAG
2005;22:303–321
1998; Shapiro and Varian, 1999). Intel’s Architecture
Lab encouraged other firms to develop products compatible with Intel’s products (Gawer and Cusumano,
2002), while NEC cultivated relationships with thirdparty developers in the Japanese PC industry (Methe,
Toyama, Miyabe, 1997). Similarly, the firms in the
present sample attempted to influence adoption of their
preferred architectures. Red Hat invested in early-stage
ventures that they thought would help deploy Linux,
and Motorola and Adobe Systems both created corporate venture capital funds that searched out and
made investments in potential complementary technologies. Lexar influenced the oft-neglected third element
of architecture, system compliance and testing. Lexar
was able to help establish ‘‘click to click’’ time as the
appropriate speed measure for Compact Flash used in
a digital camera. When their primary competitor advertised a speed advantage using a different metric,
Lexar filed and won a false advertising lawsuit. Thus,
even focusing on what might be considered a less critical element of architecture created value.
Adobe Systems’ actions driving the genesis of desktop publishing provide a comprehensive example of
how multiple mechanisms can be utilized to influence
an architecture. Adobe exploited a number of external
collaborative relationships to exert some control over
the architecture of desktop publishing systems and to
establish the Postscript printer page description language as a de facto interface standard between applications software and laser printers. Postscript technology facilitated the emergence of desktop publishing by enabling the use of typeset quality fonts and the
integration of text and graphics in documents created
and printed with desktop equipment. Previously, professional publishers and printers were needed to generate such documents. In promoting Postscript,
Adobe engaged producers of each complementary
module: Apple (which provided the Mac computer
and Laserwriter printer), Aldus (which provided
Pagemaker software), and Linotype-Hell (which provided typeset quality font designs). These relationships helped to ensure a large number of Postscript
users early on, avoiding the chicken–egg problem often encountered when starting a feedback process. To
facilitate further adoption, Adobe also provided continual support to application developers and printer
manufacturers, making the integration of Postscript
in their products easier. Adobe would often provide
one of its own employees to participate on the product
development team of a printer manufacturer that was
incorporating Postscript technology.
N. STAUDENMAYER, M. TRIPSAS, AND C. L. TUCCI
When firms could not influence the overall architecture, they often attempted to regain some control
by moving from the ‘‘Development web’’ quadrant
of Figure 1 to the ‘‘Partial integration’’ quadrant, by
rebundling modules in the system, sometimes in collaboration with other firms. Ideally the combined
modules would have higher performance when bundled but could still function with other firms’ products
if needed. For instance, Lexar Media worked with
cameramaker Nikon to develop an interface that
would optimize the speed of Lexar’s flash memory
when it was used with an Nikon digital camera. While
Lexar Media’s flash memory would still work with the
cameras of other manufacturers, and Nikon digital
cameras could use flash memory from other firms,
performance was significantly improved with the
Lexar/Nikon combination. Although Lexar maintained broad compatibility, this strategy could be
dangerous if the newly bundled combinations had
proprietary interfaces and were no longer compatible
with products from other firms.
Another option when firms could not influence the
overall system architecture was to identify means for
differentiation within the hidden module. They often
attempted to move functionality and bring value into
the module(s) that they did control. While the protection of intellectual property is important in many
industries, it was particularly key in this situation
where so much of the product definition was standard
across firms. For instance, even though the interface
for Compact Flash was defined by an industry association, Lexar Media developed a patented controller
that enabled its Compact Flash to store images from a
digital camera more quickly than competitive products. Another option was to bundle the product with
value-added services. For example, Red Hat bundled
consulting and distribution services with the commodity Linux package that one could, theoretically, download and install for free over the Internet.
Interdependency Management: Challenges
An interfirm modular environment is by definition
supposed to be characterized by interfaces that eliminate interdependencies. Without eliminating interdependencies and without agreeing upon design rules,
the products of different firms would not work together well enough for consumers to be satisfied doing
their own mixing and matching. So in a ‘‘perfect’’
setting, firms producing the different components of
MODULARITY AND PRODUCT DEVELOPMENT
an interfirm modular system would have no interdependencies.
Ironically, this study found that the large number
of firms involved in the creation of these systemic
products, combined with the imperfect ability of individuals to predict interdependencies, resulted in a
situation where firms experienced more, rather than
fewer, interdependencies with external firms in this
environment. The systems were indeed ‘‘nearly decomposable’’ (Simon, 1962). Clean lines could not
always be drawn, both within and between firms.
Many interdependencies were not necessarily identifiable in advance or visualizable by employees; instead, they emerged unexpectedly over time. Given the
shifting patterns of structures, relationships, and tasks,
and the presence of multiple-party effects where firms
communicated with one or two partners who in turn
were interdependent with other parties in the network,
more and more interdependencies remained ‘‘hidden’’
or beyond the conscious awareness or purview of all
team members. These hidden interdependencies could
pop up unexpectedly and required flexible management responses. Events such as the emergence of new
firms or changes in competitive strategy often created
new interdependencies mid-process (Tjosvold, 1986).
When other firms made changes to interdependent
modules, that change might simply affect the performance of other modules or might require that a firm respond by changing its product design. So despite the
appearance of independence, even firms that had no
formal relationship experienced interdependencies in
this environment.
Other emergent interdependencies resulted from
cognitive limits at the individual level. It was simply
impossible to unearth all the interdependencies in advance in very large system products. Some interdependencies emerged over time as a result of increased
experience and knowledge of tasks. For instance, one
executive in the present sample lamented that ‘‘there
are some examples where we have gotten really far
down the road and then we decide, you know, we
can’t do that fundamental thing that you need us to
do.’’ Product requirements and features therefore
were continually evolving and were driven as much
by external as internal factors.
Interdependencies also created frustration when
making systemic changes and upgrades. Upgrading
a module could be a difficult task as could reacting to
a partner’s proposed upgrade. Systemic shifts were
especially challenging since coordination among the
decentralized group of firms in different subindustries
J PROD INNOV MANAG
2005;22:303–321
313
was difficult. Since changes to multiple modules involved coordinating multiple parties, it was often difficult to accomplish. In addition, the incentives of
firms around whether to make a break with the past
and to announce an incompatible upgrade differed,
with firms that held a strong position preferring to
maintain upward compatibility to exploit their installed base and with other firms preferring to make a
break and attempt to level the playing field (Dhebar,
1995).
Interdependency Management: Potential Solutions
Existing thinking on interdependency management has largely emphasized up-front minimization
or outright elimination of interdependencies, particularly with those outside the team (Galbraith, 1973;
Thompson, 1967). The goal has been to identify the
tasks, to define the interdependencies between them,
and then to redistribute the tasks and/or to redefine
the product architecture to minimize contingencies
(Eppinger et al., 1994; Van de Ven, Delbecq, and
Koenig, 1976; von Hippel, 1990). For example, if two
different software development teams needed to access to and change the same software module and
their actions conflicted, resulting in a failed system
integration or system ‘‘crash,’’ the recommended solution would be to resegment the contingent tasks so
that only one team was responsible for both sets of
changes.
In contrast, this study found that for firms in this
sample, systematic management of interdependencies,
as opposed to attempted up front elimination of
them, was more effective. Unfortunately, as discussed
previously, in many situations identifying all interdependencies ex ante was not possible; some interdependencies emerged midstream despite efforts to
minimize them. Managers therefore focused on coordinating portfolios of interdependent development relationships holistically, attempting to recognize and to
adjust to changing patterns as they arose rather than
eliminating or minimizing interdependencies through
initial structures (Bensaou, 1999; de Figuerido and
Teece, 1996; Miller, 1993; Staudenmayer, 1997).
For example, Lucent’s software development
group, encompassing both internal employees and
external collaborators, developed a process for
bringing interdependencies out ‘‘into the light’’ when
they occurred. If two different teams or individuals
caused a system ‘‘crash’’ upon reintegration, they
314
J PROD INNOV MANAG
2005;22:303–321
communicated directly with each other to negotiate a
solution—all dependencies were to be pursued person
to person and not via proxy or third party. Only if an
interdependency cropped up several times was there
an attempt to ‘‘sever’’ it by consolidating control in
one team. Interestingly, Lucent found that most interdependencies were only sporadic and not consistent. This more flexible approach, while difficult at first
in that it required more frequent interactions, also
enabled the various teams to adjust to ongoing changes more effectively.
Building flexibility and experimentation into the
design process also became extremely important (cf.
Thomke, 1997; Thomke, von Hippel, and Franke,
1998) to deal with unpredictable change imposed by
other firms changing their modules. In the firms studied here, evidence was found of fluid organizational
structures and task assignments where team members’
roles evolved throughout the project. Task assignments within the team were no longer distinct. As a
manager of a new wireless project at Lucent observed,
‘‘Everyone is responsible for everything.’’ Boundaries
defining who was inside versus outside the team were
also becoming fuzzy (cf. Bleeker, 1994; Davidow and
Malone, 1992; DeSanctis, Staudenmayer, and Wong,
1999). Flexibility also came through forming a modular internal organization to increase adaptability and
responsiveness (Sanchez and Mahoney, 1996).
In attempting to overcome the problem of coordinating systemic product upgrades, some firms found it
useful to create a special track of advanced long-term
development projects that did not follow typical release cycles (e.g., a release every year or six months).
The advantage of such an approach was that for major changes, the firm’s partners and complementors
knew what to expect and were better able to buy into
the long-term plan. The relative lack of time pressure
also enabled enlarging the scope of the team, with
heavy representation from external stakeholders. For
products that were coming to market immediately,
it would have been impractical to work with so many
constituencies. For example, Red Hat had a team
associated with Red Labs that was working on
products/features destined for two to three years in
the future. This contrasted with a typical Red Hat
product development team that was working under
a four-month release cycle. The Red Labs teams
typically had 5–10 internal developers, 10–20 active
external developers representing different firms’
(and even individuals’) interests, and 100–200 less
active external members whose primary roles were
N. STAUDENMAYER, M. TRIPSAS, AND C. L. TUCCI
tracking what was happening, providing limited input, and developing small pieces of the products/
features.
Relationship Management: Challenges
The nature of product development is such that it has
always involved contact with players outside the
boundaries of the firm. Producers source components
from suppliers and integrate those components into
their products. The management of these supplier relationships has been found to yield accelerated product development through early, on-site supplier
involvement during the design, development, and production of new products, services, or processes (Clark
and Fujimoto, 1991; Dyer, 1996; Imai, Ikujiro, and
Takeuchi, 1985; Takeuchi and Nonaka, 1986). Similarly, customers provide important input regarding
their needs and sometimes become involved in the
design process (Athaide, Meyers, and Wilemon, 1996;
von Hippel, 1990). Understanding whether new products satisfy user needs, perform unique tasks, or have
unique features is a strong predictor of new product
success (Cooper, 1985). There thus exists considerable
empirical evidence that external collaborations, resources, and relationships constitute an important
part of the development process (Brown and Eisenhardt, 1995, 1998), although formal collaborative relationships in this domain have been traditionally
managed as a discrete set of external dyads, with individuals playing key roles such as a ‘‘gatekeeper’’
(Allen, 1977; Roberts and Fusfeld, 1982), ‘‘scout,’’ or
‘‘ambassador’’ (Ancona and Caldwell, 1990, 1992).
In an interfirm modular environment, however, especially in the ‘‘Development web’’ quadrant, the network of external firms with which a given firm might
interact was on a different scale in terms of both the
diversity and complexity of relationships. Rather than
a set of dyadic relationships, firms were embedded in a
broader, interrelated web of organizations including
customers, suppliers, complementary producers, competitors, and institutions (Bensaou, 1999; Singha and
Cusumano, 1991; Tidd, 1995). Firms had a combination of formal and informal relationships with other
organizations, and in addition, these organizations
also had relationships with each other. Firms in the
present study’s sample therefore found that the coordination of relationships was much more difficult,
with communications among multiple players particularly challenging.
MODULARITY AND PRODUCT DEVELOPMENT
To begin with, the scale and variegated nature of the
relationships was overwhelming. In addition to some
formal joint development projects, firms had less welldefined strategic alliances, multifirm research consortia, as well as arms-length relationships that occurred
through trade associations and standards bodies. Coordinating this portfolio of relationships without sacrificing development time and quality was challenging.
As a Gale Group product manager told us, ‘‘The
number of partners that you have to have to be viable
these days has grown exponentially, so overall you are
putting much more energy into it.’’ Another interviewee lamented, ‘‘Just keeping track of [partner relationships] is hard, isn’t that embarrassing?’’ Given the
proliferation of contacts, people needed to know
much more about the tasks of individuals outside the
firm’s boundaries, including individuals working for
organizations with which a firm had no formal relationship. For example, a manager of one project commented, ‘‘From one to twenty people have to know
what you are doing every minute while you are doing
it, which affects how fast you can do it.’’
Coordinating firms with divergent interests was another challenge. As a manager at Red Hat put it, ‘‘In
the a.m., you can be my partner, but in the p.m. you
can be my competitor. And in a lot of cases, you are
both at the same time.’’ A related challenge was how
to control indirect effects where the results of one
dyadic collaboration spilled over into other current or
future relationships. For example, Red Hat had an
equity relationship with Intel and a revenue relationship with Dell. Dell was also a partner of Intel. So
whatever happened in the Red Hat/Dell relationship
could potentially have an impact on Red Hat’s relationship with Intel. Thus, one critical issue was how to
account for one’s collaborator’s collaborators.
The complex network of external collaborations
also fundamentally changed the nature of internal interdependencies and communication. Whereas earlier
dyadic firm relationships generally had a single point
of contact, respondents spoken to in this study noted
that external collaborations now had multiple points
of contact at different levels of the hierarchy, requiring higher levels of internal coordination in order to
effectively manage them. This shift could be in part
due to the general trend toward greater decentralization and autonomy (Hitt, Keats, and DeMarie, 1998).
For example, a strategic alliance with one partner
might yield multiple projects, thus requiring numerous project managers in the firm to coordinate closely.
Integration therefore was multidimensional, occur-
J PROD INNOV MANAG
2005;22:303–321
315
ring across levels, functions, and business units or divisions in a dynamic time frame. In fact, it was not
uncommon for different groups within the company
to be unaware that they were simultaneously coordinating with the same partner. As one executive noted,
‘‘We literally have cases where different people are
talking to the same outside partner on projects that
other people don’t know about . . . and [other business
units] may have past relationships with other companies that you may or may not know about.’’
Motorola’s involvement in wireless Internet service
provided one example of relationship challenges. A
broad range of wireless information devices was
emerging, ranging from laptop computers to ‘‘communicators,’’ (e.g., PDAs with wireless connections)
to enhanced mobile phones. Motorola was involved
with the development of a key component of these
devices: the computer chips that enable the service.
Motorola also manufactured the cellular phones
themselves. To compete in this emerging arena, Motorola had to coordinate with a number of external
firms. For instance, in 2000 Motorola was a member
of the Symbian alliance (along with Psion, Ericsson,
Nokia, and Matsushita), a group that was jointly
developing Epoc, an operating system for mobile
phones. At the same time Nokia, one of the partners
of Symbian, also was working directly with Palm
Computing to develop a competing cell phone operating system. In addition to these stakeholders, Motorola also had to work with both private and public
organizations involved in developing complementary
standards, including Bluetooth (a connectivity standard as discussed already), Java, and the Wireless Application Protocol (an information services standard).
Lucent Technologies provided another example of
some of these challenges. Digital switch software
products were primarily designed to provide new services such as Caller ID or Call-Return. Yet these new
functions had to be integrated into the existing software system infrastructure architecture, most of
which was designed and implemented 25 ago. Lucent
therefore faced the challenge of managing a ‘‘legacy’’
of external collaborations with customers that utilized
these older systems in addition to developing and
coordinating with a broad range of new partners.
Teams involved internal Lucent engineers working on
the new product, internal developers maintaining
and creating interfaces with the old system, marketing representatives, external standards-making
boards, computer hardware manufacturers, phone
manufacturers, the corporate customer, end users,
316
J PROD INNOV MANAG
2005;22:303–321
and international governmental and institutional
structures. The development and subsequent deployment of new products/services therefore involved hundreds of people both inside and outside the firm,
spanning multiple time periods, with many organizational and functional affiliations.
Relationship Management: Potential Solutions
To manage the diversity of relationships with which
they were confronted, some of the firms in the present
sample centralized control over relationship management. They created a new role of ‘‘relationship manager,’’ an individual who typically reported to the
division head or chief executive officer (CEO) and
was responsible for coordinating strategic collaborations across the firm. This individual kept track of all
external relationships across multiple development
projects to ensure that the entire portfolio of relationships was balanced. A relationship manager could keep
track of not only the firm’s own dyadic relationships
but also relationships among other firms in order to
know ‘‘who was talking to whom and about what’’
according to a manager at the Gale Group. Thus potential conflicts could be identified and resolved before
they materialized in a significant way.
When a firm had multiple relationships with a single partner, a relationship manager served as a control
point, coordinating and communicating across projects. For example, the IBM relationship manager at
Red Hat focused on ensuring that the messages being
sent to IBM were consistent and coordinated. Establishing a relationship manager also helped to establish
long-term relationship memory in the firm. As explained by one Gale Group executive, ‘‘It seems to me
that most of the partnerships that we pursue, we pursue for a larger aim than any one particular project.’’
The expectation of future interactions combined with
the knowledge that there was organizational memory
could help to control potential opportunistic behavior
among partners.
Some of the sample firms also categorized relationships by tiers, defining distinct ‘‘mini webs’’ within
their full set of external collaborators. These subsets
of firms, typically categorized based on the function
of the relationship (e.g., equity, revenue-generating),
were coordinated intensely. For example, at the time
of the interviews, Red Hat had 10 revenue-generating
collaborations. Some of these were called ‘‘Tier One’’
relationships because they were the firm’s most im-
N. STAUDENMAYER, M. TRIPSAS, AND C. L. TUCCI
portant and influential partners. At any given time,
only about half of those were actively and intensively
involved in developing the latest rounds of new products, features, and services. Other firms within the
sample identified a focal partner for external contact
that served as a gateway to other producers. The firms
communicated often with that primary contact, and
that contact was in turn responsible for communicating with and coordinating more peripheral partners,
both of which are examples of so-called ‘‘nesting’’ coordination techniques—webs within webs (Mintzberg
and Van der Heyden, 1999).
Matching Solutions with Types of Interfirm
Modular Environments
The concerns outlined led to experimentation on the
part of the firms in the sample as they searched for
solutions to help them cope with their environments.
While performance data is not known, the solutions
have been identified that appeared to be most appropriate for each quadrant of the matrix (see Figure 2).
Thus, as managers apply the solutions identified in
this study, it is suggested that they first evaluate which
quadrant of the matrix they are currently located in
and then identify appropriate action.
Since firms in the Appliance quadrant are not experiencing interfirm modularity, most of the solutions
suggested would not apply. The one exception is the
application of flexible, modular design principles to
the organization. If a firm is using modular design
principals for its internal product development efforts, then it has been suggested that a parallel modular organization improves performance (Sanchez
and Mahoney, 1996). In fact, a more flexible, modular organization form is suggested for all quadrants of
the matrix.
In the ‘‘Single-apex’’ quadrant, given that a firm is
not the one controlling the architecture—and assuming that that the firm is unable to exert control over
the architecture, at least in the short term—it is suggested that differentiating and adding value within the
hidden modules is the best course of action. The need
for extensive external relationships in product development is more limited in this context since firms are
dealing with a single entity that controls the architecture, and thus relationship management solutions
were deemed relatively less important and are not included here.
When multiple firms are involved in defining the
architecture, as in the ‘‘Partial integration’’ quadrant,
MODULARITY AND PRODUCT DEVELOPMENT
J PROD INNOV MANAG
2005;22:303–321
1. Attempt to influence architecture to
advantage
2. Aim to differentiate within module
3. Develop fluid tasks structures and
experiment
4. Create a flexible modular organization
5. Use internal-external teams with long
lead times
High
6. Centralize control over PD alliance
management
7. Categorize and manage relationships by
tiers
Number of
organizations
involved in
defining
the system
architecture
Partial Integration
4. Create a flexible modular organization
317
3. Develop fluid task structures,
experiment
4. Create flexible modular organizations
within firm
5. Use internal-external teams with long
lead times
6. Centralize control over PD alliance
management
7. Categorize and manage relationships by
tiers
Development Web
2. Aim to differentiate within modules
4. Create flexible modular organizations
within firm
Low
Appliance
Single-apex Cluster
Low
High
Number of firms involved in
producing the “systemic” product
Figure 2. Proposed Solutions and How They Fit with the Types of Interfirm Modularity
then external relationships become important, so solutions such as centralizing relationship management
become relevant. But since firms in this quadrant were
generally combining previously distinct modules in
order to add value, differentiation within hidden modules was not suggested. Finally, in the ‘‘Development
web’’ quadrant all of the solutions suggested by the
firms in the sample would be appropriate.
Conclusions and Implications
Summary
This article explored the implications of interfirm
modularity for the product development process.
While a great deal of research has examined the organization of product development, relatively little
work has focused on the context of interfirm modularity in particular—a context that is becoming more
relevant across a number of industries. Interfirm modularity allows the products of different firms to work
together in a decentralized system, often configured
by the user. While some products such as stereo sys-
tems have had this characteristic for a long time, others have only recently moved in this direction. Two
dimensions of interfirm modularity are identified that
are key: whether multiple firms produce products in a
system and whether multiple firms/institutions control
the overall architecture of the system. In the most extreme environment, called a Development Web, firms
are confronted with a highly decentralized environment where large numbers of organizations have influence over different parts of a system’s architecture,
and multiple firms produce the products that make up
the system.
Through an exploratory field-based study of product development processes at seven firms, both challenges and potential solutions to the challenges raised
by this context were documented, making a number of
contributions to understanding of the product development process. Challenges fell into three broad domains. First, firms were frustrated at their lack of
control over the definition of their own products.
Standard external interfaces imposed constraints on
what their own products could deliver. Second, while
an environment of interfirm modularity should in
318
J PROD INNOV MANAG
2005;22:303–321
theory eliminate interdependencies among firms since
interfaces between products are defined ex-ante, it was
found, ironically, that interdependencies were ubiquitous. Interdependencies continually emerged throughout the product development process, despite efforts
to limit them. Third, firms found that the quantity and
variegated nature of external relationships made their
management exceedingly difficult. The sheer complexity was daunting, given both the size of the external
network as well as the number of ties per external
collaborator. Partners with whom control over the
architecture was shared often had divergent interests,
or at least not fully convergent interests.
The solutions observed in this sample of firms were
creative and in many cases ran counter to established
wisdom. For instance, research has suggested many
ways for a firm to influence interface standards, especially in markets with network externalities (e.g.,
Shapiro and Varian, 1999). While the firms in the
present sample followed some of this advice, they also
focused on a more neglected aspect of architecture,
the compliance and testing standards that accompany
modules and interfaces. By concentrating their efforts
in a different area, even smaller firms in the sample
were able to have some influence. Similarly, existing
research has focused on how to eliminate interdependencies via task partitioning, modularization of
tasks, or structured coordination mechanisms (Galbraith, 1973; von Hippel, 1990). In the context of interfirm modularity, however, it was observed in the
present research that instead of focusing on the elimination of interdependencies, firms benefited from
concentrating on the management of interdependencies as they emerged. Finally, while layers of management and ‘‘bureaucracy’’ are often viewed as unproductive, even the relatively young firms in the
sample found that adding structure, through positions such as relationship manager, was highly beneficial in handling the coordination and control of a
wide range of external relationships.
In addition to enhancing understanding of the
product development process, this study also helps
extend understanding of change and coevolution
across levels of analysis. The present work demonstrates that change at the industry level in the form of
increased modularity and standards can lead to profound changes at the organization, team, and individual levels. But as organizations experiment with new
technological and organizational solutions to cope
with this changing environment, their actions in turn
contribute to the environment within which they op-
N. STAUDENMAYER, M. TRIPSAS, AND C. L. TUCCI
erate (Rosenkopf and Tushman, 1994). Changes at
the level of the environment and firm level relationships therefore are related to new organizational
forms and processes and vice versa, creating a reciprocal feedback loop (between individuals and firm,
industry and firm, and among interacting firms).
Implications for Future Research
A number of interesting questions for future research
arise from this work. Previous scholars have addressed the issue of ‘‘product proliferation’’ as more
and more firms develop different versions of a core
design (Barnett and Freeman, 1999). The present
work suggests a parallel problem of ‘‘collaboration
proliferation.’’ Thus, the presence of more and more
external collaborative relationships means that firms
must confront the inevitable issue of when and how to
dissolve relationships. Clearly, there exists an upper
limit in terms of just how many collaborations a firm
can reasonably maintain and get value from over time
due to cognitive and coordination limits. Furthermore, opportunities are continually arising where a
new partner with greater expertise or industry power,
or both, may be preferred over an existing one.
Yet what are the criteria for disengaging, and how
can a firm do so gracefully without limiting future
opportunities for interaction? Collaborations, especially founding ones, involve an intense emotional
component. How could (or should) a company abandon a small firm that played an important part in their
success? The challenge of collaboration management
in a modular industry environment involves knowing
not only how to form and maintain, but how to dissolve such relationships. It involves balancing and
managing personal and emotional issues just as much
as strategic ones (DeSanctis, Staudenmayer, and
Wong, 1999). Previous scholars have primarily concentrated on the ‘‘courtship’’ and ‘‘marriage’’ of external collaborating (e.g., Jemison and Sitkin, 1986).
The present work would imply that there needs to be
equal attention to issues of ‘‘divorce’’ or deliberately
ending collaborations.
Another question concerns the generalizability of
the present findings. While the relevance of this research is clear for traditional high technology complex
systems industries already characterized by interfirm modularity, it also has implications for historical ‘‘appliance’’ industries that are becoming more
networked. For instance, the home automation industry takes a number of previously distinct product
MODULARITY AND PRODUCT DEVELOPMENT
categories and creates interfaces among them in order
to deliver an overall system. The management of intrafirm and interfirm networks in this evolving industry is thus an important element of product
development (Tidd, 1995).
While there is a temptation to think of modules and
interfaces in terms of a physical product, one also can
imagine knowledge-based industries for which interfirm modularity is relevant. The drug development
process and the biotechnology and pharmaceutical
industries, for instance, share many of the characteristics described here, with interorganizational networks of learning playing a key role (Powell, Koput,
and Smith-Doerr, 1996), even if the end product, a
drug, is not a systemic product. Some of the suggestions described here for relationship management
therefore also may be relevant for firms in these industries, while concerns about product definition may
be less salient.
Lastly, interfirm modularity is becoming increasingly important in industries historically categorized
as low tech due to the adoption of the Internet across
industries (Afuah and Tucci, 2003; Brews and Tucci,
2003). Publishing, for instance, is in the midst of radical change as more and more material is published
real-time over the Web without the need for typesetting and printing of batched material. The present
authors look forward to research that examines the
impact of interfirm modularity on product development in these additional industries.
Given increased levels of flexibility and fluidity, it
seems that firms undergoing industry changes toward
modular environments may want to reconsider the
manner in which they track and communicate both
internal and external collaborative relationships, depending on the type of modular environment their
industry is evolving toward. For example, traditional
organization charts, which treat people and units as
boxes with clear lines of connection, primarily represent vertical chains of authority. Not only are such
representations unable to keep pace with the level of
change inside the firm, they also somehow fail to help
employees struggling to understand how their companies work. What are the relationship ties and configurations? What parts connect to one another in
web-like interdependencies? How should processes
and people come together? Organizational charts’
relevance therefore may be diminishing in situations
where traditional forms of hierarchy are being replaced by new organizational forms. Elements such
as chains, hubs, and webs represent what an organi-
J PROD INNOV MANAG
2005;22:303–321
319
zation is and what it does: relationships and processes
as opposed to names, titles, and reporting relationships (Mintzberg and Van der Heyden, 1999). The
present research indicates that firms are desperately
searching for adequate ways of representing new organizational forms that capture the rich complexity of
work relationships today but are also simple and flexible enough for employees to understand—an area
demanding future research. Indeed, numerous examples were seen where firms were experimenting with
solutions to the coordination of collaborations such
as the role of a relationship manager, nesting coordination techniques, new metrics, and databases to
track partner value. Further theoretical and empirical work is needed to establish the basic conceptual
problem and test the robustness of these managerial
solutions. The context outlined in this article foreshadows new managerial challenges and new theoretical and empirical research opportunities that will
increase understanding of work in contemporary organizations.
References
Afuah, A. and Tucci, C.L. (2003). A Model of the Internet as Creative
Destroyer. IEEE Transactions on Engineering Management
50(4):395–402.
Aldenderfer, M.S. and Blashfield, R.K. (1984). Cluster Analysis. Thousand Oaks, CA: Sage, Quantitative Applications in the Social Sciences Series No. 44.
Allen, T.J. (1977). Managing the Flow of Technology. Cambridge, MA:
MIT Press.
Ancona, D.G. and Caldwell, D.F. (1990). Beyond Boundary Spanning:
Managing External Dependence in Product Development Teams.
Journal of High Technology Management 1(2):119–135.
Ancona, D.G. and Caldwell, D.F. (1992). Bridging the Boundary: External Activity and Performance in Organizational Teams. Administrative Science Quarterly 37(4):634–665.
Athaide, G.A., Meyers, Patricia W. and Wilemon, David L. (1996).
Seller–Buyer Interactions during the Commercialization of Technological Process Innovations. Journal of Product Innovation Management 13(5):406.
Baldwin, C. and Clark, K.B. (2000). Design Rules: The Power of Modularity. Boston: Harvard Business School Press.
Barnett, W. and Freeman, J. (1999). Too Much of a Good Thing?
Product Proliferation and Organizational Failure. Working Paper.
Stanford University.
Bensaou, M. (1999). Portfolios of Buyer–Supplier Relationships. Sloan
Management Review 40(4):35–44.
Bleeker, S.E. (1994). The Virtual Organization. The Futurist March–
April, 9–14.
Brews, P. and Tucci, C.L. (2003). Building Internet Generation Companies: Lessons from the Front Lines of the Old Economy. Academy of Management Executive 17(4):8–22.
Brown, S.L. and Eisenhardt, K.M. (1995). Product Development: Past
Research, Present Findings, and Future Directions. Academy of
Management Review 20(2):343–378.
320
J PROD INNOV MANAG
2005;22:303–321
Brown, S.L. and Eisenhardt, K.M. (1998). Competing on the Edge:
Strategy as Structured Chaos. Boston: Harvard Business School
Press.
Clark, K.B. and Fujimoto, T. (1991). Product Development Performance. Boston: Harvard Business School Press.
Clark, K.B. and Wheelwright, S.C. (1992). Organizing and Leading
‘‘Heavyweight’’ Development Teams. California Management Review 34(3):9–28.
Cooper, R.G. (1985). Selecting Winning New Product Projects: Using
the NewProd System. Journal of Product Innovation Management
2(1):34–44.
Cusumano, M.A. and Nobeoka, K. (1998). Thinking beyond Lean.
New York: Free Press.
Davidow, W.H. and Malone, M.S. (1992). The Virtual Corporation.
New York: Harper Business.
de Figuerido, J.M. and Teece, D.J. (1996). Mitigating Procurement
Hazards in the Context of Innovation. Industrial and Corporate
Change 5(2):537–559.
DeSanctis, G., Staudenmayer, N. and Wong, S.S. (1999). Interdependence in Virtual Organizations. In: Trends in Organizational Behavior.
C. Cooper and D. Rousseau (eds.). New York: Wiley and Sons.
Dhebar, A. (1995). Complementarity, Compatibility, and Product
Change: Breaking with the Past? Journal of Product Innovation
Management 12(2):136–152.
Dyer, J. (1996). Specialized Supplier Networks as a Source of Competitive Advantage: Evidence from the Auto Industry. Strategic
Management Journal 17(4):271–292.
Eisenhardt, K.M. (1989). Building Theories from Case Study Research. Academy of Management Review 14(4):532–550.
Eppinger, S.D., Whitney, D.E., Smith, R.P. and Gebala, D. (1994). A
Model-Based Method for Organizing Tasks in Product Development. Research in Engineering Design 6(1):1–13.
Galbraith, J.R. (1973). Designing Complex Organizations. Reading,
MA: Addison-Wesley Publishing.
Garud, R. and Kumaraswamy, A. (1995). Technological and Organizational Designs for Realizing Economics. Strategic Management
Journal 16(special issue):93–109.
Gawer, A. and Cusumano, M.A. (2002). Platform Leadership: How
Intel, Microsoft, and Cisco Drive Industry Innovation. Boston:
Harvard Business School Press.
Glaser, B. and Strauss, A.L. (1967). The Discovery of Grounded Theory.
Chicago: Aldine.
Griffin, A. (1992). Evaluating QFD’s Use in U.S. Firms as a Process
for Developing Products. Journal of Product Innovation Management 9(3):171–187.
Henderson, R. and Clark, K.B. (1990). Architectural Innovation: The
Reconfiguration of Existing Product Technologies and the Failure
of Established Firms. Administrative Science Quarterly 35(1):
9–30.
Hitt, M.A., Keats, B.W. and DeMarie, S.M. (1998). Navigating in the
New Competitive Landscape: Building Strategic Flexibility and
Competitive Advantage in the 21st Century. Academy of Management Executive 12(4):22–42.
Iansiti, M. (1998). Technology Integration. Boston: Harvard Business
School Press.
Iansiti, M. and Levien, R. (2004). The Keystone Advantage. Boston:
Harvard Business School Press.
N. STAUDENMAYER, M. TRIPSAS, AND C. L. TUCCI
Kahn, K.B. (1996). Interdepartmental Integration: A Definition with
Implications for Product Development Performance. Journal of
Product Innovation Management 13(2):137–151.
Langlois, R.N. and Robinson, P.L. (1992). Networks and Innovation
in a Modular System: Lessons from the Microcomputer and Stereo
Component Industries. Research Policy 21(4):297–313.
Larson, E.W. and Gobeli, D.H. (1988). Organizing for Product Development Projects. Journal of Product Innovation Management
5(3):180–190.
Matutes, C. and Regibeau, P. (1988). Mix and Match: Product Compatibility without Network Externalities. RAND Journal of Economics 19(2):219–234.
McGahan, A.M., Vadasz, L.L. and Yoffie, D.B. (1997). Creating Value and Setting Standards: The Lessons of Consumer Electronics for
Personal Digital Assistants. In: Competing in the Age of Digital
Convergence. D.B. Yoffie (ed.). Boston: Harvard Business School
Press, 227–264.
Methe, D.T., Toyama, R. and Miyabe, J. (1997). Product Development
Strategy and Organizational Learning: A Tale of Two PC Makers.
Journal of Product Innovation Management 14(5):323–336.
Meyers, M. and Lehnerd, D. (1997). The Power of Product Platforms.
New York: Free Press.
Miller, D. (1993). The Architecture of Simplicity. Academy of Management Review 18(1):116–138.
Mintzberg, H. and Van Der Heyden, L. (1999). Organigraphs: Drawing How Companies Really Work. Harvard Business Review
77(5):87–94 (September–October).
Motorola Incorporated (2003). News Releases for Q1 2003. Available
at: http://www.motorola.com/mediacenter/news/detail/0,1958,2349_
1920_23,00.html (accessed March 2003).
Nelson, S.A., Parkinson, M.B. and Papalambros, P.Y. (1999). Multicriteria Optimization in Product Platform Design. Proceedings of
the ASME Design Engineering Technical Conference, Las Vegas
September, 12–16.
O’Mahoney, S. (2005). Non-profit Foundations and Their Role in
Community Software Development. In: Perpsectives on Free Source
and Open Software. F.B. Feller, J. Fitzgerald, S. Hissam, and K.
Lakhani (eds.). Cambridge, MA: MIT Press.
Papalambros, P.Y. (1995). Optimal Design of Mechanical Engineering
Systems. Journal of Mechanical Design 117(4):55–62.
Powell, W.W., Koput, K.W. and Smith-Doerr, L. (1996). Interorganizational Collaboration and the Locus of Innovation: Networks
of Learning in Biotechnology. Administrative Science Quarterly
41(1):116–145.
Roberts, E.B. and Fusfeld, A.R. (1982). Critical Functions: Needed
Roles in the Innovation Process. In: Career Issues in Human Resource
Management. R. Katz (ed.). Englewood Cliffs, NJ: Prentice-Hall.
Rosenkopf, L. and Tushman, M. (1994). On the Co-evolutionary Dynamics of Organizations. In: Evolutionary Dynamics of Organizations. J. Singh and J.A.C. Baum (eds.). New York: Oxford
University Press.
Sanchez, R. and Mahoney, J.T. (1996). Modularity, Flexibility, and
Knowledge Management in Product and Organization Design.
Strategic Management Journal 17(special issue):63–76.
Schilling, M.A. (2000). Toward a General Modular Systems Theory
and Its Application to Interfirm Product Modularity. Academy of
Management Review 25(2):312–334.
Sengupta, S. (1998). Some Approaches to Complementary Product
Strategy. Journal of Product Innovation Management 15(4):352–367.
Imai, K., Ikujiro, N. and Takeuchi, H. (1985). Managing the New
Product Development Process: How Japanese Companies Learn
and Unlearn. In: The Uneasy Alliance: Managing the Productivity–
Technology Dilemma. K.B. Clark, R.H. Hayes and C. Lorenz (eds.).
Boston: Harvard Business School Press, 337–375.
Shapiro, C. and Varian, H.R. (1999). Information Rules. Boston:
Harvard Business School Press.
Simon, H.A. (1962). The Architecture of Complexity. Proceedings of
the American Philosophical Society 106:467–482.
Jemison, D.B. and Sitkin, S.B. (1986). Corporate Acquisitions:
A Process Perspective. Academy of Management Review
11(1):145–163.
Singha, D.K. and Cusumano, M.A. (1991). Complementary Resources
and Cooperative Research: A Model of Research Joint Ventures
among Competitors. Management Science 37(9):1091–1106.
MODULARITY AND PRODUCT DEVELOPMENT
Staudenmayer, N. (1997). Managing Multiple Interdependencies in
Large Scale Softward Development Projects. Unpublished Ph.D.
diss. The Sloan School of Management, Massachusetts Institute of
Technology.
Swink, M.L., Sandvig, J. Christopher and Mabert, Vincent A.
(1996). Customizing Concurrent Engineering Processes: Five
Case Studies. Journal of Product Innovation Management 13(3):
229.
Takeuchi, H. and Nonaka, I. (1986). The New New Product Development Game. Harvard Business Review 64(1):137–146.
Terwiesch, C., Loch, C. and Niederkofler, M. (1998). When Product
Development Performance Makes a Difference: A Statistical Analysis in the Electronics Industry. Journal of Product Innovation Management 15(1):3–15.
Thomke, S., von Hippel, E. and Franke, J. (1998). Modes of Experimentation: An Innovation Process and Competitive Variable.
Research Policy 27(3):315–332.
Thomke, S.H. (1997). The Role of Flexibility in the Development
of New Products: An Empirical Study. Research Policy 26(1):
105–119.
J PROD INNOV MANAG
2005;22:303–321
321
Thompson, J.D. (1967). Organizations in Action. New York: McGraw
Hill.
Tidd, J. (1995). Development of Novel Products through Intraorganizational and Interorganizational Networks: The Case of Home Automation. Journal of Product Innovation Management 12(4):307–322.
Tjosvold, D. (1986). The Dynamics of Interdependence in Organizations. Human Relations 39(6):517–540.
Ulrich, K. and Eppinger, S.D. (2000). Product Design and Development. New York: Irwin McGraw-Hill.
Van de Ven, A.H., Delbecq, A.L. and Koenig, R. (1976). Determinants
of Coordination Modes in Organizations. American Sociological
Review 41(3):322–337.
von Hippel, E. (1986). Lead Users: A Source of Novel Product
Concepts. Management Science 32(7):791–805.
von Hippel, E. (1990). Task Partitioning: An Innovation Process
Variable. Research Policy 19(5):407–418.
Yin, R.K. (1984). Case Study Research. Beverly Hills, CA: Sage.
Yoffie, D.B. (1997). CHESS and Competing in the Age of Digital
Convergence. Boston: Harvard Business School Press.