Silence, Sharpies and Support Tickets: Jeff Weinstein's Product Playbook from Stripe

Lenny Rachitsky begins with a quote in which Weinstein explains why he stayed in a class after doing poorly: he wanted to be in the class where he was potentially the worst. Weinstein says part of that was rationalization, since he really was not good at the classes, but the attitude also grew out of his unusual K through 12 school in Baltimore. Students there chose their own courses and had to think about why they were in school.

He recalls a high school History of Science class that spent a year studying things science once believed that turned out to be false. The teacher also gave students a ticket for each class, priced by dividing tuition by hours, and each day they handed it over only if they judged the class worth the cost. In college he studied the same materials as a friend in an advanced microeconomics class, got the bottom grade while his friend got the top, and told his professor he wanted to stay anyway.

He started as an English major but kept playing with computers and liking math, and noticed that the leaders of the companies he admired had technical backgrounds. So he added a computer science degree midway through and finished with both.

The first item on Weinstein's list is "go, go, go ASAP plus optimistic, long-term compounding approach". He sees every day as a chance to inject energy, for example by turning "due tomorrow" into "due today", and says that attitude spreads to others. Over time he learned that some goals, like his startups' and Stripe's, cannot be solved in an afternoon and need layers of infrastructure, services and partnerships, like the underwater part of an iceberg.

His example is Stripe's expansion to more countries and payment methods. For the first seven or eight years, additions were roughly flat even though the world wanted them and many people were working hard. Pouring more energy into Thai payment methods or UK bank transfers did not help, so the team stepped back, asked what would need to be true in ten years, and went slower by building internal platforms and sending people around the world to use these payment methods.

The line stayed flat for a while, but then growth turned nonlinear and Stripe went from about 10 payment methods to over 100. Someone had suggested locking everyone in a basement to get from 10 to 50, which would have been the startup-intensity answer. Weinstein calls the decision formative and says he still struggles to balance the two mindsets.

Asked why he emphasizes craft and quality, Weinstein works backwards from a failure. His earlier startup built a collaborative tool for SQL analysts and got a couple hundred customers. When the service went down for 10 to 20 minutes, customers barely complained, and a year later he realized that silence meant they did not have product-market fit.

From that he concludes that craft is a dessert you get after the meal of solving a real problem. His obsession is finding problems that people will pause their entire day to solve. No amount of beauty or delight, he says, can fix the issue of building something people do not really need.

He adds that people get out of bed for their first problem, not their second, so you should not pitch while trying to learn. When a founder opens a call with a demo, he says, they have anchored the conversation and likely missed the customer's burning issue. Instead he asks things like what is in your inbox, what grinds your gears, or what you would take off your plate with a magic wand, and then stays quiet.

Silence can even build the roadmap. At Stripe, customers repeatedly complained about verifying that a sign-up was a real person, which led the company into identity even though it was not originally an identity company. In his view this beats long surveys and long build cycles.

Weinstein says the business comes from customers, and the internet lets people announce what they care about, whether in a Reddit thread or a screenshot of a bad support exchange. He is surprised that so many teams do not talk to customers directly, and admits his motivation is fear of repeating his earlier mistake. Doing it takes a little nervous gumption, like introducing yourself at a cocktail party, but the loop becomes infectious inside the company too.

Even at Stripe's scale he says you can pattern-match to the customers who represent where the world is going, such as the most ambitious, technical and fast-growing. If you are text-message friendly with five or ten of them, you get so much direct signal that you forget how you worked before. Speed matters too: when someone takes time to write about your product, he treats that as a top-priority alert and will leave a meeting to send a quick reply.

He tells of a bug in Atlas legal documents that handed out 25 shares instead of 25% of the shares, which a founder spotted and tweeted about. The team fixed it and regenerated the documents quickly, and the founder, who has a law degree, offered to review documents in the future. His bar is to turn an upset customer into a promoter, not just to solve the problem.

On avoiding overload, he suggests asking people for a screenshot, a video or three to five bullet points, which self-selects those who care and are worth following up with. He also bounds the effort with a made-up program: a single tweet announcing a Stripe bug-finder program produced 65 videos and dozens of issues.

Weinstein discounts feedback from friends to zero. Builders tend to have friendly friends who use the beta and say they like it, but his target is a specific person, whom he calls Sarah, who has the problem right now and will pay to fix it. He wrote the rule down because the pull of friendly feedback is so strong.

