Putting It Together: How to Succeed in Distributed Product Development
Handing off various parts of your innovation process can work — if you are willing to spend the time upfront and follow these suggestions.
Image courtesy of Flickr user horiavarlan.
Companies have traditionally been protective of the innovation activities they use in product and process development, seeing the activities as part of their crown jewels. That thinking, however, is starting to change. The increase in outsourcing, offshoring and alliance building has resulted in innovation efforts that often require the orchestration of multiple organizations separated by cultural, geographic and legal boundaries.1 At one extreme are centralized arrangements, with a clear lead organization and subsidiary “supplier” organizations. At the other are innovation efforts performed by decentralized “open-source” networks.2 In between is the realm of outsourcing and offshoring — the key building blocks in a trend called distributed product development or DPD, whose success factors are still not widely understood.
This article is an attempt to remedy that. Outsourcing complex product development work subjects companies to significant uncertainty. Companies can make perfectly reasonable decisions and still find themselves needing to make expensive changes, ranging into the millions or even billions of dollars. Our contention is that, by anticipating some of these changes, managers can reduce risk and, ultimately, cost.
We start by explaining why some seemingly well-conceived DPD strategies have failed to deliver the expected financial or performance benefits — information that may be useful to senior executives starting to put their faith in DPD and invest in it.3 Our central focus, however, is providing guidance to middle managers — who, after all, must make DPD work. Our recommendations have been developed over more than a decade’s worth of research and consulting.
The Trouble That Arises Around “Boundaries” — Two Cautionary Tales
We will start by acknowledging that DPD is no panacea. Two illustrations make the point. Example one: A multibillion-dollar computer server company concluded that it could exploit the benefits of reusability by developing one subassembly that it could use in a number of products. That was certainly feasible. However, the working prototypes the manufacturer developed demonstrated significant unwanted electromagnetic, mechanical and thermal interactions, which degraded the performance of the derivative products.
The Leading Question
If you work with others to develop a new product, how should you manage the process?
Findings
- The flippant answer — “very carefully” — is also the right one.
References (16)
1. S.D. Eppinger and A.R. Chitkara, “The New Practice for Global Product Development,” MIT Sloan Management Review 47, no. 4 (summer 2006): 21-30; S. Nambisan and M. Sawhney, “A Buyer’s Guide to the Innovation Bazaar,” Harvard Business Review 85, no. 6 (June 2007): 109-118; and B. Jaruzelski and K. Dehoff, “Beyond Borders: The Global Innovation 1000” Strategy + Business 53, (winter 2008): 52-68.
2. E.G. Anderson Jr., A. Davis-Blake, S. Erzurumlu, N.R. Joglekar and G.G. Parker, “The Effects of Outsourcing, Offshoring, and Distributed Product Development Organization on Coordinating the NPD Process,” in “Handbook of New Product Development Management,” eds. C. Loch and S. Kavadias (Burlington, Massachusetts: Elsevier, 2007), 259-290; and E. von Hippel, “Democratizing Innovation” (Cambridge, Massachusetts: MIT Press, 2005).
