Another Perspective on Build vs. Buy

In another blog entry I compared and contrasted Henry Chesbrough’s writings on build vs. buy with Clayton Christensen’s. I would now like to mix in Eric von Hippel’s writings to see how it affects thinking on whether to build or buy, particularly at the Fuzzy Front End of innovation.

In my last entry I concluded that the best practice is to buy so you can build. Buying is not going to be enough, usually, to bring a product for your customer to market. If someone had already finished building what you want to build for your customer, you’re not going to need any R&D, it’s a financial or operational play. A more likely case is you’ve still got to do some development to solve your customer’s unique problem. Before re-inventing the wheel, go scout for available technology. If you find some then gain control of it by acquiring the technology’s owner or the assets. Don’t enter into a vendor relationship with the source because then your product developers won’t have the control they need.

But then I got to thinking about Eric von Hippel’s writings on the subject of who should do the innovating. In his paper on “Sticky Information and the Locus of problem solving”, von Hippel has this very logical argument:

“Suppose that to solve a particular problem, two units of equally sticky information are required, one from a user and one from a manufacturer. In that case, there will be an equal incentive operating to unstick either of these units of information in order to reduce the cost of transfer…But now suppose that there is reason to expect that one of the units of information, say the manufacturer’s, will be a candidate for transfer n times in the future, while the user’s unit of information will be of interest to problem solvers only once…In that case, the total incentive to unstick the manufacturer’s information across the entire series of user problems is n times higher than the incentive for the individual user to unstick its problem-related information. And, as an important consequence, it is reasonable that the locus of problem-solving activity will tend to shift to the locus of the less frequently called-upon information--in the case of our example, to the user.” (Eric
von Hippel)

This whole discussion could get confusing if I’m not clear about the roles of the different parties. I have been referring to a buying party in my own discussion above. The buying party in this case is the user who happens to be developing a product for its own customer. The buying party is considering a purchase of technology from a supplying party, the manufacturer in von Hippel’s terminology. The reason the discussion could get confusing is that there is an innovation supply chain underpinning all of this and at any point in that chain, the locus of innovation might need to shift depending on how sticky the information is. But let me stick to a simple discussion of a supplying organization and a buying organization (that happens to be building a product from another user, but that’s outside the scope).

Getting back to the passage from von Hippel…in some ways Clayton Christensen expressed a similar notion in talking about the need for an interdependent architecture. As I explained in my last posting, I think Christensen was talking about the need for the innovator to have the control and freedom to change the system to suit his needs. That’s the same as von Hippel’s notion of the locus of problem-solving needing to shift to the place where the freedom to adapt the system is greatest.

So far this additional observation is leading me to the same conclusion as in my last posting. If an innovator needs to build something, he is better off gaining control of a piece of technology to make it adapt to his needs. That reduces it from two parties to one, so no locus-shifting problem.

But some of von Hippel’s more recent work suggests another way for technology suppliers to deal with the shifting nature of the locus of innovation. If the technology provider can develop a Tool Kit that gives the innovator the freedom it needs to build what it wants, then perhaps the innovator’s company need not acquire the supplying firm. Acquisition is a way to handle it, as discussed above, but if the supplying party can convince the innovator that their needs will be met through the flexibility of the Tool Kit, perhaps it is possible to develop the interdependent architecture while still relying on an outside source of technology.

Well in conclusion, after looking at the work of Henry Chesbrough, Eric von Hippel, and Clayton Christensen, I am inclined to give the following advice to any innovator considering the build vs. buy question. First, if you encounter a problem in your effort to build a product for your customer that will need an innovative solution, your knee-jerk reaction should be “don’t reinvent the wheel”. That means following Chesbrough’s Open Innovation advice and looking externally. Second, if you don’t find what you want then look instead for components or look for earlier-stage assets such as research findings that you can turn into technology for your product. Third, make sure to gain the control you’ll need to adapt the supplied technology to do what you’ll need it to do. Christensen’s writing suggests making a company acquisition. But von Hippel teaches us to look for Tool Kits that may provide the adaptability innovators need without going to the extreme of making an acquisition.