Paying is a forcing function. Sarah will happily ask for features until you say the product costs $10,000 with a full refund, at which point she may say it would need to solve a specific problem to be worth that, and then you learn what is of value. He recommends improv classes to practice the silence that draws this out.

The same applies to enterprise deals. When a large customer promises a big contract if you build a long feature list, he suggests asking them to wire $1 million and promising to send it back on request. If they refuse, that is a useful signal; if they say yes and ask how to train their teams faster, you are on the faster path to success.

He stresses that being ready to pay differs greatly from paying, because paying means someone exchanges something of value for a promise. So he has founders practice charging him by sending a $1 invoice or payment link, so that their first real charge will not feel strange. Another trick to get people talking is to ask about their regular life, such as what they did yesterday.

Weinstein believes a product manager's responsibility is to produce product-market fit, which is shown by charts going up and to the right on one hand and tweets on the other. He treats quantitative and qualitative evidence as equals. Good metrics, he says, are a numerical representation of the value delivered to the customer, measured from their perspective, and a small number of them forces trade-offs that stop teams from arguing endlessly over what to build.

When he began working on Atlas, he looked at the support tickets and found they were almost all sad. Asking why someone would recommend Atlas to a friend, the team defined a metric: the share of companies that get through the whole incorporation process, plus two weeks of buffer, with zero support tickets. Only 15% did at first. Over about 18 months they raised it to 85%, and market share followed the same shape.

The metric also helped the team work. Engineers could be assigned a group of tickets to investigate, write the spec and build the fix, which turned them into PMs and led to work such as automated 83(b) elections, a custom signing service and click-through flows. Weinstein says being able to wake up, open the same metric and know what to do beats re-deciding priorities every month.

Lenny raises the risk of perverse incentives, such as a team making it harder to contact support. Weinstein says they watch several metrics but optimize one, and each engineer owns a tactical key result such as a faster risk-review decision. He likes charts that go up and to the left for cohorts, and reports that nearly all customers now receive their risk review within an hour.

Weinstein notes that the zero-ticket metric suited Atlas because founders ask their friends how to start a company, so delighting existing customers lined up the metric, the tactic and the go-to-market. He would export a different metric to anyone: the "users having a bad day" chart. Teams emit a log line whenever a user hits a problem, such as a 404, a payout a day late or many payment declines, and stack them in a bar chart.

The frequencies, he says, can be mind-blowing, and anyone on a team can add a new bad-day reason. When a customer incident occurs, he checks whether a bad-day reason already exists; if not, the immediate action is to count it. Lenny tries it live by listing his own bad days as a Stripe customer, such as slow loading or login trouble, and Weinstein says he knows the URLs of those charts.

He also cares about aesthetics. Metric names should be short and emotional, like "companies with zero support", so they become currency inside the company, and dashboards should be tidy, with sensible significant digits and a shared x-axis. Stripe can see which teams actually open their dashboards, which he finds a strong predictor of how customer-obsessed they are.

His rule is that if a metric is not on Stripe's internal Go Metrics page, he will not look at it, because one-off charts cannot be interrogated and definitions are often wrong at first. He describes the stages of grief: excitement, confusion, discovery that it was counted wrong, and a ritual of revisiting the live URL in team meetings. That attention is why you cannot have a thousand metrics.

Weinstein says products rot over time: a smooth end-to-end flow turns into a broken mall with busted doors as teams ship other things. Friction logs, in which one person plays a customer and writes up the experience, work but are a high bar. So he created Study Groups, in which four to eight volunteers from any role, such as support, sales or infrastructure engineers, pretend to be a made-up company with a goal like selling tickets to Dolphin Aquarium Industries.

There are two rules. First, you do not work at Stripe, and if someone uses insider knowledge, he pauses and asks them to redo it. Second, the group is not there to solve problems, critique or file bugs; it is only about practicing empathy and moving through the product, which can take an hour or more.

Stripe has run more than 25 groups, and over 250 people took part in the last few months of 2024, with reactions like surprise at how hard some tasks were. He thinks it works because nobody is defensive about a product that is not theirs, the pace is slow, and it is simply fun, with people inventing company names and playing a CTO. Teams have since adopted it themselves, and he plans to train Study Group captains.

Outputs feed into existing processes rather than a new one. Craft bugs get tags, and a P0 craft bug, which is not an incident, must be acknowledged within seven days, though teams can relabel it. Weinstein says watching colleagues struggle with your feature is more motivating than customer complaints because you cannot dismiss them as having a special setup.

