This is the second post in the How I Ship series, where we look at real PM workflows inside specific companies. First up was a general look at shipping culture. This time: Stripe.
The Company
Stripe builds payments infrastructure for the internet. Founded in 2010 by Patrick and John Collison, the company now processes hundreds of billions of dollars annually and employs thousands of people across dozens of countries.
What makes Stripe unusual as a PM environment is its developer-first DNA. The product is an API. The quality of that API is the entire business. PMs at Stripe don't ship features that users click on. They ship interfaces that developers build against. That distinction shapes everything about how the PM role works there.
Stripe also operates in one of the most heavily regulated spaces in tech. Financial services compliance adds real constraints to what can ship, when, and how. PMs who thrive at Stripe learn to treat regulatory requirements as design constraints, not blockers.
The Workflow
Writing culture. Stripe is famous for its writing culture, and PMs are at the center of it. Major product decisions are driven by 6-page narrative documents, not slide decks. PMs write structured proposals that lay out the problem, the options considered, the recommended approach, and the tradeoffs. These documents are pre-read before meetings. The meeting itself is for questions and decisions, not presentations.
This matters because writing forces clarity in ways that slides don't. A PM who can write a clear, persuasive doc gets more done at Stripe than one who relies on charisma in meetings. If you're building this skill, start with how to write a strong PRD. The same structural discipline applies to Stripe's longer narrative docs.
Operating principles. Stripe publishes operating principles internally, and PMs align decisions to them. "Users first" is the north star for prioritization. When two valid approaches conflict, the one that serves users better wins. This sounds obvious, but having it codified means PMs can cite the principle in debates instead of relying on opinion or authority.
Long planning horizons. Payments infrastructure has integration complexity that most SaaS products don't. Merchants build on Stripe's APIs. Breaking changes have real financial consequences. This means Stripe PMs plan further ahead than is typical. Quarterly planning feeds into annual strategy. Multi-quarter roadmaps aren't just for executives. They're working documents that engineering teams reference daily. For PMs coming from faster-cycle environments, this shift in planning horizon is one of the biggest adjustments. Product management in regulated industries covers more on navigating these constraints.
Cross-functional pods. PMs work in small teams with engineering and design, similar to most tech companies. The difference is the extended cast. Compliance, legal, and risk teams are involved in product decisions early, not as a sign-off gate at the end. PMs who treat compliance as a late-stage checkpoint get stuck. PMs who bring compliance in during discovery move faster.
API-first thinking. Every feature is evaluated through the lens of "how does this work as an API?" PMs think about API-first design before they think about dashboards or UIs. This is a specific flavor of developer experience thinking. The question isn't "is the button in the right place?" It's "can a developer integrate this in under 10 minutes with clear error messages?"
The Decisions
Balancing innovation vs. reliability. In payments, breaking things costs real money. A failed API call might mean a merchant can't process transactions. PMs constantly weigh new features against stability and backwards compatibility. The bias is toward reliability. Shipping something new that degrades existing behavior is worse than not shipping at all.
Saying no to scope. Stripe PMs cut scope aggressively. The goal is to ship the smallest useful thing, learn from real usage, and iterate. This sounds like standard agile practice, but the stakes are higher when your API changes affect thousands of integrations. Scope creep at Stripe doesn't just delay a launch. It increases the surface area for bugs in financial transactions. For more on the discipline of cutting, see the art of saying no.
Regulatory constraints as a planning input. PMs can't just ship. Features that touch money movement, data storage, or cross-border transactions may need compliance review. That review can add weeks. Senior PMs learn to plan around regulatory timelines by starting compliance conversations during discovery, not after specs are finalized. The PMs who ship fastest are the ones who build regulatory review into their project plans from day one.
The Craft
Writing as a PM skill. This can't be overstated. At Stripe, written communication is the primary medium for influence. PMs write product specs, strategy docs, launch plans, and post-mortems. The quality of the writing directly affects how well ideas travel through the organization. PMs who write clearly get faster alignment, fewer misunderstandings, and better outcomes.
Metrics rigor. Stripe measures everything. PMs define success metrics before building starts, track them post-launch, and run retrospectives on whether the metrics moved as expected. This is standard practice in principle but Stripe enforces it with more discipline than most. A launch without pre-defined metrics wouldn't get approved. If you're building this habit, measuring product roadmap success is a practical starting point.
Customer empathy through support. PMs regularly read support tickets and sit in on developer calls. This isn't a quarterly ritual. It's a weekly habit. Direct contact with developers who are integrating Stripe's APIs shapes product intuition in ways that dashboards can't. PMs hear the exact words developers use when they're frustrated, confused, or delighted. That language feeds back into API naming, error messages, and documentation.
Tool Stack
- Jira for project tracking and sprint management
- Internal tools for payments monitoring and transaction debugging
- Figma for design collaboration on dashboard and UI features
- Google Docs for 6-page narrative documents and decision memos
- Slack for day-to-day communication across pods
- Custom internal dashboards for real-time metrics and experiment tracking
Key Takeaways
- Writing skills compound. PMs who write well influence more decisions and get faster alignment across teams.
- Regulated industries require longer planning horizons but reward thorough preparation. Building compliance into discovery saves weeks later.
- API-first thinking forces PMs to treat developer experience as a first-class product concern, not an afterthought.
- Small scope beats big scope. Ship the minimum useful thing, especially when changes affect thousands of integrations.
- Metrics defined before building, not after launching, is the difference between learning from a launch and just shipping one.