Platform Principles and Constituent Stack Rank
Rank who the platform serves before policy and design force a trade-off
- Difficulty
- Advanced
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 97%
Platform decisions cannot be optimized for one user because several constituencies create and consume value. Chu uses a developer platform to illustrate the problem: developers build apps, businesses use them, and end buyers may encounter them, while policy, data sharing, economics, and interface control create conflicts among all three. Before detailed design or technical execution, the PM defines the principles behind the platform and stack-ranks the constituencies for moments when their interests cannot all win. That priority order becomes a decision rule for policy and design. The team then traces second-order effects rather than treating them as surprises. A platform focused on business independence, for example, may require developers to return data so merchants retain access, even when that imposes a cost on an app provider.
Origin
After years working on Shopify's developer ecosystem, Chu identified explicit platform principles and a stack rank of constituencies as essential preparation for platform PMs.
Core principles
- 01A platform PM designs a canvas for other creators rather than a single end-user experience
- 02Platforms contain multiple constituencies with legitimate but conflicting interests
- 03Mission-level principles determine which constituency wins a hard trade-off
- 04Policy, data, economics, design, and engineering must express the same priority order
- 05Each priority choice creates second-order effects that should be accepted consciously
How to run it
- 1
Map the value system
List everyone who builds, supplies, operates, distributes, or consumes value through the platform. Describe what each group needs and controls.
Pro tip Include the end customer even when the platform team's direct user is a developer or business.
Watch out Optimizing only for the direct API consumer hides downstream effects.
- 2
Define the governing mission
State what the platform ultimately exists to enable. Turn that mission into principles strong enough to decide a conflict, not broad values everyone can endorse.
Watch out Principles discovered after implementation may merely rationalize decisions already made.
- 3
Stack-rank constituencies
Specify who wins when two legitimate needs cannot both be satisfied. Make the order explicit before a contentious launch or policy change forces the issue.
Pro tip Use a concrete conflict to test whether the ranking is operational.
Watch out Trying to call every constituency equally primary leaves the hardest decisions unresolved.
- 4
Trace cross-system consequences
Apply the ranking to data access, policy, economics, interface control, and engineering architecture. Identify both the primary benefit and the second-order cost to other groups.
Pro tip Examine how one participant's data behavior can create a duplicated or contradictory experience for an end customer.
- 5
Decide and communicate early
Use the principles to make the trade-off before detailed implementation. Explain the rationale to affected groups and use resulting incidents to refine the principles.
Watch out Unstated trade-offs can surface as a CEO block immediately before launch or as damaging incidents afterward.
In the wild
Chu explains that Shopify's mission supports entrepreneurs and business independence. That can justify requiring an app developer to push data back into Shopify so the merchant and other apps can access it, rather than allowing one provider to hold it back.
→ A mission-level priority supplies a consistent rule for a contentious data-policy choice.
Chu offers Amazon as a hypothetical contrast, explicitly saying he is assuming the principle: when seller and buyer interests conflict, a consumer-focused platform may side with the buyer and accept seller dissatisfaction as a second-order effect.
→ The example shows how a clear constituency rank can produce consistent service decisions and predictable costs.
Common mistakes
Designing before defining principles
Technical and interface work begins without a rule for resolving the multi-party conflicts embedded in the platform.
Ignoring second-order effects
A decision can benefit the top-ranked constituency while harming another group; failing to anticipate that cost turns a conscious trade-off into an avoidable incident.
Is it for you?
Best for
It is best for PMs designing developer platforms, marketplaces, operating systems, or other multi-party ecosystems.
Not ideal for
It is not ideal for simple single-user products with no meaningful conflict among participant groups.
From the episode
Brandon Chu on building product at Shopify, how writing changed the trajectory of his career, the habits that make you a great PM, pros and cons of being a platform PM, how Shopify got through Covid