From Research to Product in Large Corporations (or not)

Most of my career has been in corporate research.

I very deliberately picked corporate research labs that had an academic flair. For instance, publishing papers was part of my job as opposed to something merely tolerated.

I've also had a chance to see how many different labs worked having switched more than a few times: Intel Research, Nokia Research Center, Yahoo Labs, Technicolor Research and the Toyota Research Institute (TRI). All of these were part of large corporations (or a fully owned subsidiary in the case of TRI) and the smallest one was Yahoo with about 20k people. Nokia and Toyota were on the order of several hundred thousand people each (manufacturing takes a lot of people). I have silicon valley companies covered from a couple different eras (Intel and Yahoo) as well as a two European companies (Nokia and Technicolor) and a Japanese one. Many of these companies are actually quite old and well established having successfully changed business models in the past (Nokia - 1865, Technicolor - 1915, and Toyota - 1937). While they are all in different industries working of different products, they all showed similar challenges in converting research into new products.

One way Nokia and Technicolor both capitalized on research was through IP licensing. Here the business model was basically do research and patent a bunch of stuff in some specific verticals (mobile telephony and media codecs respectively). And more specifically, portfolio of patents on a specific technology would be created. For example, when I was at Technicolor, there was a push for technologies related to HDR TVs.

With the patent portfolios in hand, there was then significant effort to get the patent encumbered technologies into industry standards (3G or MP3) and from there a licensing business is developed. Anyone use the technology covered in the standard would also pay a license fee. Nokia and Technicolor both at their peek were making $500m Euro per year on patent licensing. That covered the cost of research and then some. However patents expire and so does that revenue source. (The other main reason companies develop patent portfolios is for defensive purposes - they want large stacks of patents, portfolios, in key areas so if there was ever a lawsuit, they could counter-sue. Basically the legal equivalent of mutually assured destruction).

Another potential benefit of research isn't the research itself, but publicity. Often corporate PR departments love to showcase research results - highlighting how innovate the company is. Just like other marketing activities, there can be a real tangible benefit to the business. I think in the case of research, this aspect is often not directly considered as an avenue for impact. (And research budgets are WAY smaller than marketing budgets).

Probably what most people would think of in commercializing research isn't the IP or publicity stories, but instead impacting the products of the company in some more direct way. For example a prototype of an interaction technique is developed, studied, and eventually makes it into the end consumer product. This can happen, but in my experience has been rare - I think for a couple of reasons.

In the research labs I've been in, the research has been intentionally decoupled from product. There are a few good reasons to do this. One is if research is too close to the product group then it is rather easy to sucked into product development. The product side usually has a bunch of fires, and researchers are smart and want to help, so they might start firefighting. However those fires are for today whereas research should be looking more into the future, and at more fundamental problems and opportunities. The product sides is also a deep gravity well and one might not escape once pulled in!

