JSTAcademy
0 XP
Dashboard
Product Management
Platform Products & APIs
16 min
PhD+200 XP
Product Management · PhD

Platform Products & APIs

When the product is infrastructure — designing for the developers who build on top of you
16 min read+200 XP on completionCert: Product Management
Tap any word in the text below to start reading from there.

Platform Products & APIs

Most product management involves building for users. Platform product management involves building for developers who build for users — a level of indirection that changes every PM decision.

Stripe, Twilio, AWS, GitHub, Shopify, Salesforce — these are platform companies. Their customers are not end users; they are the companies and developers who use the platform to serve their own users. The platform's success depends on the ecosystem's success.

What Makes a Product a Platform

A product becomes a platform when third parties can build value-creating extensions or applications on top of it. The key characteristics:

Core enabling capability: something valuable that would be expensive or difficult to replicate independently. Stripe: payment processing infrastructure with global coverage and compliance. AWS: on-demand computing infrastructure with massive capital expenditure spread across millions of customers. Shopify: e-commerce infrastructure including payments, inventory, and distribution.

Extensibility: mechanisms for third parties to build on the core capability — APIs, SDKs, webhooks, plugin systems, app marketplaces.

Network effects: each new third party building on the platform increases the platform's value. More Shopify apps make Shopify more valuable to merchants; more merchants make building Shopify apps more valuable to developers.

Developer Experience as a PM Priority

For platform products, developer experience is the user experience. The developer is the direct customer; their end users are two steps removed.

DX dimensions:

  • API design: Are the endpoints logically named and consistent? Do responses include enough context for error diagnosis? Is authentication straightforward?
  • Documentation: Can a developer get to their first successful API call in under 30 minutes? Are there working code examples in every major language? Are edge cases documented?
  • SDKs: Do official SDKs exist for major languages? Are they maintained and up-to-date?
  • Sandbox/Test environment: Can developers test without affecting production data? Without real payment credentials? Without hitting rate limits?
  • Error messages: Do errors identify the problem and point to the solution? "Invalid API key" is better than "Authentication error 401". "The email field is required" is better than "400 Bad Request".
  • Status page and reliability: developers need to know when the platform is having issues and can plan around them

Stripe's documentation is the canonical example of exceptional DX. Every endpoint is documented with code examples in 8 languages. Error messages include a link to the relevant documentation. New developers can make their first test payment in under 10 minutes.

API Design Principles for PMs

PMs working on APIs do not make low-level technical design decisions — but they shape the requirements that determine API design:

Naming consistency: if the API uses customer_id in one endpoint, it should not use client_id in another for the same concept.

Versioning: APIs change as the product evolves. Breaking changes (removing fields, changing field semantics) require version increments (v1 → v2) or long deprecation windows. Developers cannot update their integrations on the platform's schedule.

Pagination and rate limiting: what happens when a developer requests all 10 million customer records? Pagination and rate limiting define the platform's graceful degradation behaviour.

Webhooks vs polling: pushing events to developers (webhooks) when state changes is more efficient than requiring developers to poll for changes, but requires more reliable delivery guarantees.

Platform Governance and Ecosystem Health

Platform companies face a fundamental tension: the interests of the platform and the interests of ecosystem participants can diverge.

The "envelopment" threat: the platform can choose to build a capability that third-party developers built on the platform — effectively competing with its own ecosystem partners. Apple adding camera apps after camera apps became popular in the App Store. Microsoft adding features to Windows that competed with middleware vendors. This creates a chilling effect on ecosystem investment.

Pricing changes: increasing API costs, adding usage tiers, or changing business models can destroy third-party businesses that built on the assumption of stable costs. Heroku's pricing changes in 2022 forced thousands of projects to migrate.

Policy changes: changing terms of service, restricting access, or requiring data sharing can undermine developer trust and ecosystem stability.

Platform PMs must actively manage ecosystem health — maintaining predictability, communicating changes with long deprecation windows, and demonstrating that the platform is a safe foundation on which to build a business.

Build vs Join a Platform

A recurring PM decision for non-platform products: build a proprietary capability or integrate with an existing platform?

The integration economics: Stripe charges ~2.9% per transaction. Building payment processing from scratch requires PCI compliance, bank relationships, fraud management, and ongoing maintenance — likely costing more in aggregate than Stripe's fee at most scales. Similarly, Twilio's SMS and voice infrastructure costs less to use than to replicate. `ost products should be customers of platforms rather than builders of competing infrastructure.

The exception: when the platform creates unacceptable strategic risk (single-source dependency for a core capability) or when the product needs capabilities the platform does not provide and cannot be customised to provide.

0%