Recommended resources
The freely available resources this lesson will direct you to.
Hello. Last time, you mapped what Microsoft does inside its business across Product, Growth, Distribution, People, and Enabling Functions. This lesson moves beyond the company boundary. A software company may build the core product, yet its success can depend on device makers, independent developers, infrastructure vendors, implementation partners, and customers who influence one another.
You will learn to identify customers, complementors, suppliers, channels, and competitors without treating “partner” as a catch-all category. We will use the Windows PC ecosystem as a continuing example, then test how the same method changes for cloud software and AI-native businesses. Allow about 35–40 minutes, including the selected resources.
Define the ecosystem before naming its members
An ecosystem map is only useful if its focal business and customer need are clear. “Microsoft’s ecosystem” is too broad: someone helping distribute Windows PCs may have no comparable role in Azure. Start instead with a proposition such as Windows on PCs used for work. Then ask who helps create that experience, who gets it to users, and what alternatives those users could choose.
The supplied value-net image is a helpful starting view. It places the company among customers, suppliers, complementors, and competitors. Its connections are reminders to investigate relationships—not claims that every pair of actors has a direct contract or payment flow.
The most important distinction is what an actor does in relation to the focal offering:
| Role | Working test |
|---|---|
| Customer | Who buys the offering, uses it, or makes the purchasing decision? These may be different people. |
| Complementor | Who independently offers something that makes the focal offering more useful to a customer? |
| Supplier | Who provides an input used by the focal company—or by another participant—to produce its offering? |
| Channel | Who provides a route through which the focal company reaches, sells to, or serves a customer? |
| Competitor | Who offers another credible way for a customer to accomplish the relevant job—or competes to attract an essential ecosystem participant? |
These are roles, not permanent identities. A device maker might purchase software licenses, distribute that software to end users, and contribute hardware that makes the experience valuable. Rather than force the firm into one box, record each role and the relationship it describes.
Separate an independent complement from an upstream input
BCG’s How You Succeed as a Business Ecosystem Contributor provides a precise distinction between complementors and suppliers. Read its opening account of ecosystem contributors before applying the distinction to Windows.
How You Succeed as a Business Ecosystem Contributor | BCG
Read BCG’s account of how an ecosystem orchestrator differs from its contributors. The distinction between a customer-facing complementor and an upstream supplier is the foundation for the map below.
In “The Growing Role of Ecosystem Contributors,” read the opening discussion, from the paragraph beginning with well-known ecosystem players through the paragraph contrasting complementors with suppliers. Focus on who provides the offering to customers, not merely on whether two companies have a partnership agreement.
A complementor adds customer-facing value alongside the core offering. An independent application developer, for example, can make Windows more useful by offering software that runs on it. The application is not simply an ingredient Microsoft purchases and incorporates into Windows; customers can choose whether to use it.
A supplier provides an upstream input. A contracted provider supplying a component or service that a software company uses to deliver its own offering fits this role. The supplier may be vital without having a direct relationship with the focal company’s end users. Be precise about whose supplier it is: a chipmaker supplying a PC manufacturer is upstream of the device maker. That does not, by itself, establish that it sells chips to Microsoft.
The boundary can change with the arrangement. An independent developer selling its own Windows application is a complementor. If a developer is contracted to build functionality for Microsoft to incorporate into Microsoft’s offering, that contracted work is an upstream input. The test is not whether the work involves code; it is who controls the customer-facing offering and how the parties exchange value.
A channel answers a third question: how does the offering reach the customer? A reseller that sells software subscriptions to an enterprise is acting as a channel. If it also sells an optional integration that improves the software’s usefulness, it is acting as a complementor in that second relationship. If it provides contract engineering to the software vendor, it may be a supplier as well. A sound map records the activities separately.
Build the Windows ecosystem map
Windows is useful because its core operating system, installed devices, and independent software have to work together to produce the customer experience. For historical context—not as a claim about today’s market shares—watch the selected parts of Michael Cusumano’s MITSDM talk, The Business of Platforms. The first part distinguishes platforms built upon by innovators from platforms centered on transactions; the second briefly shows why Windows required more than an operating system alone.
The Business of Platforms: Strategy in the Age of Digital Competition, Innovation, and Power
Watch “The Business of Platforms: Strategy in the Age of Digital Competition, Innovation, and Power” from MITSDM to distinguish the core technology from the independent offerings around it.
Watch platform types for the distinction between innovation and transaction platforms. Then skip to Windows participants, where the speaker identifies the device makers, applications, and end users that had to come together. Focus on their different roles rather than the historical verdict about competing systems.
With Windows on work PCs as the focal offering, a first-pass map looks like this:
| Actor or group | Role in this scoped ecosystem | Relationship to investigate |
|---|---|---|
| Organizations procuring PCs and software | Customers and purchasing decision-makers | Which needs determine device and operating-system choice? |
| Employees using the PCs | End users | Which applications and experiences make the system useful? |
| PC manufacturers | Buyers of OEM licenses, channels to end users, and providers of complementary devices | Who purchases the license, who selects the device, and whose brand owns the user relationship? |
| Independent software developers | Complementors | Which applications make this operating environment more attractive? |
| Component makers supplying PC manufacturers | Suppliers to the manufacturers | Which inputs determine whether manufacturers can produce suitable devices? |
| Alternative PC operating-system and device ecosystems | Competitors for relevant customers and participants | For which work needs can a customer credibly choose another system? |
The table deliberately distinguishes a purchasing relationship from a user relationship. In a pre-installation arrangement, a PC manufacturer can purchase an OEM license and offer a device with Windows to its customer. The organization choosing the PC and the employee using it are also customers in analytically important senses, even if neither buys that license directly from Microsoft. A map that labels only the payer “customer” would miss who determines demand; one that labels only the user would miss the route to market.
It also shows why channels are not just arrows on a sales diagram. A PC manufacturer is a route through which Windows reaches users, but its device affects the experience itself. If a device maker changed what it pre-installs, both distribution and the attractiveness of the combined offering could change. Those are related effects, not the same role.
The BCG reading calls a firm that sets ecosystem standards and rules an orchestrator. You need not settle whether a company orchestrates every relationship to make a useful participant map. It is enough here to identify which actor controls a consequential interface or rule—for example, compatibility requirements—and which other actors depend on it. The next lesson will examine strategic bottlenecks and profit pools more directly.
Identify competitors without calling every partner a rival
Competition becomes clearer when you specify what choice could change. For a customer choosing a work PC, another operating-system-and-device combination may be a direct alternative. For an independent application developer deciding where to invest, another developer ecosystem may be the relevant competing destination. Those are two competitive contests, even when some of the same companies appear in both.
BCG’s What Is Your Business Ecosystem Strategy? explains why ecosystem competition includes the contest for contributors as well as for customers.
What Is Your Business Ecosystem Strategy? | BCG
Read BCG’s explanation of how competing ecosystems vie for both customer demand and contributor participation. This helps distinguish an alternative offering from an alternative home for complementors.
In “5. Which Role Should We Play in the Ecosystem?” there is background on contributor roles; for this reading, go to “5. How Can We Win Against Competing Ecosystems?” and find the sentence beginning “Ecosystem competition differs from conventional market competition in three ways.” Read the first two differences, ending with the paragraph about competing for contributors as well as customers. Focus on how the identity of a competitor depends on which participant’s decision is at stake.
This does not mean every complementor is secretly a competitor. An independent application may help Windows attract users while competing with another application for those users. A platform owner may also offer an overlapping application. In that case, the owner and developer can simultaneously cooperate in the operating-system ecosystem and compete in the application category. Label the arena of competition rather than declaring the entire companies either partners or rivals.
Equally, an alternative does not have to copy the focal company’s product to affect it. If a customer can accomplish more work through a browser-delivered service, that may reduce dependence on a particular desktop application or operating-system capability. It is a potential substitute for part of the customer’s job, not necessarily a direct replacement for the whole operating system. This distinction keeps the competitor map tied to actual customer choices.
Reapply the tests to cloud and AI-native businesses
The categories remain useful when the focal offering changes, but the actors move. Suppose the scope is a cloud application sold to enterprises, rather than Windows on PCs. An enterprise may be the paying customer; its employees are users. An implementation partner may be a channel when it helps win and transact the deal, and a complementor when its integration or specialist service increases the application’s usefulness. A cloud infrastructure provider can be an upstream supplier if the application company buys hosting from it. A competing application is relevant when it addresses the same customer need, even if it uses a different technical approach.
For an AI-native application, use the same questions rather than inventing a new set of labels. An enterprise buyer and its users may still be distinct customers. A model provider or compute provider may supply an upstream input; a third-party integration may complement the application; a marketplace or implementation partner may act as a channel. A competing application, an incumbent software feature, or a customer’s decision to build internally may be alternatives—but only if each can plausibly satisfy the specific job you have scoped. Whether any particular firm fills one of these roles requires evidence about its contracts, product experience, and route to market.
That is the practical value of an ecosystem map: it tells you what to verify. For each consequential relationship, seek evidence of who contracts with whom, who pays, who controls access to users, and whose participation increases the offering’s usefulness. Mark an uncertain relationship as a hypothesis rather than promoting an industry label into a fact.
Key takeaways
Begin with a specific offering and customer need, not an entire conglomerate. Identify customers as payers, decision-makers, and users where those differ. Distinguish independent, customer-facing complementors from upstream suppliers, and record channels as routes to customers even when the same actor plays another role. Finally, name competitors in relation to a particular customer or contributor choice. An actor can occupy several roles at once; the map is stronger when it shows those relationships explicitly.
Next, we will use this outward-looking map alongside the internal value chain to locate profit pools and strategic bottlenecks—where value is created, where constraints arise, and who may have leverage over them.