Lenny's Podcast: Product | Career | Growth
00:02:37 · Lenny Rachitsky, Tom Verrilli
[00:02:37] S1: I hear that. I hear that when people come with the podcast. Here you are. [00:02:40] S0: Somebody's giving you first time long time. [00:02:43] S1: That's right. I want to start with something that you wrote online that surprised a lot of people, and I think will surprise a lot of people coming from a long-time chief product officer, long-time product builder, someone that's built a lot of very successful products and teams. What you wrote is, "Since its earliest inception, the Whatnot product team was built on the somewhat simple premise. We regret that product management exists." [00:03:09] S0: Yes, sir. Not a thing you probably hear from a lot of CPOs. [00:03:12] S1: No. Talk about why you feel this way. Talk about how you got to this place. Talk about what this means.
00:03:19 · Tom Verrilli
[00:03:19] S0: Sure. I mean, I always try and start with history in order to understand kind of things. And one of the things when you come to product management is if you go all the way back, product management didn't exist. It was like the business, and very often founder or CEO types talking directly to engineering and design about what we needed to build, and then executing it together. And internet businesses, it turns out, scaled a lot faster than any other businesses in history. And so at some point, scale meant delegating the specifics of execution to somebody or trusting somebody else to work out what comes next because there's just too many things on for somebody to sit with. But if you think about most startups, or you think about how that evolution worked, that was really a specialist role where somebody was working it out. It was usually you said less things to the engineer, or you had to describe in less detail what you were trying to get done to a designer because they understood or they'd been involved. And this idea that we need this kind of specialist decision-making class of humans in tech is really a more modern function than it is a pure necessity. The way I would think about it and the way that Whatnot is always treated is it would actually be way better if engineering and design had the context that they needed to just make great decisions there, if they were so in touch with users and what they needed that they could make the same decisions that a product manager is. The only argument as far as I'm aware for why you would want product management to be a specialist function is really it's a trade, not a qualification. And what I mean by that is it's something you get good at by doing. It's a muscle, for want of a better term. And as every private trainer has ever told me, muscles are built by reps. And so the more you do it, the better you get at it. But the flip side of that is the more you abstract your engineers and your designers from doing the same thing, their muscle gets underdeveloped. And so I think product management plays a really important role. And I think you can deploy product management to have a really important leverage on particular things that need to go really well. And in a lot of ways doing that, let's design and engineering be the best they can be at their craft in those situations.
00:05:28 · Tom Verrilli, Lenny Rachitsky
But wherever possible, it's kind of optimal to not have a product manager and instead have design and engineering going through those kind of steps and making sure that their muscles are well-repped. [00:05:39] S1: Do you feel like product management was very helpful early on and was important, and then it kind of went through a period of, wow, there's way too many PMs that are not that amazing. And now there's kind of this coming back to, okay, what is actually an amazing PM and maybe we need fewer of them?
00:05:54 · Tom Verrilli
[00:05:54] S0: Yeah. The funny thing is I think if you talk to most engineers, or even designers, they will remember the great PMs that they've worked with mostly because they've worked with so many bad ones. And I don't mean that as a disheartening pejorative for folks, but I think it's more if you're being really literally self-critical as a function, does the average PM add a ton of value to folks around them in the way that having really high quality product management can disseminate clarity and absorb ambiguity in the ways that they can or help people make really timely decisions? And I think a lot of it is this function of, as tech companies scaled and we ended up hiring so many engineers, somewhere along the line, and I don't want to pin it on HR, but somewhere along the line, this kind of HR ratio of a pod popped into being. Every time you hire six engineers, you add a designer, you add a PM, you add an EM, and the nucleus exists. And then when you're now serving billion DAU products, you got a lot of engineers. And so now all of a sudden you've got a lot of product managers. And in most cases, you probably don't need a PM for notifications infrastructure. Engineers are perfectly capable of understanding how that works. And in a lot of ways, as we just described, hiring so many PMs infantilizes the engineers and the designers who are perfectly capable of making good decisions, but just never had to because there was always a PM to babysit them. It's certainly less glamorous than people think. Yeah.
00:08:46 · Lenny Rachitsky
[00:08:46] S1: Yes, exactly. How do you think about that? Especially as a company scales, engineers having to be in alignment meetings, having to write docs, aligning everyone, taking note, all these kind of minutiae part of PM. And also just the big, engineers want to build, engineers want to code, designers want to design. How do you think about that element of they may not actually want to be doing that work?
00:09:10 · Tom Verrilli
[00:09:10] S0: I think this is where specialization works both ways. It is useful to have folks who are well-honed in making decisions. It's totally reasonable as well for someone to say, "Listen, I'm an infrastructure lead and I want to think a lot about scale, and I do not want to have to spend my time debating alignment or getting those minutiae right." And certain skillsets don't necessarily translate super well. If you're really good at building big mental models in your head of how infrastructure should scale, you may not have the skillset of listening to a customer and actually understanding the core problem as opposed to the thing that they said, which again, just a thing that we've built over time. So my supposition of we regret isn't to say that we don't want product managers. We recognize in those situations that you do need to help other functions specialize. But I think it's we articulate it that way to force ourselves to remember that you don't hire a PM just for the sake of hiring one, you hire one where there's really specific need. And I think what goes with it, Lenny, is you have to build the culture of the organization around that. So for example, when we say we regret product management exists, every time we write documents about how we ship or what we're doing, we're very clear that anyone can bring change forward, that we can have DRIs of new product development that is an engineer or is a designer, but that everybody goes through that same level of function of you've got to go through product review, you've got to actually do the work because it is real work. And if people don't want to do that, if they want to do something else, we can always move product management around. And so rather than mapping PMs to teams where you assume that the PM will always do that, we tend to map them to problems or core projects. And that means that there will be a year more where there isn't a PM attached to a particular engineering team, even though there's lots of ongoing product work to do.