Mapping Ecosystem Control Points, Dependencies, and Bottlenecks

Hello. Last lesson asked whether a customer, transaction, or workload generates enough contribution to justify the costs behind it. This lesson asks who can change that equation. A company may have attractive unit economics today yet depend on another firm for customer access, technical capacity, or the right to operate.

You will learn to map a company’s control points, complements, dependencies, and potential bottlenecks—and to distinguish an asset that is merely important from one that confers bargaining power. Allow about 40–45 minutes, including the short videos and selected readings.

1. Move from a value chain to an ecosystem

A value chain identifies activities required to deliver an offering. An ecosystem map adds a different question: which independent participants must cooperate, and who governs the interfaces between them? An enterprise software company, for example, may write its own application while relying on cloud infrastructure, customer identity systems, implementation partners, and third-party integrations. Those firms do not all sit neatly before or after one another in a linear chain.

Watch NYU Stern’s How the Platform Ecosystem Works for the distinction between a tightly integrated product and a modular ecosystem. Notice the trade-off: opening interfaces can attract specialized offerings, while leaving the platform owner with less direct control over everything customers experience.

A complement is an offering that makes another offering more valuable to a customer, or helps deliver the customer outcome. An application built for a software platform is one example; an implementation service that makes that application usable is another. A complementor may cooperate with the platform while also competing with its other complementors—or even with a product the platform owner later develops.

The diagram below separates two relationships that are easy to conflate. The labeled connections from individual complements to the platform represent vertical complementarity. Connections among complements represent forms of horizontal complementarity: the offerings can be more useful together because of platform design, shared standards, direct integration, or a combined portfolio. The grouping also depicts collective complementarity—value created by the set, not necessarily by any one connection in isolation.

This distinction matters commercially. If customers value an integrated set of tools, a company controlling the platform interface may benefit from many complementors joining. But the complementors’ ability to interoperate can also reduce dependence on any single vendor. Whether openness strengthens the platform, its partners, or both depends on the rules and available alternatives.

2. Draw a map that explains power, not just participation

A useful ecosystem map starts with a focal company, customer outcome, and scope. “The global software ecosystem” is too broad to diagnose. “How a merchant uses a commerce platform to sell online in a given market” is workable. For that scope, identify customers, the focal company, complementors, infrastructure providers, distribution channels, and relevant rule-setters.

Then annotate the relationships. For each important pair, ask: What passes between them—money, data, access to customers, technical capability, or trust? Who can change the terms? A logo without an exchange or a decision right contributes little to the analysis.

Read the indicated parts of Umbrex’s Ecosystem Mapping. Its practical value here is the insistence on mapping flows and rules before declaring where power sits.

Shopify provides a concrete lens without requiring a product-by-product tour. Watch this short segment of Boundaryless’s The Fundamentals of Ecosystem Strategies with Simone Cicero. Its point is that the commerce proposition involves merchants and specialists who help them succeed, not merely software supplied by one firm.

An initial map for a merchant-commerce platform might record the following relationships. These are analytical categories, not a claim that every merchant uses every participant:

The map prevents a common overstatement: enabling merchants to reach buyers is not the same as owning all merchant demand. Merchants may control important customer relationships while depending on outside discovery channels. The platform, in turn, can govern important software interfaces while depending on other firms to make the overall merchant proposition work.

3. Locate control points—and test whether they confer leverage

A control point is an interface, resource, or decision right through which a company can influence participation, terms, or the customer experience. Examples include default distribution, an identity layer, access to proprietary data, an application interface, certification rules, or a scarce component. The decisive question is not “Is this asset valuable?” but “What can its owner cause other participants to do, and what alternatives do they have?”

BCG’s What Is Your Business Ecosystem Strategy? distinguishes the platform orchestrator from complementors and upstream suppliers. Read its discussion of both orchestrator and contributor power: owning the central platform is not the only way to hold a defensible position.

To assess a proposed control point, apply four tests:

1. Decision rights: Can the company set access, technical standards, ranking, pricing, or enforcement terms—or does it merely participate under someone else’s rules?
2. Criticality: If access disappeared or terms worsened, how much customer value or partner profit would be at risk?
3. Substitutability: Could affected parties switch, use multiple providers, build their own capability, or bypass the interface? At what cost and speed?
4. Durability: Are the rights enforceable and likely to persist, or vulnerable to open standards, regulation, partner resistance, or technological change?

