apply-platform-takeover

Apply Platform Takeover

Enter an established ecosystem as a value-adding participant, make yourself indispensable to the ecosystem's participants and end-users, then shift the power dynamic until the platform depends on you rather than the reverse.

Why This Is Best Practice

Origin: Two stratagems address power inversion within existing structures. Stratagem #30 "Turn the guest into the host" (反客為主): the guest who enters a household and gradually takes over by making themselves indispensable — eventually the host cannot function without them. Stratagem #25 "Replace the beams with rotten timbers" (偷梁換柱): substitute the structural supports gradually — by the time the substitution is visible, the new structure has replaced the old. In business: enter an ecosystem as a dependent participant; gradually replace the underlying dependencies that hold the ecosystem together; become the new structural support.

Adopted by: Platform takeover is one of the most consequential strategic patterns in technology. Microsoft Office became so essential to Windows users that Microsoft's pricing power exceeded Windows itself. AWS entered as a service layer inside Amazon.com, then opened to external customers, then became the structural foundation of the internet — the "beams" of the web are now AWS infrastructure. Salesforce entered enterprises as a CRM application, then became the platform that custom applications were built on (Force.com), then the integration hub that connected all enterprise applications. In each case, the transition from guest to host happened through indispensability rather than assertion.

Impact: Building a new platform from scratch against an established one is expensive and faces the cold-start problem — no participants, no network effects. Platform takeover avoids this: you enter an existing platform with existing participants, provide them with capabilities the platform owner does not, establish direct relationships with them, and gradually become the structural layer they depend on. The platform owner's ecosystem becomes your customer base.

Why best: Platform takeover is patient and capital-efficient relative to platform creation from scratch. The participants, distribution, and demand already exist — you are not creating them but repositioning yourself within them. The vulnerability of established platforms is that they cannot easily displace participants who have become indispensable to the ecosystem without destroying the ecosystem itself.

Sources: Thirty-Six Stratagems #25 and #30 (Sawyer trans. 1994); Parker, Van Alstyne & Choudary, Platform Revolution (2016); Eisenmann, Parker & Van Alstyne, "Strategies for Two-Sided Markets" (HBR, 2006)

Steps

Step 1: Enter as a value-adding participant — ask for nothing exclusive upfront

Platform takeover requires a legitimate entry. The initial offering must:

• Solve a genuine problem in the ecosystem that the platform owner has not addressed
• Make the platform more valuable, not less — adding participants, reducing friction, improving outcomes for end-users
• Not require exclusivity, special treatment, or platform owner cooperation to succeed initially

Examples of legitimate entry into platforms:

• A developer tool that makes it easier to build on the platform's APIs
• An analytics layer that helps other participants optimise their participation
• A marketplace that aggregates the platform's participants for end-users
• A support service that the platform owner does not provide

Do not signal your intent to become the essential layer during entry — early signalling invites competitive pre-emption by the platform owner.

Step 2: Become indispensable — develop capabilities the platform owner cannot easily replicate

The path from participant to host requires building something the ecosystem cannot function well without:

Indispensability mechanism	How it works
Technical integration depth	Your product is integrated with dozens of other ecosystem participants; removing you breaks their integrations
User relationship ownership	End-users think of you as their primary interface to the ecosystem, not the underlying platform
Cross-platform data	You aggregate data or capabilities from multiple platforms; participants depend on you for insight they cannot get from any single platform
Category expertise	You have become the authoritative source for a capability category within the ecosystem
Network effects within the ecosystem	Your product has created its own sub-network within the ecosystem whose participants depend on your connections

Focus on the indispensability mechanism that is hardest for the platform owner to replicate. If the platform owner can easily build what you have built, you are not yet indispensable.

Step 3: Establish direct relationships with ecosystem participants — make them your customers, not the platform's

The shift from guest to host requires that the ecosystem's participants see their primary relationship as being with you, not the underlying platform:

• Establish direct communication channels with participants: email lists, community forums, direct contracts
• Create value outside the platform: education, certifications, off-platform tools, consulting
• Build loyalty through investment in participant success that the platform owner does not match
• Collect data about participants' needs and behaviour independently of the platform

When participants think of you as an essential partner — not just an app on a platform — you have established the relationship layer that enables the power inversion.

Step 4: Shift the terms — use indispensability to extract favourable conditions

Once indispensable, you can shift the power dynamic:

• Negotiate data portability — your customers' data should be accessible to you independently of the platform
• Negotiate preferential terms — reduced commission, featured placement, early API access
• Build cross-platform capabilities that reduce the platform's centrality to your customers' experience
• Introduce capabilities that make the underlying platform partially substitutable

