Ecosystem Leadership and the Platform Economy
Building an ecosystem is one thing; leading it is another. If your partners are not earning around you, what surrounds your platform is a crowd in which only you win.
EnterpriseStrategy 70 / 885 min read
Author: Alp SuleimanPublished Updated
Platform companies often voice a familiar complaint: “We have developers, we have APIs, we have a marketplace. But nobody is building anything.” Look at the documentation, the hackathons, the developer relations team, and all of it is in place. What is missing is credible proof that a developer could make money on top of them.
Ecosystem leadership is a different job from running a platform. Here, your product matters, but so does your partners' economics, the stability of your rules and, above all, your answer to the question “will this company turn on me one day?”
When you need it
When long-tail demand has built up on your platform that your own product team cannot satisfy (customers constantly asking for integrations, add-ons or industry-specific extensions), it is time for ecosystem leadership. Likewise, if customers use your product as a “work environment” rather than a “tool” and build their own processes on top, partners are likely to add value there.
Salesforce introducing AppExchange in 2005 is an example of an extension economy starting at the right time, on a product that already had a strong customer base and customers who wanted to customize. Apple's App Store worked because it offered developers a market once the device base was large enough.
It can also be too early. With a small user base you cannot offer partners a meaningful market; the core product has to prove it attracts customers before it can attract developers. And if the interfaces of the core product (APIs, data model) break often, partners cannot trust it.
What most teams miss
Ecosystems have two distinct ways of being built, and the two are often confused. The first is building the ecosystem: opening APIs, launching a marketplace, announcing a partner program. The second is leading it: looking at who earns how much, how the rules change and whose side you stand on in a conflict.
Marco Iansiti and Roy Levien's concept of the “keystone” describes this well. A keystone player manages ecosystem health through its partners' economics. A “dominator,” which pulls most of the value to itself, wins in the short run and in the long run causes partners to leave. An ecosystem is a value-sharing agreement; if your share is not generous enough, the partner goes to another ecosystem.
Trust is the currency of this leadership. Twitter shutting off third-party client access in 2023 proved to developers who had built businesses on those clients that an ecosystem's rules can change overnight. The debates around Apple's App Store commission policy also show the tension between power and cooperation for an ecosystem leader. In both cases the future of the ecosystem depends on how much partners trust the leader.
Ecosystem leadership means managing your partners' success as a precondition of your own.
The playbook
1. Make partner economics measurable
For each partner category (developer, integrator, distributor, consultant), build a “partner economics” table: time to first revenue, typical annual revenue, the share we take, the partner's own costs. If you cannot build this table, you do not know why the partner is there.
2. Shorten the path to first revenue
The speed at which a developer takes a product to market is the most important leading indicator of ecosystem health. Sandbox, sample code, certification process, listing approval, route to the first customer: measure the time of each step and fix the longest. In most ecosystems the problem is that partners give up before seeing their first payment.
3. Write down the rules and the change protocol
Commission rate, API usage limits, data rights, listing conditions and the “which areas we may also enter” rule should be written. And write how rules will change: how much notice, what transition period. A partner's biggest fear is rules changing by surprise.
4. Set the boundary between your product and your partners
The most dangerous decision for an ecosystem leader is moving your own product into an area where a partner succeeded. Sometimes it is necessary. But if you state up front which areas you will not enter, partners do not hesitate to invest. This decision should be part of the product roadmap, not an accident.
5. Segment partners and build dedicated support
Do not lump partners together. A small developer, a mid-sized ISV and a large integrator need different support. Run joint roadmap work with the partners who create the most value and provide co-marketing and sales support. Ecosystem value concentrates in a small share of partners; investing in them yields a high return.
What to measure
- Time to first revenue: How long does it take a new partner to earn their first money on your platform? The strongest leading indicator of ecosystem health.
- Revenue per partner and partner retention: Are partners earning and staying? A lagging but honest measure.
- Ecosystem-sourced customer share: How much of customer buying or retention comes through partner solutions? Shows that partners add real value to the product.
- Partner NPS: How does partner trust change over time? It drops fast after rule changes.
Pitfalls
Commission hunger. Taking a share that squeezes partners early can dry the ecosystem up before it grows. Keeping the share low during growth encourages partner investment.
Entering the partner's space. Copying a partner's successful product, once done, signals to the whole ecosystem: “success here gets appropriated.” Keep this decision deliberate, explained and exceptional.
Rule instability. Changing the API or the rules suddenly destroys the investment partners made. Advance notice and a transition period for changes should be standard.
Start this week
- Talk to your five most valuable partners and ask each: “Is the money you earn on us enough to keep you here?” Write down the answers.
- Map the path of a new developer or partner to first revenue step by step, put a duration on each and identify the longest step.
- Draft a one-page rule sheet covering commission, API changes and the areas your own product will enter, and ask the board: “is this the promise we are making to partners?”