Lenny's Podcast: Product | Career | Growth
00:22:26 · Tom Verrilli
[00:22:26] S0: I mentioned a little bit earlier, but there was this thing in the ratio land where what you did if you were really successful as a PM is you got promoted into being a director. And then all of a sudden it was like, don't be hands-on anymore. Your goal is just to coach and guide. And so we took all of our A players and then promoted them out of doing things. And they spent all of their time in alignment and they spent all of their time coaching and tweaking what their team was doing. And you get this really yo-yo development process where somebody does all this work, it goes to review, it gets told no, and you're just going back and forward in reviews. You can see my scar tissue coming through. On our team, everybody is, there are managers, there's I think four or five people across the team who manage other PMs, all of them would spend 90 plus percent of their time doing IC work. I'm still probably 50% of my time doing IC work personally. And I think there's a couple real advantages of it. The first is if you are a kind of VP product where you've got a decade plus, maybe 15 years of experience building things, hopefully your instincts as to what's going to work and not are fairly well honed at this point. You can just make decisions more quickly than people. You can have real impact very, very quickly. And it's really great for the organization to have somebody who can do that as opposed to the idea of working through three layers of we divide the problem up amongst a couple PMs. Those folks need to get into alignment. There's different engineering teams debating stuff. You just tend to go. So that's wonderful. I think the second thing is there's two ways that that ends up driving leverage. One is a VP in theory can handle the workload of multiple more junior PMs just because, as I said, they're more efficient. And that means that you see more of the board at any given point in time. And so you're far more likely to make the intuitively correct decision for how should we tune the discovery algorithm vis-a-vis people who ship slowly, which is an evergreen thing in e-comm. Well, if you are thinking about how we manage sellers who ship slowly, and you know about the power of discovery, you can, in either case, make the correct decision.
00:24:35 · Tom Verrilli, Lenny Rachitsky
One of the things that I remember plaguing Twitch for a long time, and I was probably one of the people more at fault of it than ever was discovery team and the ads team were always at war for impressions. Where do ads go in the feed? What's the impact to discovery metrics? What's the impact to ad dollars? One of the first things I did when I go up to Twitch was just put ads in discovery and make sure that there's the same PM who's accountable for both because they're going to make the natural trade-off that say the goal is GMV generated from the feed. One of them is through organic. One of them is through a paid substitution. Solve. And when you put the same person across multiple things, they tend to organically align those things and you just cut out months and months and months of back and forth and the politics that tends to take it from being company first to career first. And so having VPs mostly in IC land, having directors mostly doing IC work, even having me having to grapple with IC work keeps everybody connected to the ground floor of what's actually true as opposed to what seems true in a review. But also means that you're more likely to make the intuitively correct decision early just because why wouldn't you want Messi playing for your team rather than trying to have the academy coming along all the time? [00:25:52] S1: I love this. So when you talk about IC work for PM, what does IC work for PM in this context mean? Does it mean shipping code building or is it like running a team, owning a roadmap, writing the strategy doc? Imagine it's the second bucket.
00:25:52 · Lenny Rachitsky, Tom Verrilli
[00:25:52] S1: I love this. So when you talk about IC work for PM, what does IC work for PM in this context mean? Does it mean shipping code building or is it like running a team, owning a roadmap, writing the strategy doc? Imagine it's the second bucket. [00:26:05] S0: Whatever is required to most effectively ship is the short answer. Have I personally shipped some production code at Whatnot? Yes. Do I think that's really the best use of my time? Not really. I'm certain that quietly somebody reworked most of my code in order to ensure that the linting was correct and the localization worked and all of the nuance that decades of software engineering has taught you that me and Claude Code did not get right. But I do think it starts with, are you literally in the support tickets? Do you know what customer problems we're having? Have you pulled all of the data yourself so that you actually understand it? Have you sat with engineering and design? Have you queried the code base directly in order to understand how things work? And then have you written the spec? Are you then running, you stand up, and we go? I think all of that is just core individual IC work. [00:26:52] S1: There's a lot of people that have worked their way up the ladder of product, become a VP, and it doesn't feel exciting to go back to being an IC. Some people, clearly you love it, you enjoy it. A lot of people are like, oh, I thought I was done with this. I could just work through people. I could think big picture. How do you feel about that? What would you say to folks in that bucket?
00:27:12 · Tom Verrilli
[00:27:12] S0: I think there are probably still a load of organizations where that is really valuable and that they will go. My recruiting tends to be the folks who are, oh my God, I used to love product management and I'm so sick of sitting in alignment meetings. And I'm out there pitching CPOs and VPs of product to be like, "Don't you miss actually doing things? Do you want to come back?" And I think it's okay for us to acknowledge that there'll be a bifurcation across the industry. I do think that there are organizations that are sufficiently large that maybe everyone being hands-on isn't right. I also think I mentioned earlier that you have to have a matching culture to go with this kind of environment where that's the expectation. Where people are like, "I don't want to talk about it. I want to just, let's go and do that thing." And in a lot of ways, every startup is a reflection of their founders. And so that naturally tends to be how do they think and how do they want to run the organization? But I've actually found that, for a lot of the cases, you go and talk to somebody who spent the last five, six years as a senior director at Meta who spends their entire time in alignment meetings, and they miss actually talking to customers and talking to engineers and shipping things.
00:28:18 · Lenny Rachitsky, Tom Verrilli
[00:28:18] S1: What makes me think about it, I imagine you've seen this list of all of these chief technology officers that have gone to become just engineers at Anthropic. I pulled up this list as you were talking. The CTO of Workday is just a member of technical staff at Anthropic. CTO of Instagram, Box's CTO, Super.com's CTO. They're just like engineers now at Anthropic. [00:28:38] S0: Yep. It is my greatest desire that the Whatnot product bench basically looks like that. All of these people with great skills and great understanding and actually end up coming and building as ICs. [00:28:52] S1: What about the comp of this path? That's people's dream, move up to VP, make millions of dollars. Is there a world where you can still do that and be an IC? [00:29:03] S0: I actually think it's easier. Spicy take. But go and take the comp required to have five L5s reporting to one L7 and then four L7s reporting to one VP, and now total the comp of that product org and turn around and say, "What if I had three people? Why can't I pay them all D2 VP money, particularly if they're having the level of impact that those folks are having there? Why not?" [00:29:29] S1: And just to fully understand why this is happening and why this should happen, what I'm hearing, there's kind of many combinations. One is AI is enabling this, which is great. Perfect timing. What are the other motivations to do this? Is it just the product ends up being better? Is it fewer people?
00:29:45 · Tom Verrilli
[00:29:45] S0: I certainly think the product ends up being better. One of the things that folks have been telling us for a long time is, yeah, that won't scale. Oh, leadership isn't going to be able to stay hands-on with what's going on. You're going to need to go and hire tons more layers. And what we found is that's actually not true. It requires a different muscle. You have to make an effort to make sure you genuinely understand ground truth. An example we use all the time is we'll be talking in a growth meeting and someone will say, "Oh yeah, but that was fraud." Turn around and be like, "How do you know that was fraud?" "Oh, it's labeled in the dataset as fraud. "Okay. Do you know how it gets labeled?" "I assume someone in ops does it." "Okay, do you know the SOP or how they label that?" "No." "Okay, so you don't know it's fraud." And if you push a really experienced product director like that, they're going to go, "Good point, I don't. I'm going to go find out." And then you invariably end up strengthening the system that agents are using to data label because suddenly there's a very smart person who's very invested in understanding how we do that and helping guide it. And so just that attitude that says we're going to do fewer things, we're going to make sure we execute the hell out of them, and we're going to push our best people to be in the weeds everywhere means that you fix lots of things as you go and you don't end up just making loads of trade-offs. And I think there's a general belief that it's too easy otherwise for growth to hide all sins. You get bigger and you just end up scaling and everybody's working off of averages. So culturally, I think you've got to be really committed to let's whole ass a few things, as I tend to say sometimes. Shout out Ron Swanson. And then push your best people to be really in the weeds of stuff. And actually what you find over time is you end up being more efficient by doing that because you actually understand how things work the first time and you make the best decisions. And then listen, AI, huge leverage for all of this. I can't think of how much time I spent as a junior PM asking my engineers how hard something would be, and distracting actual velocity in order to help scope future stuff. And now I can sit and talk to Claude and understand roughly LOEs.