Julie Zhuo: belief

Transcript context

…That's funny. That's the term I've been actually using more and more. I used to orient this podcast and newsletter around product managers, and then I started using just product to be a little more broad, and now I'm actually using that term builder. And I love that term because it's exactly what you're saying. And this is very much a theme that comes up often in these conversations more and more, just the lines are blurring. I'm curious at your company, how does that look? What are you doing differently? What are you seeing on the ground within your company that maybe would be different from a few years ago? So we have eliminated more roles. For example, we thought we would need a bunch of product managers. It's turned out that actually, if you don't have a product manager, I know this might be going against a little bit of the ethos of where Letty started. But I find that sometimes when you have like a designer or a product manager, and let's say I'm an engineer, then when I have a problem like, oh, I need to figure out the product definition. My default will be, well, I've got these people and that's kind of their job description. So I'm just going to delegate that to them. And I think that in doing so, you know, again, where we want to be polite, we want to respect everyone's lanes. I think that's a missed opportunity for that, you know, if I'm the engineer to be like, wait a second, I should probably focus a lot too. Like I need to understand and have an opinion about what to build or what the user experience is. And so we found that if we actually make teams smaller and we kind of even like in the past, you know, pre-AI, like just to have fewer of these, it allowed everyone to be like, oh, wait, we don't have a product manager on the team. Okay. So communication's up to me, figuring out how we get greatest value to users is something that is now strictly in my charter. And so that's why I'm such a big fan of like, we can make teams smaller and we can eliminate these lines. Sure. Again, there's still, I'm not trying to say like everyone has to do everything. We still can respect the fact that you might be much better at this particular skill than me, but it's less about the role and it's more about the specific context that we're in. And I find that whenever you have teams and you empower them to be able to take more action on their specific context, rather than having these higher level rules or policies, or like, this is how it's supposed to be. then you get better work, you get faster work, and you get happier employees because people feel like they actually can have the power to create the thing that they want. That's really interesting that just that constraint of not having a PM makes the engineer realize they're not going to wait for someone else to do it. They have to figure it out. The obvious kind of trick there is they have to be good at this. It's a very different job from engineering to be really good at articulating. Here's the problem we're going to solve. Here's why it's important that we're solving. Here's how we're going to prioritize everything we're thinking about. Here's how do we get alignment. Is there something you do differently when you're hiring these engineers knowing you're going to probably not hire PM? And just that feels really hard to hire for someone that's really good at all these things.…

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