Lesson 61: Platform Thinking: Products, Platforms, and Ecosystems

Lesson 60 closed the foundational arc of this curriculum by asking you to consolidate everything into a personal product philosophy. That philosophy was built almost entirely around a single mental image: one team, one product, one set of users. Module 7 breaks that image apart.

Most PMs spend their first several years working on what this lesson will call a feature product — a bounded set of capabilities serving a definable user, shipped by a single team you can name. But as products succeed, they tend to stop being feature products and start becoming platforms: systems whose value comes not from what the core team builds directly, but from what other teams, companies, and developers build on top of them. Amazon's retail storefront is a feature product. Amazon Web Services is a platform. Slack's messaging interface is a feature product. The Slack App Directory, built by thousands of external developers, is a platform layered on top of it.

This distinction matters because platform PMs are evaluated on a different axis than feature PMs. A feature PM asks, "did our product make the right decision for our users?" A platform PM must ask a second, harder question: "did our product make it possible — and worthwhile — for someone else to make good decisions on top of us?" Get this wrong, and you can ship a technically excellent platform that no one builds on, which is a failure mode invisible to every metric you learned about in Module 5, because usage of the platform by external builders doesn't show up in your own product's engagement dashboards at all.

This lesson introduces the vocabulary, diagnostic questions, and a new mental model — the Leverage Stack — that you will use throughout Module 7 to reason about products that succeed by empowering others rather than by directly serving an end user.

Learning Objectives

1
Distinguish a feature product from a platform product using the "who creates the value" test.
2
Explain the Leverage Stack and identify which layer a given product decision operates on.
3
Identify the distinct success metrics required for platform products versus feature products.
4
Describe at least two structural risks unique to platform businesses that do not exist for feature products.
5
Evaluate a real product decision for whether it strengthens or weakens third-party incentive to build on the platform.

This lesson assumes you carry forward the Accountability Triangle and Output vs. Outcome distinction from Lesson 1, and the growth loop vocabulary (in particular, the K-factor and the idea that growth can be structurally embedded in a product rather than bolted on) from Lesson 46. It also assumes the closing synthesis from Lesson 60 — that you have already articulated your own view of what a PM is accountable for — since this lesson is going to complicate that view by adding a second class of "user" you are accountable to: the builder.

The Feature Product / Platform Distinction

A useful diagnostic, sometimes called the "who creates the value" test: when a user has a good experience with your product, who built the thing that made that experience good?

If the answer is almost always "our own team," you are managing a feature product.
If the answer is increasingly "a third party we don't employ, using tools we built," you are managing a platform.

Most successful products migrate from the first category toward the second over time, not because platforms are inherently superior, but because a platform's value can scale without the core team's headcount scaling in proportion. A feature team of thirty engineers can ship a great note-taking app. It cannot, by itself, build ten thousand integrations connecting that note-taking app to every calendar, CRM, and messaging tool on earth. A platform can — by making those ten thousand integrations worthwhile for people who don't work for the company to build.

The Leverage Stack

This lesson introduces the Leverage Stack, a four-layer model for reasoning about where a platform decision actually operates:

Each layer depends on the one below it, and a weakness at a lower layer caps everything above it. If your Developer Surface (Layer 2) is unreliable — APIs that change without notice, documentation that lags behind reality — no amount of investment in Marketplace discovery (Layer 3) will produce a thriving Ecosystem (Layer 4), because builders will not invest their own time and reputation on a foundation they don't trust.

The Leverage Stack is useful precisely because it forces you to locate a proposed initiative. "Should we build a plugin marketplace?" is a Layer 3 question that presupposes a healthy Layer 2. Teams frequently skip straight to Layer 3 or 4 investments — public marketplaces, developer conferences, partner co-marketing — while Layer 2 is still brittle, and then wonder why adoption stalls. We will return to this exact failure pattern in the Case Study below.

Direct, Indirect, and Platform Network Effects

Lesson 46 introduced growth loops and the K-factor for user-to-user virality. Platforms introduce a related but distinct phenomenon: network effects across two different populations — builders and end users — where growth in one population increases the value of the platform for the other.

This loop, sometimes called a cross-side network effect, is the structural engine behind platforms like app stores, marketplaces, and developer ecosystems: more shoppers attract more sellers, and more sellers (with more selection) attract more shoppers. Note that this loop can also run in reverse and collapse just as powerfully — a platform that loses end users gives builders a reason to leave, which then gives remaining users a reason to leave too. Platform PMs must monitor both sides of this loop, not just the side closest to their own team's traditional metrics.

Platform Value Capture: The Take-Rate Question

A platform must eventually answer how it captures value from the ecosystem it enables — typically through a take rate (a percentage of transactions, as with app store commissions or marketplace fees), a subscription or usage fee for developer access (as with many API-first companies), or an indirect capture strategy where the platform is monetized elsewhere and the developer surface is offered as a retention or distribution mechanism rather than a direct revenue line. Choosing the wrong capture mechanism, or setting a take rate that developers perceive as extractive relative to the value they receive, is one of the most common causes of ecosystem stagnation, and is a topic this curriculum returns to in Lesson 79 (Pricing Strategy at Scale).

Platform Thinking: Products, Platforms, and Ecosystems