Lenny's Podcast: Product | Career | Growth
00:49:45 · Lenny Rachitsky, Amol Avasare
[00:49:45] S0: This is such an interesting insight you're making. It's so counter to how a lot of people are thinking PM is evolving. What I'm hearing here is, because PMs are so behind, because engineers are just getting so much done, there's many people here, "Okay, you need to be prototyping, you need to be shipping PRs as a PM." What you're saying, which I completely agree with, is your time is much better spent helping PM basically, and helping the engineers become better PMs themselves. And the leverage there is a lot higher than you spending time coding, shipping PRs in most cases. [00:50:17] S1: I think that's true in certain circumstances. I think that as a smaller company, I don't know that that's the case. In a smaller company where it's all hands on deck, I think you probably need to be shipping. I think if you're in a company where budgets are very tight, and engineers are very tight, and you're not able to just hire because money's unlimited, then you need to do what is needed to accelerate the impact your team's going to have. Right? So there's going to be a number of cases, where as a PM, the right thing to do is to be like, "Screw it. I'm shipping and I'm going it the whole way." But I'm talking here more about the larger companies, more scaled businesses. Yeah, if you have 20 engineers, is it the highest use leverage of your time to ship an extra feature, or figure out how do I up-level everything that we're doing, get the user insights better, et cetera?
00:50:17 · Amol Avasare, Lenny Rachitsky
[00:50:17] S1: I think that's true in certain circumstances. I think that as a smaller company, I don't know that that's the case. In a smaller company where it's all hands on deck, I think you probably need to be shipping. I think if you're in a company where budgets are very tight, and engineers are very tight, and you're not able to just hire because money's unlimited, then you need to do what is needed to accelerate the impact your team's going to have. Right? So there's going to be a number of cases, where as a PM, the right thing to do is to be like, "Screw it. I'm shipping and I'm going it the whole way." But I'm talking here more about the larger companies, more scaled businesses. Yeah, if you have 20 engineers, is it the highest use leverage of your time to ship an extra feature, or figure out how do I up-level everything that we're doing, get the user insights better, et cetera? [00:51:14] S0: Yeah. And I think there's also an element of shipping to learn, building a prototype so that you can have a better opinion. A lot of people talk about just, "I'm just going to try three things, see how it goes and that'll help inform the roadmap." This is now the PRD, is look at it instead of talking about it. So there's a lot of value there still.
00:51:14 · Lenny Rachitsky, Amol Avasare
[00:51:14] S0: Yeah. And I think there's also an element of shipping to learn, building a prototype so that you can have a better opinion. A lot of people talk about just, "I'm just going to try three things, see how it goes and that'll help inform the roadmap." This is now the PRD, is look at it instead of talking about it. So there's a lot of value there still. [00:51:29] S1: That's very true. I think that's a great point. So even for me now where we've got number of PMs, we've got many engineers, there are certain times when I'm like, "I want to articulate the idea I have in my head." It's just better for me to prototype it and show it. Right? So I think that is really important. And then we are very scrappy. So we're a big company by name, valuation, but we're extremely scrappy, and just the focus internally is just minimize bureaucracy and just go. And so probably 70%, maybe 60, 70, 80% of what we ship does not have a PRD. I'm averse to PRDs. I think I just hate documentation. I'm just like, "Go, go, go. Just cut the blockers." 20, 30% of stuff where it's like, it's important, it's really important to get right. The documentation should be really good and that people should spend a lot of time on it. But by and large, I think PRDs are just outdated at this point, and you can just kick things off with a good team without needing to do that sort of thing.
00:51:29 · Amol Avasare, Lenny Rachitsky
[00:51:29] S1: That's very true. I think that's a great point. So even for me now where we've got number of PMs, we've got many engineers, there are certain times when I'm like, "I want to articulate the idea I have in my head." It's just better for me to prototype it and show it. Right? So I think that is really important. And then we are very scrappy. So we're a big company by name, valuation, but we're extremely scrappy, and just the focus internally is just minimize bureaucracy and just go. And so probably 70%, maybe 60, 70, 80% of what we ship does not have a PRD. I'm averse to PRDs. I think I just hate documentation. I'm just like, "Go, go, go. Just cut the blockers." 20, 30% of stuff where it's like, it's important, it's really important to get right. The documentation should be really good and that people should spend a lot of time on it. But by and large, I think PRDs are just outdated at this point, and you can just kick things off with a good team without needing to do that sort of thing. [00:52:34] S0: Say more about that. What do you do to help make sure, because people can build so fast, or spend a lot of time going in the wrong direction, ship things that are not what you're asking? How do you kick off a project and clarify, "Here's what we're doing"? Is it just a conversation or is there anything beyond that?
00:52:48 · Amol Avasare
[00:52:48] S1: It really depends on the size of it. And this kind of goes back to the two-week thing. So why we have that two-week thing, it's more like, how do I have some filter to say if we're investing heavily into something, we should apply more thinking behind it versus if it's a smaller set of investments, just go for it? And as a growth team, again, you do have a decent amount of these smaller things that you do. So for very small changes, like, "Oh, there's a thing coming. We need to have an upsell for it. What is it the thing we're doing?" This is just on Slack. This is just purely on Slack. It's just messages back and forth. And I think it also depends on having a good caliber of engineer in there, but engineers can understand, like, "Hey, I know you said this, but what about that for the audience?" And so we're lucky we have good product-minded engineers in that sense, but all these smaller things are very much just on Slack back and forth, and that's what you do. For the larger things, I think I very firmly believe in a proper kickoff. So we still do ... Just there's so much going on at this place. No one's got time, no one knows what's going on. And so doing a cross-functional kickoff, get legal, get safeguards, get everyone in the room and just be like, "This is what we plan to do. What do you care about? What do you care about? What do you care about?" That 30-minute meeting for larger things is just, I think, still so important to just streamline all the mess that may happen later if you don't do that work early on.
00:54:17 · Lenny Rachitsky, Amol Avasare
[00:54:17] S0: What's your approach to crafting that PRD in those cases? Is it ramble into Claude? Is it, do you have a template? [00:54:24] S1: Even in those cases, there are times I don't craft a PRD because everything's moving so quickly, right? So there's still some of those cases where I just set up the meeting and then five minutes before, I'll put it into Cowork, some of my thoughts, what credit. "Here are the things that I need to think about," spin up a basic doc and we use it to talk. Other times I won't even have a doc. But if I am creating a PRD, I have basically, a skill that they've created, and then there's projects with all the previous PRDs in there, and then it's pretty simple. It has the format down so I'll just say, "Here are the things I care about. Here's the why. Here's the problem," and flesh out the key considerations, flesh out the cross-functional stakeholders, those types of things. But again, my default is if I can avoid the doc and if we can just jump to action, then that's what we should do and increasingly just jump to prototyping the thing. [00:55:24] S0: Yeah. And that's where I think it'll get so interesting once we can automate more of that, just like your assistant talking to the legal assistant, just ironing out all these little, what's important to you, what's important to the ...