Lenny asks how this obsession with experience connects to revenue. Weinstein says that if anyone has a faster path to revenue than getting it from customers, he wants to hear it, but he finds revenue is usually part of the product experience. Internal sales tools, partner onboarding and vendor processes can all be examined with Study Groups or friction logs.

He tells of a healthcare company founder whose self-serve funnel generated lots of support requests. Weinstein pointed out that those requests were really sales contacts, and the product should instead hand those moments to a person who already knows the customer's name and context. He also praises Fidelity, whose representative walked him through a 401(k) rollover by sending an envelope with a second envelope inside, which he calls "that is product".

On the balance between fixing everything and hitting goals, he says the failure mode is when you do not look at all. The best case is being your own customer, the second best is sitting next to a real customer, and the third best is pantomiming the customer with no internal knowledge. He wants teams to receive information while keeping the freedom to relabel it.

Atlas began in 2016 when Stripe employees heard that entrepreneurs abroad had to fly to the United States to form a US company. Weinstein calls needing an airplane to run a business a burning problem. He says Stripe believes the number of startups is not finite, citing Instacart, which signed up with a Gmail address and then delivered food during Covid.

Over the years Stripe automated the complexity, notably the 83(b) election, a one-page IRS form with a 30-day deadline that must be mailed with no verification and no redo. As the podcast launched, Atlas offered one-click company setup, handling share purchases, banking access, the tax ID and the 83(b) filing in the background, so a founder could quit on Sunday night and be ready for business within a day or two. He says it took three years to get there.

He reports Atlas had an NPS above 80 with almost a 50% response rate even before the automation, but they continued because automated customers charge their first customer sooner, in about half the time. More solo founders use it than before, the 2024 startup cohort reached $50 million in revenue twice as quickly as the 2023 cohort, and over 55,000 Atlas companies generate $5 billion a year. About 20% of surveyed founders said they would not have started without Atlas.

The team is ten people, and Weinstein says they pick up only work they can automate. For 83(b), go-go-go meant having one engineer mail a single piece of paper to prove it was possible, while the long-term compounding meant carefully choosing third-party mail vendors and backups, with SLAs, alerts and playbooks. Each year they write a document titled "Should we do this ourselves?", and each year the answer is no. He also notes that the team is majority women, built deliberately by shaping the candidate pool early.

Asked how he shipped a zero-to-one product inside Stripe, Weinstein says it helps for the idea not to be yours: talk to 50 customers who say the same thing. He then storyboards the unconstrained ideal solution with a Sharpie, like a Pixar-style storyboard, and gets one working version quickly. Proof of existence, such as holding the physical piece of paper, is more powerful than proof by theory or debate.

Shared metrics build trust without big update decks, since anyone can open the metrics page and see progress. He also says the economics must be shown: whether a product is a customer-acquisition engine or a moat, its metrics have to say so. Atlas has had several leaders, and he rotated roles one month at a time with the current lead, Hayley Halvarsson.

He recounts competing with AngelList, which launched incorporation, banking and cap tables just as he started on Atlas. Stripe kept a long-term approach and an open relationship, sharing a Slack channel and discussing 83(b) elections. Eventually AngelList's product lead called to say they were leaving incorporation and asked if Stripe wanted the business, and AngelList now points customers to Atlas, with data flowing back to AngelList and other partners such as Mercury and Carta.

His takeaway is that in the end they are not competitors but alternatives, and if you care about your customer you care about their alternatives. Lenny recaps the playbook of storyboarding, solving a burning use case, showing tangible progress, keeping momentum and making the business case.

Weinstein adds that you should bring the earliest customers into the team as soon as possible. Atlas invites founders to team meetings, pipes feedback into a Slack channel and follows up on any NPS score that is not a 10. His team also invites founders into Whimsical to draw the dashboard they want, which he calls giving customers write access, not just read access, to the company.

He recalls his father's line that you can screw up a sentence if it begins with "The customer", and how his father sometimes put a chair in meetings for the invisible customer. He invites listeners to send him cold emails, saying his love language is Loom videos of bugs.

In the lightning round he recommends High Output Management, Orbiting the Giant Hairball and 7 Powers, with process power and counter-positioning as his favorites. His life mottos are "go go go" and "let's make some mistakes". He also names Raycast and CleanShot as favorite tools.

He closes with advice from Stripe's founders. Patrick Collison told him his first draft of a quarterly business review did not yet sound like him, so he rewrote it in his own voice. John Collison told him he was great at solving problems three through 100 but needed to be stuck on problems one and two, after which Weinstein started bringing only the hardest problems to their meetings.