'Platform' is a word that one hears a lot nowadays in our industry, and it sometimes suffers from over-use. Here are a few thoughts on building platforms:
1. The art of being a platform is letting someone else be the product. I.e. platforms should underlie products, enabling diversity, not attempting themselves to be all things to all people.
2. Platforms are collections of capabilities, not baskets of features. Capabilities imply higher level of abstraction, enabling development of diverse feature sets without defining them exhaustively.
3. Platform business is hard. End users interface with products, not platforms. Most businesses compete on stickiness and profitability of their customer relationships. Catering to end users gives one greater scale, and so many businesses that begin by declaring themselves platforms eventually become very keen to own end-user relationships under their own brand, rather than letting third party product developers own them. Evolution of the Apple platform is a good case in point.
4a. For a product-oriented company of sufficient scale, factoring out underlying platform/capability set is key to scaling across global markets with their diverse requirements. Without a good platform foundation, feature flow demanded by differentiated global markets becomes more expensive, there's duplication of effort (and code), gradual accumulation of tangled dependencies and increase in brittleness.
4b. Exactly the same concern arises for SaaS companies that develop tailored solutions for anchor tenants of the platform and need to migrate to true multi-tenant platform.
5. However, a typical product manager is not incentivized to be platform-minded. Most corporate incentive structures are targeting delivery of specific, discrete, value-added features, not investment in broader capabilities that may yield dividends over the longer arc of time.
A humble proposal:
For every investment, there should be an explicitly factored out portion that genuinely accrues to platform building (with the rest going towards feature flow). If it's 0% than at least it's explicitly 0%, not ambiguously implying platform investment or enablement in their absence.
Sometimes, making implied things explicit is all one needs to reach agreements or effect change.
1. The art of being a platform is letting someone else be the product. I.e. platforms should underlie products, enabling diversity, not attempting themselves to be all things to all people.
2. Platforms are collections of capabilities, not baskets of features. Capabilities imply higher level of abstraction, enabling development of diverse feature sets without defining them exhaustively.
3. Platform business is hard. End users interface with products, not platforms. Most businesses compete on stickiness and profitability of their customer relationships. Catering to end users gives one greater scale, and so many businesses that begin by declaring themselves platforms eventually become very keen to own end-user relationships under their own brand, rather than letting third party product developers own them. Evolution of the Apple platform is a good case in point.
4a. For a product-oriented company of sufficient scale, factoring out underlying platform/capability set is key to scaling across global markets with their diverse requirements. Without a good platform foundation, feature flow demanded by differentiated global markets becomes more expensive, there's duplication of effort (and code), gradual accumulation of tangled dependencies and increase in brittleness.
4b. Exactly the same concern arises for SaaS companies that develop tailored solutions for anchor tenants of the platform and need to migrate to true multi-tenant platform.
5. However, a typical product manager is not incentivized to be platform-minded. Most corporate incentive structures are targeting delivery of specific, discrete, value-added features, not investment in broader capabilities that may yield dividends over the longer arc of time.
A humble proposal:
For every investment, there should be an explicitly factored out portion that genuinely accrues to platform building (with the rest going towards feature flow). If it's 0% than at least it's explicitly 0%, not ambiguously implying platform investment or enablement in their absence.
Sometimes, making implied things explicit is all one needs to reach agreements or effect change.
