Platform PM Principles

Adapt your psychology, timeline expectations, and stakeholder principles for platform work

Brandon Chu
Brandon Chu on product management, writing, and Shopify's culture

Platform PM Principles

"The first thing is as a PM, your psychology has to really change around your own validation. So usually, you can build a product, ship it, customers tell you if it's good or not. The cycles for platform work are five to 10 odd times longer." - Brandon Chu

What It Is

Platform PM Principles is a framework for adapting your approach when transitioning from consumer/user-facing product work to platform and developer ecosystem work. The domains require fundamentally different psychology, timeline expectations, and stakeholder management approaches.

Platform work involves building canvases for others to create on, not designing end-user experiences directly. You ship APIs and infrastructure that developers use to build apps that merchants use to serve buyers. This creates multi-party complexity and dramatically extends feedback loops—sometimes by 5-10x.

Without understanding these differences, talented consumer PMs often struggle or burn out in platform roles.

How It Works

Psychological Shift:

Consumer PM validation: Ship → Users react → Learn → Iterate (weeks) Platform PM validation: Infrastructure → API → Alpha → Beta → Developers build → End users experience (months to years)

You must find fulfillment in longer cycles and celebrate milestones that have no external visibility (like an API entering alpha).

Stakeholder Stack-Ranking:

Before executing any platform work, establish and align on who matters most when stakeholders conflict:

Example at Amazon (hypothetical):

  1. Consumer > Seller (when in conflict, consumer wins)

Example at Shopify:

  1. Merchants (entrepreneurs) > Developers > End buyers

This determines data policy, economic splits, and design decisions when tradeoffs arise.

Design Spectrum:

Platform UX exists on a spectrum from loose to tight integration:

  • Loose: Link out to third-party site (new tab opens)
  • Medium: iFrame embedded in your product
  • Tight: Your app serves UI on behalf of third-party, with their data

Tighter integration = better UX but more control you cede to third parties. You must decide how far to go for each extension point.

How to Apply It

  1. Adjust your validation sources - Stop expecting immediate user feedback. Find satisfaction in API adoption metrics, developer NPS, alpha program engagement—leading indicators before end users ever touch anything.

  2. Establish constituent hierarchy early - Before starting any project, get alignment on: When stakeholders conflict, who wins? Document this. Reference it in every design decision.

  3. Celebrate invisible milestones - When an API goes to alpha, throw a party. There's no press release, but the team needs recognition. Tell the narrative of how this enables future end-user value.

  4. Map your integration spectrum - For each extension point, deliberately choose where on the loose-to-tight spectrum to land. Don't default to one extreme.

  5. Hire for patience and systems thinking - Platform work requires people who find joy in enabling others rather than shipping directly visible features.

When to Use It

  • When transitioning from consumer to platform PM - Recalibrate your expectations
  • When building a developer ecosystem - Establish stakeholder hierarchy upfront
  • When designing API extension points - Deliberately choose integration tightness
  • When your platform team seems demoralized - Check if you're celebrating invisible wins
  • When facing stakeholder conflicts - Reference your pre-established hierarchy

Source

  • Guest: Brandon Chu
  • Episode: "Brandon Chu on product management, writing, and Shopify's culture"
  • Key Discussion: (41:39-45:07) - Deep dive on platform PM psychology and principles
  • YouTube: Watch on YouTube

Related Frameworks

Back to Product Strategy