January 1, 2015 Jason

The TurboCore platform Series: Building a successful platform

Building a platform technology is more than just declaring it as such.  Products do not exist as platforms for the sake of being a platform, but must have some intrinsic value, which can be built upon and ultimately enable new and superior products and services.  Platforms must also have clear points of stability and vicissitude.  Lastly, platforms must have clear processes for enabling collaboration between different parts of the ecosystem—be it internal manufacturing teams, or application developers that clearly articulates how to best leverage a platforms strengths.

The purpose of developing a platform, as indicated in the last post, is predicated on either reducing cost or building value within an ecosystem.  Regardless, the underlying product itself must have some native value, which can be leveraged and grown.  In the previous post vehicle chassis were a strong example because they were the foundation for both cost reduction and were valuable in providing the structure which ultimately housed the vehicles built from them.  In the Apple example, the mobile hardware is the platform, on top of which new applications could be built that uniquely leveraged mobility.  A platform with a unique value proposition fosters a strong ecosystem—tautologically, a strong platform begets itself.

Because the platform is really a foundation for everything that is built on top of it, there must be features of the platform which are immutable, delivering a core set of values.   This can range from the physical footprint (think x86 chipset platform) to how it is used (think Facebook).  There must also features that can be modified or tweaked in a controllable manner to allow users of the platform to adapt it to their own needs.  Often times these modifications exist beyond the physical (or digital) product produced by the source company.  In the example of vehicle chassis, variations include physical pieces of equipment added to create the final product, from the engine and drive train installed on the chassis, to the trim on the interior.  This alludes to early channels for platform technology, namely the OEM. OEMs take core pieces of hardware, like CPUs or Engine, and build a variety of products around them, such as Servers and PCs or trucks and generators—however the interface between the core technology and the whole products are the same.  The customer ultimately derives value from consuming the whole product for their specific needs, but the platform is what provides the foundational value for those end products, be it computational power or horse power.

The last key is defining how the platform interacts with the ecosystem around them.  It should be clear that the interface itself sits and dictates the boundaries of what is core to the technology, and what is mutable.  In software this can be as simple as providing an API or SDK; hardware standards are more complex, with physical properties that must be taken into account.  Regardless, these interfaces define the strength and flexibility of a platform.  If the interface is poorly defined or does not allow partners to leverage the underlying technology, the platform will wither.  Part of understanding the interface is understanding how to communicate it to ecosystem partners; depending on the complexity of the underlying platform, a simple API may be sufficient, but more sophisticated systems may require training, education, and joint technology development.  Partners themselves may need to be qualified or their products screened before being released to the world.  Building a robust process for defining that interface is an exercise in trust between the technology provider and the ecosystem, and is an integral part of building a world class platform.