Maher Hakim (Managing Director at Qatar Science & Technology Park)
There are many differences between the three types of organizations involved in the above value chain of "computing-research to business-solutions", but for the sake of brevity, I will only point out two crucial differences: 1) the incentives and motivation of the institutions' talent force, and 2) the culture of these institutions.
In research labs, the main human drivers are the scientists and researchers who typically pursue discoveries that will potentially have a wide range of applications, users and scenarios. For example, language translation research can be used in a consumer travel app which helps you order food at a restaurant on your Thailand vacation, or provides real-time translation for a foreign patient in a hospital's emergency room. Research grants tend to flow to ideas that have many potential uses. Meanwhile, a researcher's prestige and reputation is directly linked to his/her ability to "abstract" patterns that occur in different contexts - natural or otherwise - so that one investigation effort could potentially lead to solutions to many challenges and problems.
But product managers - the unsung heroes of products organizations - think and behave very differently. A product manager's main goal is to create the right product for a particular customer segment within a specific market. Product managers wrestle with trade-offs to find the right mix of technology, features, usability, marketing message, packaging, price, etc. They care less about the wider applicability of the core technology underlying their product, and more about how to make this technology ideal for specific customers in specific scenarios. These specific customers and scenarios define the product organization and the market they serve. You would expect a company like TripAdvisor to launch a "travel translation app" targeting consumer travelers, but you would never expect it to invest in hiring sales teams to go after hospitals to sell its "translation technology solutions" for emergency rooms. While the underlying technology (and the language translation research behind it) maybe the same, the products and companies you build to go after each opportunity are markedly different.
And on the far end of the spectrum, when business customers (hospitals, retailers, banks, universities, etc.) look for business software solutions, they care less about products and more about "integrated solutions". When a new hospital is setting up its IT infrastructure, the CIO looks for vendors who will help him/her source, implement and deploy the various products that he/she needs to run the hospital. The CIO will likely turn to a services organization like Accenture or IBM services to assist him/her in conducting needs-based analysis, selecting the right product vendors, and putting together a plan for procuring, implementing, deploying and staff-training. And who would be the person most qualified to help the CIO in this effort? Not a scientist/researcher, not a product manager, but an "industry expert" - an ex-hospital-CIO turned "director of services" at an IT professional services organization or has become a "partner" running the healthcare practice at a consulting firm.
Of course there are exceptions. Many product companies have successfully built services practices (IBM, Oracle, etc.). But their practices run as independent business units - with their own missions, incentive structures, hiring processes, success metrics, etc. Also, software product startups do typically engage with service-type activities at their clients' sites. But they do so because they have to, not because they want to. They need to learn more about how their product fits within their clients' environments so they can successfully draw a line in their offering between "products" and "services". Moreover, because they are still small, young and unproven in the market place, finding services organizations that are willing and ready to make the investment required to support their product is not an easy task.