Lenny's Podcast: Product | Career | Growth
00:47:21 · Tom Verrilli, Lenny Rachitsky
[00:47:21] S0: Definitely agree. Also props for bringing in the receipts even with a timestamp, my friend. Well done. I think my only build on that would be to say I think those core PM skills aren't necessarily the things that we have rewarded PMs for over the last five years, versus storytelling, alignment, strategy. And so I do think you're 100% correct that can I genuinely understand the customer? Can I genuinely understand the business? Can I genuinely understand the tech? And can I translate the three together for optimal efficiency, is the point of leverage when doing things gets cheaper, trying things is cheaper, et cetera. So absolutely agree that product skills are probably the most durable. My build would just be there's a lot of people who have the title PM who haven't spent a lot of time building those skills in the last five years, but have gotten really good at communicating frameworks to leadership. And so I just kind of push us back as a function into that core work. [00:48:23] S1: Yeah. Marty Cagan calls this product theater. A lot of people just do the things that PMs should be doing. [00:48:28] S0: And listen, I'm guilty of this. We rewarded it for so long that it doesn't surprise me that that product theater is a core skillset for a lot of folks. I just think that there's not a lot of place to hide in that anymore.
00:48:28 · Tom Verrilli, Lenny Rachitsky
[00:48:28] S0: And listen, I'm guilty of this. We rewarded it for so long that it doesn't surprise me that that product theater is a core skillset for a lot of folks. I just think that there's not a lot of place to hide in that anymore. [00:48:41] S1: And this comes back to that 32,000 people applied for jobs. I imagine a lot of that is just people who think they're PMs, or have the title PM, but are exactly what you described. They just focus a lot on alignment, writing docs, meetings, things like that, and not actual building, understanding what it takes to build a successful product. [00:48:57] S0: Yeah. The number of people who do really well in a product interview, Lenny, and then you give them a case study. So everyone who gets hired at Whatnot in any role has to do an actual hands-on case study. But the number of people who present incredibly well, and then you give them a prompt and some data, and ask them to come back with a POV on something, and then we make them verbally defend it, how quickly the thinking decays from folks who are good at the theater, but not the specifics is really telling, I think. [00:49:23] S1: Okay. So going beyond the hiring step, say you hire somebody, what are some things you've learned about how to get the most out of the people you hire? You mentioned this kind of contrarian take that you don't agree with this hire great people, get out of their way. So I want to hear more about that. And just is there anything else you've learned about just elements to building your very successful world-class product team?
00:49:45 · Tom Verrilli
[00:49:45] S0: I mean, nuance required, in my life, hire people and get out of the way is wrong, I will say. But couple of pieces to build off of it. I think in general, the hire great people and get out of their way became this kind of macro saying for let them work out what the roadmap is, let them work out what the problems are, just completely devolve what's going on. And I think the real answer is obviously the better people you hire, the more you can totally trust that they know what they're doing. But we tend to live in a verify, then trust land as opposed to a totally trust or even trust but verify, which is like I'm probably in a better position than any of my directs to understand how all of the different pieces of our system, buyer, seller, trust, fit together. They're almost certainly in a better position than me to understand the nuance of how any of those individual features work. If somebody quizzed me today on exactly all the weightings in the Whatnot discovery model, I would definitely be wrong vis-a-vis any of the engineers on that team, vis-a-vis any of the PMs on that team. Good. But it's actually kind of incumbent on me to learn that and understand that over time because I'm asking them to make decisions, and I am proving things that they're doing. And so time spent actually working alongside those teams in the trenches trying to solve something, really, really powerful. One of the things that I saw earliest when I joined Whatnot that I've seen, Grant, who's our founder CEO do, is he'll sit in a review and be like, "I don't think this is right." And then he'll pause and say, "I'm going to clear the rest of my day. Let's sit and figure it out." And he'll actually end up sitting with the team and going through, again, easier with AI data tools, let's literally pull up the tickets. Let's literally pull up the code. Let's go through the data line by line and understand what's actually happening so that we can make a decision there. And it means he's very up-to-date with what's going on, very culturally sets the tone for the team that we're just seeking truth. And it makes it very much a us versus you. Reviews got very into listen for yes for a little while there where all you're trying to do as a PM is just get a green light so that you can go back to your engineers and say, "I have some credibility.
00:52:03 · Tom Verrilli
I can get the CPO to approve what we're building." As opposed to this idea that says we're just trying to find out the right answer, and in theory, everyone wants us to come up with the right answer. So we use planning to align the company on what are the really important things we have to solve. That's mostly a resourcing discussion. If we pick the right things, stack rank them all. Ultimately, I'm most accountable for making sure that we have the right resources in the right places to hit things. But I don't know if those are the right places if all I do is delegate to the team to go figure it out, and I'm not actually periodically very deep with them on exactly how does that work? How do our referrals work? Literally, what is the logic that fraud might use in order to invalidate one? Oh, based on address signals. How do we calculate address signals? Is that a Google normalized thing, or is that free text that's put in? And if you don't actually push yourself down to sit alongside your IC engineers and your IC designers and your ICPMs, you don't actually know that stuff. So you can't make good macro decisions without the micro. So increasingly, I think I push myself to I try and be T-shaped. I can go very, very deep when required, but I'm mostly broad across pieces. And I think the idea of just hiring people, and then not asking any more questions and delegating all of the detail just isn't really the most successful model for getting the most out of an organization.
00:53:32 · Lenny Rachitsky
[00:53:32] S1: With a very product-minded founder, CPO classically is a very challenging role for people because you're basically this person between a very opinionated founder and the team building it. What have you found works in creating an environment where you are happy in that role?
00:53:51 · Tom Verrilli
[00:53:51] S0: Yeah. Funnily, that's become most of my career. Actually, I've worked for three founders in a row who are all very product-minded and whatnot. I've got two, which is a blessing actually. In general, I try not to double up. If Grant or Logan, our founders are on a thing, probably doesn't need me. What's the advantage of an extra layer? I think jokingly one of the PMs on the team has referred to it as the two dads problem where you've just got two people issuing conflicting instructions, or somebody wants to review and then you do all this work to present it to me, and then you go back and it gets a different thing. So my first thing is if Grant or Logan are on it, I check that they're watching it, they're accountable for it, and I step out. So there'll be long periods of time where fully half my team can be working on something, and I couldn't tell you day-to-day where it is because it's with Grant, it's with Logan, and that's totally fine. I don't have to be across all of the things they're doing. We just need to make sure that there is somebody doing that bar raising. So we spent much time doing that alignment. I think the second one is, ultimately, if you are a product leader in a founder-led company, you have to understand it's not your company, it's theirs. And you just find the right balance of, hey, are you open to feedback on this? Have you made up your mind? Are you open to a push on this? And you just find that rhythm working with folks. Generally speaking, there's a reason that founder-led companies do so well in our industry. The insight required and the kind of customer intuition to make the thing in the first place and work tends to be really important. And then I just view my job as making sure that we've got coverage on the places where our founders are.