Lenny's Podcast: Product | Career | Growth
00:46:28 · Lenny Rachitsky
[00:46:28] S1: Two and a half years ago, I had this post I put out where I said, "Why PMs are the best positioned role in tech to thrive in an AI world." And I feel like, even though the beginning of our conversation was like we should live in a world where we regret PM exists, I feel like we agree on this idea that the skills that seem to matter most and are going to be most valuable, whether it's a PM doing them or an engineer or designer, is very PM-y skills. I'll share a few examples from this post. Who is really good at this stuff, these things? Identifying what to build, distilling, communicating requirements, prioritizing everyone's ideas for the highest ROI opportunities, giving feedback and design to improve impact, developing go-to-market strategy, understanding business strategy. To me, this is what PMs do, and it feels like that's becoming more and more important. So I guess the question to you is, would you agree with this idea that the PME skills seem to be the most valuable now as AI takes on the building?
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?