For a Nimbler, More Stable Alliance, Share Less

futurelab default header

by: John Caddell

An article in the current Journal of Product Innovation Management starts out with this rather bland statement:

There is wide agreement in analyses of strategic alliances that, regardless of the purpose of the alliance, members of the partner organizations should engage in intensive mutual learning to make the alliance a success.

Sounds good, but so what? Well, the authors go on to show that perhaps this needn't be the case–that a strong product development alliance can exist with much less sharing than previously thought. "Learning to Reduce Interorganization Learning: An Analysis of Structural Product Innovation in Strategic Alliances" (link – $$) by Roman Grunwald of Siemens AG and Alfred Keiser of Mannheim University states that deep person-to-person learning is not a critical success factor if other elements are used instead.

And why would that be helpful? For one, person-to-person learning is time-consuming and expensive. For another, it can destabilize a partnership by teaching one partner enough about the other's business to tempt it to move into the other's turf. This last area is one that I've seen first-hand doom several partnerships, and in thinking about Grunwald's and Keiser's paper, avoiding this could be a significant benefit to a partner strategy.
The authors point out four areas where "Transactive Organizational Learning"–that is, using the knowledge of two companies without sharing it person-to-person–can be employed:

  1. Modularization – meaning creating a more distributed architecture for partner innovation. Decomposing the tasks and allowing for more specialization among the partners.
  2. Storing Knowledge in Artifacts – a partner's contribution to an alliance can be a piece of software or hardware. The other partner doesn't need to know how the artifact works in detail–it needs only to know that it fulfills the requirements and how to connect with it.
  3. The Rolodex – the authors call it "locating knowledge not available within the team." It means being able to access information that's not directly known by the core product team, whether from alliance partners, customers or others (an important corollary to modularization).
  4. Prototyping – pulling the above together, creating iterative models of the product, identifying those areas that need more intense collaboration, and focusing learning on those areas only.

If alliances can work without "opening the kimono," to use a term, then the partners can worry less about whether one partner is going to use its learning to take business away from the other. (And spend less on product development and get products to market faster.)

Original Post: