Lenny's Podcast: Product | Career | Growth
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.
00:31:49 · Tom Verrilli, Lenny Rachitsky
I can sit there and go through and be like, it feels like there's some car crash of modals that must be hitting new users as they open up the app. And you can literally just go through and be like, let's load up the feed and talk to me about the logic of who sees what in what order and when does this thing fire? And you can get answers really quickly. And having, as I said before, folks with enough tenure and enough reps that they can see that and say, "You know what? That's bad. Let's just make a good decision and change the ordering of those." I've saved now a kickoff meeting, an alignment meeting, a week writing PRDs, experiment time, all of that by just having somebody who's kind of empowered to go and make a decision. [00:32:28] S1: So coming back to people that are trying to get a job as a PM, whether you're new, let's actually hold off on new people, but people that are say managers, senior folks that are just like, wow, the market has really shifted. A big thing we're hearing right now is you need to be comfortable with moving back into IC, giving up your fancy title. Is there anything more along those lines of just people looking for a job, struggling to find a job? Any other advice for them?
00:32:53 · Tom Verrilli
[00:32:53] S0: Start doing IC work in the role you're in would be my push. Get back to the basics of make sure that you're taking on practical work. Because I just think it's good to make sure that you are keeping those muscles well honed. I think it also starts with pushing internally for those things. I would bet that if you started bringing that level of productivity back into the role that you're in, it probably helps you where you are in addition to help you where you might move to. But I think there's a lot of chatter online obviously about PMs or engineers now. And I think that's all well and good. It's a great muscle to go and go and hone. As I said, I've pushed some production code because I wanted to go through the exercise of understanding it. But I think there's also, before you get to building things, it's like how quickly can you get back into the muscle of scoping the correct thing, understanding the problem, being able to define what good looks like? And take advantage of the scale and the scope that you've got that you can see more and bring more to things. I think most folks who've sat in a director plus role will know the pain of sitting there and watching a junior PM yo-yo back and forth on the same PRD back to review where you kind of know what the answer is. Somewhere along the way we decided that lead a horse to water as opposed to help them understand the answer and then keep moving. And I think there's something in our coaching styles that we can get back to of help somebody understand what good looks like relatively quickly as opposed to just endless review yo-yo.
00:34:19 · Lenny Rachitsky, Tom Verrilli
[00:34:19] S1: This point you make about PMs not shipping to production, I so agree with. Because my mind changed on this recently with a previous podcast guest with this point that PMs have so much more leverage if they're not sitting there trying to ship to production. Enabling the team to ship better and faster and making sure the things that are shipping are better is a much better use of PM's time than sitting there shipping stuff. [00:34:41] S0: I mean, this sounds really silly, mate, but it takes me substantially longer to go through the minutia of getting, get, commit, and all of the pieces that are second eng to engineer aligned than it does to actually work out what the problem is and be able to describe it. So yes, good practice to try and make sure you're doing something. For example, I don't want to judge if our dev tools have gotten easier or not based on what someone tells me. I'm going to go and try it and be like, yep, that was easier than last time I did it. But I do think you can get an awful long way understanding the code base and then talking to somebody who can actually execute well. Otherwise you're just going to get fall afoul of a thousand classic traps that every other engineer learned how not to do when they were an L4.
00:34:41 · Tom Verrilli, Lenny Rachitsky
[00:34:41] S0: I mean, this sounds really silly, mate, but it takes me substantially longer to go through the minutia of getting, get, commit, and all of the pieces that are second eng to engineer aligned than it does to actually work out what the problem is and be able to describe it. So yes, good practice to try and make sure you're doing something. For example, I don't want to judge if our dev tools have gotten easier or not based on what someone tells me. I'm going to go and try it and be like, yep, that was easier than last time I did it. But I do think you can get an awful long way understanding the code base and then talking to somebody who can actually execute well. Otherwise you're just going to get fall afoul of a thousand classic traps that every other engineer learned how not to do when they were an L4. [00:35:22] S1: So following that thread a little bit, what are some of the ways that AI has enabled you and/or your team to move faster and be more productive other than prototyping, which is the very clear benefit of AI for PMs and product teams? What else? What are maybe in the top three of, wow, this has really unlocked our productivity and the quality of what we do?