I was recently asked about how you would go about developing a process for determining and commercializing parallel uses of technology. That is, as a technology vendor you know that there are other uses for your products and technologies, but how do you commercially explore and exploit these alternative uses in a systematic way? My thoughts in a minute, but first a few stories…

Over the past few years, I have heard of some interesting uses for CRM technology. There was the college-age “playa” using the personal edition of a commercial grade CRM system as modern black book (complete with pipeline reports, alerts and escalations), the bunch of knee-breakers using CRM to track their extortion victims and the house of ill repute that used the one-to-many association between the account and contact entities to, ahem, track who serviced whom… But my all time favorite example, and the one that has relevance beyond the novelty value of the above stories, was the use of CRM to track black economic empowerment credits for businesses in South Africa. This is a very localized issue that would be beyond the scope of most software vendor’s localization and commercial plans. To address the market demands, a South African Value Added Reseller (VAR) had one of two choices: 1) develop the solution from scratch recreating much of the common functionality or 2) use the CRM system as a platform to develop their own solution. They choose option two and ultimately developed a solution that ended up looking much different than the CRM package that was originally shipped by the vendor.

To identify and exploit new uses of your technology, I believe that an organization needs to have several critical components in place. First, there needs to be a “sensing” mechanism that is attuned to the customer’s wants, needs and challenges. In some organizations, this responsibility sits with the product management teams, in others it is is a business development function. Regardless of where it sits, to be successful, the product and business development teams need to be in the field interacting with real live customers — and not just the top customers or the ones that scream the loudest. Even if the challenge is outside the scope of your current product capabilities, understanding the nature of the issue will be invaluable in determining if your technology could work through modifications or customizations. This information needs to be captured and organized in such a way that it can be shared and re-used throughout the organization. Understanding the challenges in broad terms will help you to understand if the problem is specific to an organization, a functional domain, an industry or a specific geography. With this understanding, you can begin to look for parallel problems. For example, in the case above, are there other countries with similar economic policies that would dictate a similar use of your technology? Do other industries have similar processes, routes to market or challenges? This requires a periodic co-mingling of domain expertise and specialisms from within and outside the business.

Another component piece is the development of an adaptable platform. Plan for change, not capabilities; rather than developing specific functionality, organizations should instead focus on flexible and modular architectures. There is no sense having a robust sensing function if you have to redesign you product for each new opportunity. Lastly, I think that many organizations need to revisit their partnering philosophy. How many strategic alliances ever achieve the value hinted at in the press release? The reality is that you are not going to get unfettered access to your partner’s customer base and the economics of most sales and marketing operations makes it unlikely that your products and services are going to be more lucrative to sell than your partner’s core products. Rather than looking at alliances as a new route to market, partnering should be used to rapidly augment your development, production and marketing capabilities to pursue these new opportunities, leaving your core team to focus on platform development and core capabilities.

  • Twitter
  • Facebook
  • FriendFeed
  • Delicious
  • Digg
  • Share/Bookmark