The platform owner faces a dilemma: removing or degrading you damages the ecosystem they have built; accepting your terms preserves the ecosystem but cedes power.

Step 5: Replace or bypass the original platform once the relationship layer belongs to you

The endgame of platform takeover is either:

• Platform dependency: The platform needs you more than you need it — you can now set terms and expand your scope of operation
• Platform bypass: You have accumulated enough of the relationship layer and technical capability to offer participants an alternative to the platform itself

The bypass option is available when you control the participant relationships and have the technical capability to replicate the platform's core function. The platform owner's ecosystem has become your customer acquisition channel for your own platform.

Rules

• Enter with genuine value. Platform takeover that does not deliver genuine value to ecosystem participants during the entry phase will be rejected by those participants. The indispensability must be earned, not asserted.
• Do not signal intent to take over during entry. Platform owners who recognise the takeover intent early will use their control of the platform to remove, degrade, or restrict you before indispensability is established. Appear as a committed participant until indispensability is secured.
• Build indispensability through participant relationships, not through platform owner dependency. If your indispensability depends on the platform owner's cooperation, they can withdraw it. Indispensability built through participant relationships is more durable.
• Be prepared for the platform owner's defensive response. Once the power shift is visible, the platform owner will attempt to replicate your capability, restrict your access, or change their terms. This response validates that you have executed the takeover successfully; be prepared to defend your position.
• Do not over-extend before indispensability is secured. Premature assertion of power — demanding terms before you are indispensable — invites the platform owner's defensive response before you are strong enough to sustain it.

Examples

Microsoft Office on Windows: In the early 1990s, Windows was the platform; Office was a participant. Microsoft invested in making Office deeply integrated with Windows in ways that made the combination more valuable than either alone. Over time, Office became the reason many users purchased Windows — the platform needed the participant more than the reverse. Microsoft's pricing power in Office exceeded Windows pricing power for enterprise buyers by the late 1990s. The guest had become the host: enterprises negotiated Windows licensing as an adjunct to Office licensing, not the reverse.

Amazon AWS: from internal service to internet infrastructure: Amazon built AWS originally as an internal infrastructure service for Amazon.com (a participant in Amazon's own operations). Opening AWS to external customers in 2006 was the entry into the broader internet ecosystem. Over 15 years, AWS became so deeply integrated into the operations of tens of thousands of companies that it became the structural layer of the internet. Participants (websites, SaaS companies, startups) depended on AWS infrastructure; platform owners (app stores, content networks, e-commerce platforms) ran on AWS. The "beams" of the internet had been replaced — the original internet infrastructure owners (Rackspace, Akamai, data center operators) had been partially displaced by a new structural layer AWS provided.

Salesforce: CRM app → platform → integration hub: Salesforce entered enterprise accounts as a CRM application — a guest in the enterprise software ecosystem. It then introduced Force.com, enabling custom applications to be built on Salesforce infrastructure. Enterprises that built custom applications on Force.com had data, workflows, and integrations embedded in Salesforce. Salesforce then introduced AppExchange, turning its platform into a marketplace for third-party applications — becoming the platform, not just a participant. Finally, MuleSoft acquisition and Salesforce's integration capabilities made it the hub connecting all enterprise applications. The guest had become the infrastructure that the entire enterprise software ecosystem ran on.

Common Mistakes

Signalling intent during entry: If the platform owner recognises the takeover intent before indispensability is established, they will use platform control to remove or degrade your position. The entry must appear as committed, long-term participation in the ecosystem — not as preparation for power inversion.

Building indispensability through platform cooperation: If your capabilities depend on API access, preferred partner status, or platform owner cooperation, the platform owner can withdraw that cooperation once the threat is recognised. Build indispensability through participant relationships and capabilities that do not require platform owner approval.

Moving to extract terms before indispensability is secured: Premature assertion of power — demanding data portability, lower commission rates, or preferential treatment before you are genuinely indispensable — invites defensive response when you are still vulnerable. Wait until the cost to the platform owner of losing you exceeds the cost of acceding to your terms.

Under-investing in participant relationships: The power inversion depends on participants seeing their primary relationship as being with you, not the underlying platform. Investing only in the platform relationship — and neglecting direct participant relationships — leaves you as a dependent app, not a host candidate.

Treating the platform owner as an adversary too early: The platform owner is your distribution channel during the entry and indispensability phases. Adversarial relationships during this period — public criticism, competitive positioning, customer poaching — activate defensive responses before you are strong enough to sustain them. Maintain cooperative appearances until the relationship layer belongs to you.