Another reason to decouple from the day to day product operations is to gain a different perspective. The product team is looking at the next sprint, and maybe a backlog of tickets. Research needs to look beyond that fray. At Intel Research, the charter for awhile was off roadmap research. It took me a while, but eventually I realized the engineers could plan out in a straight line basically forever. Partly this was the product life cycles (eg silicone getting locked down 4 years out, or a 4 year car development cycle). But it is also because if something is on the critical path, the engineers would rise to the occasion and overcome the challenges. What was harder for them to do was look off to the side - where the roadmap was not, or see past discontinuities coming in the future (eg. Christensen's Disruptions).

Another challenge with research is if it really is research, we don't know the answer. We might have some hypotheses, but we are intentionally going off into the unknown. Part of this is the connection to academia and publishing. We are intending to create new knowledge for humanity. The hope is that the company can also capitalize on that knowledge. I think most research labs understand that not all research works out, and I think similarly the parent org understands that risk. To use a baseball analogy, it is ok to strike out occasionally. Just not all of the time! But this uncertainty can make planning around research results difficult, especially for planning heavy orgs with long time horizons. The window for slipping research results into a product plan is often rather deceptive. Things that look like they should be malleable from a research perspective, things the research results could help with, might have been locked down years ago. So the real opportunity is for a product N years out.

So there is uncertainty as to if the research works at all, but that is rather well known. What seems to be less well understood is what problems the research is targeting, and how those impact the business units and products. There are a few buckets here. At a high level, we can think about applying research directly to the problems a business unit has. At the other end is targeting research where the business unit is not. This can take a lot of different flavors, trying to take the technology of the company into a new area, trying to find the next product, conducting research in areas key competitors are working in, but the company is not. Most of my research career has been in this second category which likely is a contributing factor for why it has been difficult to transfer research results into products in these companies. However, let's hold off on that case for a moment and focus on the "easier" one where the research is directly aligned with the business.

There are a variety of factors here to consider that make things easier or harder. One is where is the research question coming from? Is it directly from the business unit? Or is it coming from somewhere else? Maybe it's coming from customers? Or maybe the question has been generated by the research team itself about the product. Often business units, and the engineers working on the products, don't really know what is or isn't a research question. Likewise they often have little idea of what is in or out of scope in a research project, or even what possible outcomes there might be. So it is quite likely they might have a question, but is it a Research (capital R) question where we're also going to contribute to the knowledge of humanity? I've had some colleagues that are actually very good at taking the questions they're given, answering them, but also taking the opportunity to ask a bigger more fundamental question. The business unit might not care about the deeper work, but they get their answer, and there is a contribution on the academic publishing side as well.

I think a similar strategy (on the technical side) is being able to check code directly into a product code base. Often the product groups are resourced constrained, so if the researchers themselves create the first version (and deal with all of the associated integration issues), there are that many fewer potential blockers for getting the research out the door.

The rest of the sources of research questions can unfortunately face much more resistance. Questions from customers, ones generated by the researchers, etc. might seem relevant on the surface, for example they're about a specific product. Or maybe in talking with the business unit, a problem is identified, but through some preliminary work you realize their problem is a symptom and there is opportunity to solve it at a deeper level. In cases, "thar be dragons". The challenges here are not ones of doing the research directly. Instead they are business challenges. The business is setup to conduct it's work in a certain way. It has things it is optimizing for, well entrenched processes and work flows, all of which have been working well to get the business to where it is today (eg it is successful). The business also has its own way of understanding the problem it is trying to solve for the customer and how it solves it. If a research result is going to land in that business, all of these issues need to be taken into account in some way. It is unlikely that the business will change given any specific research result. So those results must slot into existing practices (even if it is those practices themselves that are somehow problematic and would need to change). Also, researchers are very good at selling their research (eg writing papers and grants, or in the corporate world pitching research projects). So that means they are likely able to tell good stories about why the research matters, and the business unit themselves can agree. But if those research results are not in a form the business can digest, then more often than not, the transfer of the research results into products is basically a non-starter. Or you somehow need to change the business unit from the outside first, and only once that change is in place can the results be incorporated. There might be research here - but it is not technical. It is all about people and business practices and how to change them. Without that, the technology, even if it is well aligned in other ways, will likely die.

So that's the good case. where the research program looks like it is aligned with the business. What about when it intentionally is not? What about the cases where the research is there to find what's next? I've done a lot of this work in various ways, some with grand ambitions, others more modest. But what they all share is the intent (from management above) to change the business - to go off in a different direction. Or to create new products for the company, and that is often in the face of existential threats (eg the iPhone when I was at Nokia) where there are a huge amount of resources being deployed on the new thing. We can do the research, get good results, get management excited, etc. But this work could also heading nowhere fast. It is a similar problem as above where you might be doing research related to a product but in a way the business unit doesn't understand. Here it might be trying to create something new for an existing business unit, or there may be no business unit at all. In these cases how can the research make it into products? While resources are put into the research and technology development, there is often extremely little consideration into how that product will be sold. Back to Nokia, we built some new technology that wasn't directly phone related. But the smartphone business unit's customer was actually AT&T. If AT&T didn't want it, there was no way they could sell it. The whole value chain needs to be considered, not just a piece of tech. I think this is a solvable problem, as new technology is stood up, the associated business resources (marketing, sales, etc) also need to be stood up. And these likely can't be taken from an existing business since you would now be giving them two different jobs (requiring different skills, strategies, etc).

So circling back to the original question, how can we transition research into products in a big corporation? Given all of the above, one solution is in selecting research questions to address. In addition to picking research topics of interest in the academic community and the skills and interests of the researchers themselves, it is worth thinking about and being deliberate about how different potential research projects might fit into the landscape of current corporate processes. That (mostly) is within the scope of the researchers themselves - what projects to invest in. A more ambitious option would be to work with management (likely executives) to figure out if or how the business might need to be restructured given the asks coming from the business. This likely involves a lot of work beyond the research itself, and likely is rather difficult (going back to Christensen's theories), but could be fruitful if navigated effectively.