Getting ahead of tomorrow's problems: Got research?

With all the talk about innovation these days in product management circles, I'm consistently surprised that I don't hear much about the role of research in driving product innovation. As a matter of fact, research is overlooked almost completely in the few supposedly comprehensive product management frameworks I've seen. When I say research, I'm primarily referring to research organizations (departments) often found at large, mature companies. 

Those that have worked in smaller companies may not be familiar with bigger shop research organizations. Many medium to large technology companies and virtually all "mega-vendors", e.g., Microsoft, IBM, have a dedicated organization whose job it is to uncover problems that may not have even surfaced yet and search for likely solutions to those problems. I haven't seen research indicating at what size a company typically creates a specialized research organization, but I would say it becomes more common North of a few thousand employees.

As we product managers often find solving today's problems more than full-time work, the potential synergy between research and product development should be fairly obvious. In an ideal world, research could anticipate the impact of key trends, both technological and otherwise, and explore how they could be addressed with technology, enabling breakthrough customer solutions that are developed and delivered by product groups. However, with a notable exception or two, I've rarely observed these two organizations working together in a way that I though was highly effective, i.e., in a way that generated significant revenue broadly from product innovation.

The disconnect between research and product development had various root causes in different organization (perhaps fodder for a future post), but there were common traits I saw in these sub-optimized relationships:

1. Lack of mutual understanding

Even though both product managers (the people who should be accountable for product development) and researchers are essentially problem solvers, the end products of their efforts and the way they approach their work are radically different. Each have complex, domain-centric concepts, terminology and approaches that often seem to be completely lost on the other, even though there are a host of analogous goals and processes between them.

2. Motivations not aligned

In an earlier post, I described the concept of business motivation, i.e., vision, mission, goals, objectives. In my experience, research has little or at best anecdotal knowledge of product teams' vision and objectives. Often, product teams, heads-down trying to ship software, have little or no idea about research's mission or their investments.

3. Ad hoc engagement model

In my experience, very few product teams engage with research as a matter of standard practice. While one can easily make the argument that engaging with engineering and marketing has much higher priority short-term, completely overlooking research strikes me as a potentially wasted opportunity.

Perhaps the most intuitive (although admittedly oversimplified) way to contrast research and PM is to consider their typical time horizons: while research is focused on solving tomorrow's problems, PMs and their product development teams, in practice, spend most of their time solving today's. I know progressive PMs may push back on this statement, rightly claiming that PMs have an obligation to anticipate what their customers will need a few years in the future. However, the benefit of having a group of very bright people focused on problems and possible solutions that likely lie beyond the last milestone on their product roadmap seems self-evident.

Bringing research and product development into alignment is not a trivial exercise but is definitely possible and can be highly profitable. In a future post, I'll suggest they key ingredients to getting these groups working together to bring breakthrough solutions to your customers.

Has research benefited your customers? If not, why not?

Next post: The brilliance of demonstrating benefits over features