Consider an enterprise workflow platform. Its integration interface may be a control point if partners must use it to reach customers and the platform can set certification and access terms. Yet a large implementation partner may hold a different control point: specialized expertise and trusted access to major customers. Neither party’s position can be inferred solely from its place on an architecture diagram.

Control does not guarantee unlimited value capture. A platform that raises partner fees or favors its own offerings might increase its share per transaction but discourage the complements that attract customers. Conversely, an essential complementor may negotiate favorable terms despite not owning the platform. BCG’s distinction between creating ecosystem value and distributing it is therefore central to the diagnosis.

4. Separate dependencies from bottlenecks

A dependency is something the focal company needs but does not fully control. It can be technical, commercial, operational, or regulatory. A dependency is not automatically a strategic weakness: using an external provider may be cheaper, faster, and more resilient than building internally.

A bottleneck is a dependency—or an internally controlled capability—whose limited availability or restrictive terms materially constrain the outcome being studied. Bottlenecks are relative to a particular goal and time horizon. Cloud capacity might be abundant for a routine application but constrained for a workload needing a particular accelerator, location, and delivery date. An integration might function technically yet bottleneck growth if customer approval takes months.

A reliable diagnostic uses a counterfactual: If this participant raised prices, degraded quality, restricted access, or failed, what would the focal company do? Estimate the time, cost, and customer impact of the best alternative. This exposes the difference between a prominent supplier and an indispensable one.

For an illustrative AI-native application, a model provider is a clear dependency. Whether it is a bottleneck depends on the application’s quality requirements, latency, data terms, switching effort, and availability of acceptable models. The application company might control a valuable customer workflow and feedback data while still depending on a distributor for access to users and on infrastructure providers for serving capacity. Its strategic position is the combination of those rights and constraints, not the mere fact that it “uses AI.”

The same questions travel across the industry:

• For enterprise software, inspect systems-of-record access, identity and data permissions, integrations, implementation capacity, and customer workflow ownership.
• For cloud and AI infrastructure, inspect scarce components, capacity commitments, software compatibility, power availability, and workload portability.
• For consumer or commerce platforms, inspect attention and discovery, participant quality, trust mechanisms, and the ability to transact outside the platform.
• For payments, inspect access to rails and financial partners, merchant integration, authorization performance, and market-specific operating requirements.

These are places to investigate, not automatic claims of monopoly power. The map must show the relevant market, who holds each decision right, and the feasible alternatives.

5. Turn the map into a strategic diagnosis

A concise company assessment can now distinguish four statements that are often blurred together:

Control point: “The company sets the terms of this interface.”
Complement: “This independent offering increases the value of the customer solution.”
Dependency: “The company needs this external participant or capability.”
Potential bottleneck: “Under a specified scenario, this constraint could limit growth, quality, or value capture.”

For each important statement, attach evidence. Terms of service and technical documentation can establish interface rules; contracts or partner disclosures can reveal access and revenue-sharing rights; customer behavior and switching patterns can test substitutability. Financial disclosures and the unit economics from last lesson help establish whether the apparent control point translates into retained economic value. Where those facts are unavailable, label the conclusion a hypothesis and state what would confirm or disprove it.

Finally, examine two directions of risk. Upstream or adjacent partners may increase their prices, constrain supply, or change access rules. The focal company’s own governance may weaken its ecosystem if complementors cannot earn enough to participate. A strong strategic position requires both leverage over critical interfaces and a viable reason for other participants to remain.

Conclusion

An ecosystem diagnosis is more than a list of partners. Map the exchanges and decision rights; identify the complements that improve the customer outcome; test control points against criticality and alternatives; and distinguish ordinary dependencies from bottlenecks that could bind under a plausible scenario. The most revealing question is often: who could change the terms, and what would everyone else do?

Next lesson, you will use this view of control and substitutability to build a defensible competitor set—including direct rivals, substitutes, entrants, and firms approaching from adjacent parts of the ecosystem.