{"id":4425,"date":"2010-08-13T07:31:40","date_gmt":"2010-08-13T14:31:40","guid":{"rendered":"http:\/\/palblog.fxpal.com\/?p=4425"},"modified":"2010-08-12T21:39:00","modified_gmt":"2010-08-13T04:39:00","slug":"research-as-product","status":"publish","type":"post","link":"https:\/\/blog.fxpal.net\/?p=4425","title":{"rendered":"Research as product"},"content":{"rendered":"

Greg Linden wrote<\/a> on the CACM Blog<\/a> about a model of research that strives to integrate researchers into product teams with the goal of helping work out thorny problems and building up social networks in the process. He also advocated that researchers should have time (something like 20%) that they can devote to non-product pursuits. This is certainly a workable model for research, but perhaps not the only viable one.<\/p>\n

The premise that a researcher contributes more to the bottom line when working on near-term problems faced by a product team is based on the primacy of short-term ROI. We are paying salaries and overhead for all these guys; let’s make sure they contribute.<\/p>\n

But it’s not clear to me that this model of research applies broadly. It may be true for some systems researchers and people focused on algorithms, but the marginal utility of a HCI researcher<\/em> spending 80% of his or her time with a product team that’s deciding on the exact shade of blue to color its links is pretty low. I am not saying that no involvement is a good policy, but that there are many factors, including the field of expertise, that will determine the degree and manner of effective researcher engagement with product teams.<\/p>\n

In addition, in practice it’s hard to enforce the 80-20 division because product cylces have time-sensitive demands, whereas research can typically wait another week. But effective research requires a certain critical mass of attention that a product release cycle may not readily accommodate.<\/p>\n

Furthermore, there is a fundamental difference in the structure of research vs. product teams: whereas product-building strives to be focused, predictable, and consistent, research processes should be much more exploratory, diverse, and prone to failure. These characteristics of the process will affect the personalities of the people who are attracted to them: I’ve seen cases where contract developers hated working with researchers because there was no clear spec to which to build (and ideas shifted weekly); I’ve seen cases where researchers who were also skilled coders lead miserable existences in heavily-structured development teams; and of course there were people who’ve been successful in both kinds of endeavors. But one size doesn’t fit all: it doesn’t fit all people, and it doesn’t fit all organizations.<\/p>\n

The perennial challenge for research organizations is relevance, which really means establishing metrics by which the senior management of a corporation judges their contributions. It is a mistake, in my opinion, to assume that the short-term ROI is the only defensible metric for assessing the utility of researchers to a technology firm. A research organization can also affect the longer-term technological trajectory of the parent corporation by creating a robust patent porfolio, by exploring opportunities tangential to the activities of product teams, by increasing the public reputation of the parent corporation, and, occasionally, by inventing something truly revolutionary. (Xerox, for example, may have fumbled away the graphical user interface invented at PARC, but it did make a bundle on laser printing.)<\/p>\n

There are, of course, many challenges to technology transfer, and the most effective strategy often involves the (temporary) transfer of people, in the manner that Greg advocates. But we should recognize the merits of both short-term integration and longer-term segregation of these different work styles to achieve their different goals. Monoculture isn’t healthy in crops, and it’s not good for the long-term viability of corporations, either.<\/p>\n","protected":false},"excerpt":{"rendered":"

Greg Linden wrote on the CACM Blog about a model of research that strives to integrate researchers into product teams with the goal of helping work out thorny problems and building up social networks in the process. He also advocated that researchers should have time (something like 20%) that they can devote to non-product pursuits. […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts\/4425"}],"collection":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4425"}],"version-history":[{"count":2,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts\/4425\/revisions"}],"predecessor-version":[{"id":4427,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts\/4425\/revisions\/4427"}],"wp:attachment":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4425"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4425"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4425"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}