High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / belief

Published · transcript-backed

Lenny Rachitsky: belief

11 Jul 2024 Lenny's Podcast Building product at Stripe: craft, metrics, and customer obsession | Jeff Weinstein (Product lead)

“We're not going to do anything that isn't driving this metric and goal that we have. And I think for teams like that, it's hard to hear just like, oh, someone's going to send you all of these problems that you experience.”

— Lenny Rachitsky

Source trail

Everything needed to verify it.

Speaker
Lenny Rachitsky
Attribution
Verified speaker
Claim type
belief
Recorded
11 Jul 2024
Publisher
Lenny's Podcast

Transcript context

…to match a bit of our incident process. So in an incident strike, like in many companies, pencils down, fix the problem, severity levels, non-negotiable Slack rooms happen, war rooms, all that stuff. You don't want to do that with every single bug, but we have a rubric of craft related tags for our bug system. And if it is a sort of a P0 bug, which is not an incident, right, it doesn't mean to put down your pencils. You do need to acknowledge it at Stripe within seven days. And even if it doesn't mean to fix it, it's like a person looks at it and says, "Hey, we're going to do it or not do it." That's a still pretty strong bar for a non-incident related craft issue. It feels just at Stripe, there's this cultural focus on we want to make the product great, we want to make the experience as great as possible. A lot of companies, it's just teams. We have this goal. We're not going to do anything that isn't driving this metric and goal that we have. And I think for teams like that, it's hard to hear just like, oh, someone's going to send you all of these problems that you experience. There's the negative version where the founders goes through the product like a CO of a larger company, just, oh my God, look at all these problems. You need to fix these immediately. And a lot of times it's completely distracting from the things they need to do, the goals they're trying to drive, things that really, really matter that the CO may not be thinking about. And it feels like you're trying to find this balance of here's problems that exist. You don't need to fix them. You probably should. Here's the most important stuff. But also there's often you find a correlation between make the experience better, you're going to do better. There's a huge amount of trust here involved in your colleagues, which is we want to provide teams great information and the best teams welcome that information. It doesn't mean that it comes with a auteur opinion from the outside world that says you must do X. We have a rubric on some of the craft related bugs, but again, we let the teams relabel them. And so maybe it's actually not a P0 from their eyes and that's the trust we put in the teams. I think that the failure mode is when you don't look. And so we need unnatural, safe, fun lore that gets us out of our chair and into the customer's mindset. Best is if it's you and you're your own customer, okay. Second best would be sitting right next to the customer in the outside world and then like, okay, fine, I'll take a third best, which is pantomime the customer and enforcing you don't use any internal knowledge. If you have practices in those three categories, I'm comfortable with the failure modes.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.

Search evidence