Technology Transfer:
So Much Research, So Few Good Products

Organizers:
Ellen A. Isaacs and John C. Tang
SunSoft, Inc.
2550 Garcia Ave.
Mountain View, CA 94043-1100
USA
ellen.isaacs@sun.com, +1 415 336-1167
john.tang@sun.com, +1 415 336-1636

Panelists:
Jim Foley, Georgia Institute of Technology
Jeff Johnson, Sun Microsystems
Allan Kuchinsky, Hewlett Packard Labs
Jean Scholtz, Intel Corporation

Discussant:
John Bennett, independent consultant

PANEL TOPIC

Since the CHI community involves both researchers and practitioners, we often struggle with the issue of technology transfer. The CHI conference features many innovative research ideas and interesting product designs, but there have been disappointingly few cases in which products were based on research projects. Although many companies have tried to address this problem on their own, the CHI conference offers a unique opportunity to bring together people from different settings to explore common obstacles to technology transfer and to share ideas for overcoming those barriers.

This panel will cover the following range of perspectives:

The Prototype Perspective. The primary goal of research or advanced development in a company is to build prototypes that test new ideas, which can eventually be transferred to development groups for productization.

The Information Transfer Perspective. The main goal of research should be to transfer information of many kinds (e.g., the resolution of basic questions that are impeding development work, practical experience with a platform's ability to support future applications, explanations of why a new product direction is technically unfeasible).

The Management Perspective. Managers of industrial research need to strike a balance between (1) providing a climate for innovation and (2) justifying the research investment from a business perspective.

The Academic Perspective. Transferring technology from academia to industry has its own challenges. Those in universities must develop alliances with industry that mutually benefit the academic institution and the commercial enterprise.

POSITION STATEMENTS

Jean Scholtz: Technology Transfer Through Prototypes

Advanced development groups are most effective if they develop prototypes that can be either developed into products or used to inspire product ideas within a company. At Intel, several labs are the driving force behind the technologies and software products. The labs embody their ideas in prototypes demonstrated to all employees in "open houses," which are a source of technology transfer for all concerned: the labs show their ideas to the attendees and the attendees offer suggestions and pointers to other work of interest. Prototypes considered good ideas by management are used as a basis for a product and groups are formed to develop and market them. The basic components for the ProShare Personal Conferencing Product started as prototypes in one of the labs. Interestingly, while early versions of ProShare were being developed, the product group conceived of an idea and transferred it back to the lab to research for future versions of ProShare.

One problem that occurs in this type of technology transfer involves the expectations of what is to be transferred. Is transfer of the concept sufficient or should there be an implementation? What constitutes proof of concept? Another problem is that the prototypes are not based on user requirements and yet in many instances they are used as the basis for the product. The implication is that a body of user requirements should be available and used to focus the efforts of advanced development groups.

In several other instances, the product group consisted of the same group that had originally developed the prototype. In these cases, the technology is in place but the groups must learn how to develop and market products. This is a difficult task and requires different engineering skills from those needed in an advanced lab setting.

Jeff Johnson: Technology Transfer as Information Transfer

Many people use the term "R&D" as if it were one word, referring to one thing. It is not. It is two words, and refers to two activities: doing science and doing engineering, respectively. What distinguishes the two is their product: that of research is information; that of development is artifacts. In this industry, few companies that have "R&D" organizations actually do "R" most do "D" only.

The conventional model of research vs. development, which uses time-to-product as its primary categorization criterion, is inaccurate and leads to misguided policy. A more accurate and useful model does not distinguish between research and development primarily in terms of time ranges. It recognizes that research can have an impact within time-spans usually reserved for development if researchers and developers are well-connected. It recognizes that research can be highly "applied" and valuable to the company even though it may not result in prototypes or other tangible artifacts. It recognizes that research and development require somewhat different skills and personalities, such that researchers and developers are not freely interchangeable.

Given this framework, a variety of technology transfer strategies are possible. The main distinction is between "pushed" and "pulled" approaches to achieving technology transfer from research to development. The former is driven mainly by researcher interest, whereas the latter by developer need. Neither the "pushed" nor the "pulled" approach alone yields satisfactory technology transfer. The best strategy balances "pushed" and "pulled" approaches.

Allan Kuchinsky: Managing Technology Transfer

As a research project manager at Hewlett Packard Laboratories, I've been responsible for the linkages between our research agenda and its various stakeholders: product divisions, upper management, external partners, and, increasingly, external customer groups.

HP Labs has traditionally provided technology breakthroughs that differentiated HP's product lines. In recent years, there has been increasing emphasis on HP Labs' role in helping the company start new businesses. Moreover, HP's product divisions operate fairly autonomously, each with its own set of customers and profit/loss responsibilities. This makes it a challenge for the company to make strategic design decisions across divisions that achieve economies of scale and scope.

To this end, my group has been intimately involved in establishing one such new business. This has had a number of implications on the way we conduct applied research:

We have had a strong "pull" for our contributions and expertise from the product divisions and from external customers. The pull from the customer has transformed product divisions into eager technology transfer partners.
We are more coupled into the day-to-day activities of the product divisions than we were previously, and more exposed to uncertainties in the marketplace. Innovation is more constrained.
We have had to broaden our notions of how to do research, e.g., combining to a much greater extent market research and economic models with our technical efforts.
Though we have stronger expertise than our division partners in certain technical areas, there are many situations in which we learn as much from them as they do from us. This is both humbling and exhilarating.

Jim Foley: Technology Transfer from Academia to Industry

In my own industry-sponsored research work and in the corporate relationships which have developed within our GVU Center's Industrial Affiliates Program, we apply several guiding principles that have generally led to successful technology transfers from university to industry:

Tech transfer is a contact sport. People, not papers and reports, transfer technology.
Tech transfer is a grass roots effort. It requires buy-in and active participation from those who are in the trenches: the faculty and graduate students at the universities and the engineers and programmers in industry.
Tech transfer requires support from the top.
Tech transfer requires a reward structure. It is not something that gets done in your spare time.
Tech transfer is based on relationships that must be built and nurtured over time, requiring multi-year project relationships, not simply a one-year "feel good" funding agreement.
Tech transfer requires understanding by the professors and graduate students of the sponsoring company's strategies, and by the company of what a university research lab can and can not do.
Industry funding must at least in part come from a separate corporate source. There is risk in funding a university project, and many mangers are reluctant to take the risk. Matching funds from the corporate level ameliorates the risk.

John Bennett: Building Relationships

All of the diverse technology transfer situations described by panelists highlight the importance of the relationships among the people offering and the people accepting the proposed technology. The following framework for partnership reminds us of distinctions important for developing and maintaining essential personal relationships.

Create a vision of the possible results. A shared vision can energize the parties to "stay the course" through the setbacks and time that successful technology transfer requires.
Build mutual trust and respect. Create, reinforce, and maintain trust throughout the project. This can be especially challenging for HCI technology transfer because researchers tend to have a long-term perspective while developers have short-term, time-to-market concerns.
Acknowledge distinctive competence. Foster a mutual recognition of skills and abilities needed for the success of the technology transfer project.
Share knowledge. Within the purpose of the project, be willing to share organizational and technical know-how.
Attend to mutual benefit. Create conversations that check on the current status of perceived benefits. They may have changed for one or more of the participants since the original creation of the shared vision.

Further information

A Web page has been set up to document this panel and to collect case studies provided by the community. See: http://www.acm.org/eccc/projects/techtransfer.html.

Technology Transfer: So Much Research, So Few Good Products