How great payments PMs think about product — and how these principles shaped every decision behind Cellix.ai.
Stripe's PM culture is distinct — and the Payments Intelligence team demands an even sharper version of it.
Technical depth is non-negotiable. Stripe PMs are expected to understand the systems they manage at a level where they can meaningfully challenge engineering decisions — not just translate requirements. On the Payments Intelligence team, that means understanding ML model architecture, fraud signal trade-offs, and authorization optimization at the API level.
Writing is the primary medium of decision-making. Stripe is famously a writing-first culture. Product decisions start with documents, not decks. A Payments Intelligence PM needs to write specifications that engineers, data scientists, and sales teams can all act on independently — bridging the gap between statistical rigor and merchant-facing value propositions.
User obsession means merchant obsession. At Stripe, the user is the developer and the merchant. The Payments Intelligence PM sits at the intersection — understanding how Radar's API surface affects developer experience while simultaneously understanding how authorization rate improvements translate to merchant revenue. Both perspectives must inform every decision.
Data-driven means hypothesis-first. Stripe PMs don't just look at dashboards — they form hypotheses, design experiments, measure outcomes, and iterate. On the Payments Intelligence team, this means designing A/B tests for authorization optimization, measuring false positive rates for fraud rules, and quantifying the revenue impact of every model improvement.
These principles guide how to think about product in the payments intelligence domain — from problem framing to shipping decisions.
Every product decision begins with a merchant problem — not a feature idea. Authorization rates dropping? Dispute volumes spiking? Compliance deadlines approaching? The PM's job is to diagnose the root cause and work backward to the product solution.
A payments PM who can't query their own data, interpret model outputs, and challenge statistical assumptions is operating blind. Ownership means understanding the data pipeline from raw transaction to ML feature to merchant-facing metric.
The best payments products are built iteratively — ship a rule, measure its false positive rate, tune it, ship again. Waiting for perfect specifications means merchants absorb fraud losses while the team debates thresholds.
An ML model improvement means nothing until it's translated into merchant revenue. The PM's unique job is to connect a 0.3% lift in authorization rates to a $2M annual impact for an enterprise merchant — and make that case to the sales team.
Payment optimization that works in the US may fail in Europe, APAC, or LATAM. Card network rules differ by region, issuer behavior varies by country, and fraud patterns shift by market. The PM must design products that handle this complexity without exposing it to the merchant.
Merchants don't buy fraud rules — they buy lower chargeback rates. They don't buy ML models — they buy higher authorization rates. Every product narrative, every roadmap item, and every stakeholder update must be framed in the language of merchant outcomes.
Building Cellix.ai was the ultimate test of these principles — applied to a production payments product with real merchants, real processors, and real outcomes.
The product wasn't conceived as a feature list — it started with the pain point observed at PayPal: enterprise merchants losing disputes they should win because evidence was assembled manually, inconsistently, and too slowly. Cellix automates evidence compilation to Visa CE3.0 and Mastercard specs because that's where the money is lost.
Before writing a line of code, the specification documented every processor's dispute API — field mappings, evidence requirements, submission formats, and response schemas across Stripe, Adyen, Checkout.com, Braintree, Square, PayPal, and Shopify Payments. Owning the data meant understanding 7 different API surfaces at the field level.
Rather than perfecting specs, the first version shipped with a single processor integration and basic evidence assembly. Each iteration added processors, refined the ML scoring model against actual dispute outcomes, and tightened response latency. The product improved because it was live — not because the spec was perfect.
The intelligence engine scores disputes across 40+ signals — but the merchant doesn't see signals. They see a win probability score and a recommendation: FIGHT, ACCEPT, or PREVENT. The technical depth is hidden; the commercial outcome is visible.
Different processors handle disputes differently. Different carriers provide tracking data in different formats. Different CRMs store customer history differently. Cellix normalizes all of it into a single evidence pipeline — handling the complexity so the merchant doesn't have to.
The product narrative isn't "AI-powered dispute management with ML scoring." It's "recover lost revenue." Every feature — evidence automation, win probability scoring, outcome learning — is framed in terms of the merchant outcome it delivers, not the technology behind it. The homepage doesn't mention the ML architecture until the third scroll.