Development of Open Product Platforms

On Monday, Karl Long over at Experience Curve talked about “2.0 Ideas Executed with a 1.0 Mindset“. As an example, he cited the new Nike/Apple appliance that converts your iPod into an accelerometer. In a nutshell, he thought that the ‘black-boxing’ of the application was a lost opportunity for both companies. Rather than producing a “polished, monolithic” product, “real power could be unleashed with a couple of API’s … to use [the data] in other ways”. With this particular example, there is a fine line between providing an open application and addressing security/privacy concerns (recall the University of Washington student that hacked the device, igniting stalker fears). However, clearly (and sensibly) Apple developed the iPod in such a way that it could easily extend its capabilities and functionality — at this point, they’ve regrettably chosen not to make the platform “open” to external developers.

This example does highlight some of the challenges that companies are going to have to face as they adopt a “platform” approach to product development. First, you need to figure out how much of the platform to expose? In his new book, Wikinomics, Don Tapscott writes:

Conventional wisdom says that being open is rather like inviting your competitor into your home only to have them steal your lunch. But in an economy where innovation is fast, fluid and distributed, conventional wisdom is being challenged.

Winning in a world of cocreation and combinatorial innovation is all about building a loyal base of innovators that make your ecosystem stronger, more dynamic and more expedient than the ecosystems of your competitors in creating new value for customers. To achieve this, your organization — regardless of the sector or line of business — needs to identify and open up platforms to enable mass collaboration.

This is all fine and well, but if you open your platform up too much, you may loose control of it. As a business, you need to decide what to keep as proprietary and what to open up. In the case of Apple, they have decided that the iPod is a closed system and sees unauthorized hacking of the device as a threat to the business (according to Tapscott, p. 134). In contrast, other businesses such as Salesforce.com, Google, eBay and SAP are aggressively trying to become platform players.

The next challenge is to figure out how to commercialize your platform. As a platform provider, you have to think differently about the nature of your business. It is no longer about selling new features and capabilities to prospects and customers; it’s about creating a massive installed base of users. Except for a base feature-set that initially ensures a wide distribution of the platform, you leave the development of increasingly niche products, services, features and capabilities to partners (and, in some cases, even customers themselves) From a product development standpoint, your job is to enhance the platform thus ensuring lock-in for both the customers and developers — your profit comes from charging both groups for access to the resulting ecosystem.

A contemporary example of commercializing an ecosystem is Salesforce.com’s introduction of AppExchange. Over the past seven to eight years, SFdC has developed an installed base of over 25,000 CRM customers. About a year and a half ago, they launched AppExchange to enable third-party developers and value-added resellers (VARs) to create new features and functionality for the installed base using their platform. When AppExchange first launched, one of the criticisms was the apparent lack of an ability (for either Salesforce.com or its partners) to make money from the platform. According to James Governor’s Monkchips:

AppExchange really needs to be a market, not a platform. What matters most is creating opportunities for folks to make money.

So, that brings us to the last challenge — how do you engage and reward platform partners? Although the platform provider stands to gain from the widespread diffusion of their open, but proprietary, tools and technology (i.e. “the platform”), there are significant risks for third-party developers. If you can create a product or service entirely on someone else’s platform, you’re left with no stand-alone intellectual property. Furthermore, chances are the the barriers of entry are pretty low. As a result, you are entirely at the mercy of the platform provider. This suggests that platforms are more likely to be attractive to developers of complimentary, but niche, capabilities that require specialized skills or industry knowledge. However, if your application is too successful, it will attract attention and can be easily replicated by competitors. To take these risks, the development partner needs a reasonable expectation that they will make money for their efforts. When introducing a platform, you need to ensure that there is a commercial model in place that appropriately compensates and rewards “co-creation” partners (incidentally, Salesforce.com has responded to these concerns and earlier criticisms, and has since announced AppStore — a marketplace for for AppExchange products and services).