High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / evaluation

Published · transcript-backed

Jeff Weinstein: evaluation

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

“I will say though that it is difficult to watch one of these Study Groups and if you are the team involved in some piece of it and not want to act on it, because seeing your fellow teammates struggle to use your thing in some way is more motivating than the customer because you can kind of always say to the customer, " Well, they didn't really know," or "They have some special setup.”

— Jeff Weinstein

Source trail

Everything needed to verify it.

Speaker
Jeff Weinstein
Attribution
Verified speaker
Claim type
evaluation
Recorded
11 Jul 2024
Publisher
Lenny's Podcast

Transcript context

…I love that and clearly it's worked for Stripe. Just one last question. I want to talk about Atlas and dive into just like what is Atlas and how is it doing and things like that. I know there's some new stuff coming that you're going to share, but one last question about Study Groups. How do you decide what product you're going to pick to do a Study Group on? And then what is the expectation with the result? I imagine there's a PM sitting around like, "Oh my God, I just got this 10 page report on all the problems." So initially, I just made up a list of stuff that I thought would be fun to Study Group to kind of kick it off. And now, because it has a bit of an internal brand and it's exciting, and people who have gone to a Study Group say nice things about Study Group there, they actually proactively say, "Hey, we should Study Group blah," or "We're launching something next week. We should Study Group it before it goes out the door." Or now I actually just have a huge backlog of things to Study Group based on what people want. And now we're again franchising it. So we're going to have Study Group captains and people run their own Study Groups, and so we can really scale this behavior. But we did our first Study Group of an internal tool recently. And so, that I think is going to catch on just anything at all can be Study Group. It just takes about an hour and a couple of people and you open up the Zoom and that's it. And then for expectation wise, look, it is so tempting to put more regulation on something. Okay, well, everything coming out of this program needs to be scored and rubricked and have SLAs. That is extremely reasonable. As some of these next steps, we do notice things that are of serious issues and we have some formal processes inside of Stripe for elevating bugs to certain priority levels that get tagged and have SLAs for teams to acknowledge and review. And so we kind of funnel the outputs of a Study Group into our already existing formal processes rather than having some new special thing that's going to bother a particular team. I will say though that it is difficult to watch one of these Study Groups and if you are the team involved in some piece of it and not want to act on it, because seeing your fellow teammates struggle to use your thing in some way is more motivating than the customer because you can kind of always say to the customer, " Well, they didn't really know," or "They have some special setup. " Well, they didn't really know or they have some special setup. You probably shouldn't say those things, but you can kind of rationalize it, whereas a group of people incentivized to have actually accomplished it, who got together to do so painstakingly slowly not being able to do so if that's not what excites you as a product person to want to solve, this thing's not for you. But then again, you have your own organization system, you have your own things you need to ship and study group doesn't have a mandate that comes from it. We have our own. It's more of a cultural piece of information that is very high signal and then people tend to use that high signal for good prioritization. I will say though, that we have added the SLAs to certain bug levels that begin 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. 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.…

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

Search evidence