Lenny's Podcast: Product | Career | Growth
00:44:00 · Amol Avasare, Lenny Rachitsky
And so we're seeing that that's putting a lot of strain on PM and design. And it's not everywhere. I look at teams like Claude Code and I think that, or because that product is so technical, it's probably just the right thing, where the PMs are all basically engineers themselves anyway. But we had a product, like a PM lead on site the other week, and we were all just talking about this where across the board we're feeling this, where PM and design is just squeezed. It's just absolutely squeezed. And we're like, "Is the right thing here, we just need to actually hire a ton more PMs?" And it could actually be where we land. On growth, how I think about it is, one, we are hiring a number of growth PMs. We desperately need people who are very, very good, and we are hiring. So if you are excited by what we're doing and you know growth, please feel free to apply. Would love to chat and- [00:44:58] S0: Maybe craft an amazing cold email to you.
00:45:00 · Amol Avasare
[00:45:00] S1: Yeah, yeah, yeah. Feel free to craft that email. So that's one, is I think we are going to be hiring in a number of PMs. But then the second thing that we do is we very much hire product-minded engineers. I think this has always been the best thing to do in growth. You always want to have the engineers coming up with ideas, et cetera, especially people who can really step in as mini PMs if the PM is absent. And so we're basically more formally leveraging that right now because we are so stretched. So, the frame that we have is that if a project is two weeks of engineering time or less, then the engineer is on the hook to effectively be the PM for that. And so that means things like talking to security, talking to legal, talking to cross-functional stakeholders, and the engineer is very much driving that. The PM will get looped in and they'll advise if needed. And if something's wildly going off track, then they'll step in, but they're much more in an advisory capacity versus execution. If a project is more than two engineering weeks, then the default is that the PM should continue to be on the hook for making that go well. They'll still delegate more to eng, but they're squarely accountable. It's not fully clean-cut. It's like, use your head. If this is a one-week thing, but it's extremely controversial, the PM should probably still drive it. But that, I think is the approach that I expect more companies will start to do, which is just deputize the engineers to be mini PMs. Now, not everyone can do it. So the PMs, the engineers who are more product-minded, suddenly their value goes up significantly in order of magnitude. And then I think we will probably still be hiring a lot of PMs.
00:46:52 · Lenny Rachitsky
[00:46:52] S0: There is so much interesting stuff I want to follow up on here. Okay, so one is this idea of two weeks, just briefly. I always joke as a PM, you can go on vacation and be away for a couple of weeks from your team and things are going to be all right. There's a momentum, there's a plan, people keep operating, and it feels like that's kind of this rule of thumb you use of just, "Okay, if it's a two-week project, you'll be all right without a PM. You can handle it." I love that those two connect. Okay. The other here is so interesting. So you're saying here that because engineers are so accelerated, and this all makes sense, PMs and design are kind of just like, "Holy." It feels like hard to keep up with this pace of engineering. And what you're saying is you need more and more PMs to keep up. That's one route, or it's engineers that can PM essentially, which is so funny. It's just like, okay, great news for the product managers until more of the PMey stuff can be done by AI. But that's a really interesting trend. I don't know, is there anything else there just like, "Oh wow, we actually may need more PMs"? The ratio of more PMs, fewer engineers might be the future.
00:47:52 · Amol Avasare
[00:47:52] S1: Yeah. I think it just really depends on the industry, the size of company. Any company where you're building something that's much more developer-focused, you're going to rely on the engineers a lot more. Earlier companies, you don't have as much of this cross-functional coordination, stakeholder alignment nonsense that you need all these PMs for, so you can get by with less. But then as a company scales, and if I think about, okay, now you have this ratio where maybe the one PM became two PMs from productivity, that the five engineers became 20 engineers, the one designer maybe became three designers. If you think about what is the best use of time for that PM, I think this is a really interesting thing, of how much should PMs be actually shipping things themselves versus everything else? I think in the world where you're limited on engineering, the PM should definitely be shipping things. I think in today's world, it's a good way to get an understanding of the tools, which is really important. So the PM should be shipping for that reason. But if I'm one PM or two PMs and there's 20 engineers, I think about what is the incremental value I can add with my time? And is it actually shipping the 21st PM feature or is it saying, "How am I getting a little bit better at guiding the team on what the right opportunities are?" And so that's where I think in this world, you may have all these engineers who are like mini PMs, and the better that happens, that's where I would love to be doing more of. But still, if you then get a really good PM who can come in and can improve that, the why and the what particularly by 5%, that is such a high leverage higher.
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.