Building great products at Stripe: craft, metrics, and customer obsession

Executive overview

Most product failures trace back to solving problems people don't actually need solved. The antidote is relentless direct contact with paying customers, a single customer-facing metric, and structured practices that force teams back into the customer's perspective.

Jeff Weinstein spent six-plus years as product lead at Stripe, scaling payment infrastructure to hundreds of billions in volume and growing Stripe Atlas to one in six new Delaware corporations. His approach pairs urgent bias for action ("go, go, go") with long-term compounding investment in infrastructure and customer trust.

The core insight: great metrics and great products both start from the same place — what does the customer actually need, measured from their perspective?

Go, go, go plus long-term compounding

• Urgency and optimism unlock fast learning; they are not enough alone.
• Some goals require layers of infrastructure before results appear — payment method expansion at Stripe flatlined for years before becoming nonlinear.
• The discipline is knowing which problems need a one-afternoon fix and which need a three-year platform investment.
• Proof of existence beats proof by debate: send the single piece of paper, ship the one version, then compound from there.

Talking to customers

• Customers announce themselves on the internet; not listening to them requires an alternative theory of where business comes from.
• Don't pitch. Open with silence and broad questions: "What would you take off your plate today if you could?"
• Respond to customer messages immediately — even a "I'll follow up tomorrow" creates a direct human channel that scales trust far beyond what brand alone can do.
• Discount all feedback from non-paying users to zero; paying customers and friends-testing-your-beta are completely different signals.
• Use payment as a forcing function: willingness to pay is not the same as paying.
• Speed matters. The moment a customer spends their finite time giving feedback is a gift — meet it with matching urgency.

Filtering and managing customer feedback at scale

• If customer volume is overwhelming, that is a good problem; take a breath before optimizing it away.
• Use structured prompts to self-select engaged customers: ask for a short video or three to five bullet points.
• Bound feedback programs with a name and timeline — "Bug Finder Program, three days" — even if arbitrary; it creates permission and closure.
• Pattern-match toward your most ambitious, technical, fastest-growing customers; you don't need thousands, you need five to ten who represent where the world is going.

Picking metrics

• A metric is a numerical representation of the value produced for the customer — measure from their perspective, not yours.
• "How many people logged in" is internal. "How many people accomplished what they came to do" is customer-facing.
• A small number of carefully named metrics forces tradeoffs and keeps teams oriented without daily re-explanation.
• Metrics enable stopping: once a tactic reaches its target, you can put it down and move on.
• Name metrics so they are motivating to say aloud — "companies with zero support" is better than a database field string.
• Dashboard hygiene matters: same x-axis, minimal decimal places, a single canonical URL. Teams that look at their metrics daily outperform those that don't.

The Atlas metric case study

• When Jeff joined Atlas, only 15% of founders completed incorporation with zero support tickets.
• The metric chosen: percentage of founders reaching zero support tickets through the entire process plus a two-week buffer.
• Rather than averaging support volume, the team tracked a binary per cohort — zero tickets or not.
• Engineers were each assigned a support ticket topic to own end-to-end, turning the whole team into customer-facing problem-solvers.
• Over 18 months, the zero-support rate went from 15% to 85%, and market share followed the same curve.

Users having a bad day

• Emit a log line every time a user hits a known friction point (404, late payout, excessive payment declines, repeated 2FA).
• Build a stacked bar chart of "bad day reasons" by frequency.
• Any bad day event that surprises the team — one they didn't know to count — is immediate action: get it on the chart.
• Once counted, teams can make informed decisions about which bad days to eliminate and when.

Study groups

• A study group is four to eight people — any role — who pretend to be a fictional company using Stripe products for an hour.
• Rule one: you do not work at Stripe. No internal knowledge, no shortcuts, no breaking character.
• Rule two: no solving, no filing bugs, no critiquing. The only goal is practicing empathy.
• Seeing teammates struggle to complete a task is more motivating than customer feedback because rationalizations ("they had a weird setup") don't apply.
• Stripe ran more than 25 study groups with 250+ participants in just a few months; teams now run their own.
• Outputs feed existing bug-priority systems; craft-related P0 bugs require acknowledgment within seven days.

Product quality and business results

• There is no faster path to revenue than making something customers genuinely need and experience as excellent.
• Product experience includes the sales process, the support process, the onboarding call, the FedEx envelope — anything the customer touches.
• When self-service contacts are full of "how do I migrate?" or "what are my options?", those contacts are the product; make them a great human interaction backed by software.

Getting things done at a large company

• Align people with direct customer stories first, then sketch the unconstrained ideal solution with a Sharpie — not Figma.
• Proof of existence (we sent one piece of paper; it arrived) is more persuasive than proof by theory.
• Ask for less permission on each step; trust compounds as small bets succeed.
• Public metrics replace internal update decks — anyone can see how a product is performing without a presentation.
• Bring real customers into team meetings and design sessions; founders who use Atlas have drawn product diagrams that went straight to engineering.
• Not having things be your idea is an advantage: 50 customers yelling about the same problem makes the case better than any internal advocate.

Building Stripe Atlas

• Atlas began in 2016 after Stripe employees met founders who had to fly to the US to incorporate — a clear burning problem.
• The 83B election (a one-page IRS filing with a 30-day hard deadline, sent by snail mail, with no confirmation) was automated by starting with go, go, go: one engineer sent one piece of paper to confirm it was possible, then the team built infrastructure over three years.
• As of launch: clicking "go" on Atlas handles incorporation, EIN, 83B election, share purchases, and banking access — one day instead of weeks.
• Atlas is a team of 10. They only take on work they can automate and be the only provider of at scale.
• 1 in 6 new Delaware corporations now start on Atlas; Atlas-started companies generate $5 billion in annual revenue.
• Over 20% of multi-founder teams on Atlas have co-founders in different countries.

Advice from Stripe's founders

• Patrick Collison, on Jeff's first quarterly business review (written one month into the job): "This doesn't sound like you yet." — permission and expectation to bring a genuine personal perspective, not a generic report.
• John Collison, nine months in: "You are one of the best people I've ever worked with at solving problems three through a hundred. But I need you stuck on problems one and two." — the most urgent action should be on the hardest problems, not the most tractable ones.

Recommended books

• High Output Management — Andy Grove; treat your output as the sum of everyone you work with, not individual effort.
• Orbiting the Giant Hairball — Gordon MacKenzie; staying creative and sane inside large, rule-heavy organizations.
• Seven Powers — Hamilton Helmer; business moats, with process power underrated precisely because competitors assume they have it.