This CPO regrets that product management exists | Tom Verrilli (CPO of Whatnot)

Transcript

As tech companies scaled, somewhere along the line, this HR ratio of a pod popped into being. Every time you hire six engineers, you add a designer, you add a PM. 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. Something you wrote online that surprised a lot of people at Whatnot: product team was built on a somewhat simple premise. We regret that product management exists. Not a thing you probably hear from a lot of CPOs. 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. It is better to not assume we need a PM in every place. The only argument for why you would want product management to be a specialist function is really, it's a trade, not a qualification. It's something you get good at by doing. It's a muscle. 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. They also wrote this brutal quote: In the last two years, 31,832 people applied to be a product manager at Whatnot. We hired one. What does he look for in the folks that you hire? I can tell you what's definitely trending down: folks who spend a lot of their time in their interviews talking about driving alignment and stakeholder management, because there's definitely a group of PMs whose specialty wasn't technical. It was politics. You're very excited about this move to IC work, PMs moving away from this big org management world. If you were really successful as a PM, you got promoted into being a director. We took all of our A players and then promoted them out of doing things. Why wouldn't you want Messi playing for your team rather than trying to have the academy coming along all the time? Today, my guest is Tom Verrilli. Tom is chief product officer at Whatnot, former longtime chief product officer at Twitch, and former director of product growth at Twitter. He's also someone I've been wanting to get on this podcast for so long. Tom has a lot of hot takes and really unique and important insights on the future of the product role, what he's seeing the best PMs doing differently these days, and what he's looking for when he's hiring product people for his team now. If you're not familiar with Whatnot, it's a live stream shopping platform. It's the fastest-growing US marketplace business of all time. At one point, Tom shares how he bought a fresh lobster from a fisherman on the platform. Before we get into it, don't forget to check out lennysproductpass.com for a free year of the hottest and most beautifully crafted AI product in the world, available exclusively to Lenny's newsletter subscribers. With that, I bring you Tom Verrilli. Tom, thank you so much for being here, and welcome to the podcast. Thank you so much, dude. It feels surreal after years of watching. I hear that. I hear that when people come on the podcast. Here you are. Somebody's giving you first-time, long-time? Tom Verrilli. 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 longtime chief product officer, a longtime product builder, someone who'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 a somewhat simple premise. We regret that product management exists. Tom Verrilli. Yes, sir. Not a thing you probably hear from a lot of CPOs. Tom Verrilli. No. Talk about why you feel this way. Talk about how you got to this place. Talk about what this means. Tom Verrilli. Sure. I always try and start with history in order to understand things. 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 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. Internet businesses, it turns out, scaled a lot faster than any other businesses in history. 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 going 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. But it was usually you said less things to the engineer, where 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. This idea that we need this 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 has always treated it, 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 does. 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. 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. As every pro trainer has ever told me, muscles are built by reps. 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. 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. In a lot of ways, doing that lets design and engineering be the best they can be at their craft in those situations. But wherever possible, it's optimal to not have a product manager and instead have design and engineering going through those kinds of steps and making sure that their muscles are well repped. Do you feel like product management was very helpful early on and was important, and then it went through a period of, wow, there's way too many PMs that are not that amazing, and now there's this coming back to, okay, what is actually an amazing PM, and maybe we need fewer of them? 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 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, or help people make really timely decisions? 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 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. When you're now serving billion-DAU products, you have a lot of engineers. So now all of a sudden you've got a lot of product managers. 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. This episode is brought to you by our season's presenting sponsor, WorkOS. What do OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by WorkOS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by large companies. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS. Literally every startup that I'm an investor in that starts to expand upmarket ends up working with WorkOS. And that's because they are the best. Whether you are a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise-ready and unblocking growth. It's essentially Stripe for enterprise features. by our season's presenting sponsor, WorkOS. What do OpenAI, Anthropic, Cursor, Vercel, Replit, Sierra, Clay, and hundreds of other winning companies all have in common? They are all powered by WorkOS. If you're building a product for the enterprise, you've felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by large companies. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS. Literally every startup that I'm an investor in that starts to expand upmarket ends up working with WorkOS. And that's because they are the best. Whether you are a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise-ready and unblocking growth. It's essentially Stripe for enterprise features. Visit WorkOS.com to get started, or just hit up their Slack, where they have actual engineers waiting to answer your questions. WorkOS allows you to build faster with delightful APIs, comprehensive docs, and a smooth developer experience. Go to WorkOS.com to make your app enterprise-ready today. Something that I find people run into eventually when they think this way that I want to get your take on is engineers and designers don't necessarily want to be doing the work of a PM because a lot of the work of a PM is annoying and not fun. And there's the glamour part, like making decisions. It's really less glamorous than people think. Yeah. 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 notes, all these minutiae parts of PM. And also, they 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? I think this is where specialization works both ways, right? 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 skill sets don't necessarily translate super well, right? If you're really good at building big mental models in your head of how infrastructure should scale, you may not have the skill set of listening to a customer and actually understanding the core problem as opposed to the thing that they said, which again, is 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, just that we recognize in those situations that you do need to help other functions specialize. But I think it's articulated 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 a 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 are engineers or designers, but that everybody goes through that same level of function of, like, 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 or more where there isn't a PM attached to a particular engineering team, even though there's lots of ongoing product work to do. What I love about this is we often hear people at ENG-oriented products talk like this, like developer tools, where we don't need PMs. Why do we need PMs? And it often comes from companies like Linear and companies throughout that are building developer tools, where you can see why engineers are enough. And so it's really interesting to hear from your perspective because you've built very consumer-y products, very consumer products that require what you think are very strong PM skills. So it means a lot, even more so coming from you, that you find that PMs aren't as necessary as people may think in building something great. Yeah. I think there were two parts that drove it. And a lot of what I'm talking about here are things that I've definitely learned over time. I spent seven years at Twitch prior to time at Whatnot, and that was very Amazon two-pizza-team, ratio-driven. I started in the Valley at Twitter, and that was similarly very tight alignment. And there were a lot of alignment meetings. So you can imagine my engineers didn't want to be in them. And it's evolved over time to understand that actually a lot of that is just a function of management not being able to see what's going on. And so you hire more folks and you build more layers, and your systems beget systems. And I think what's really changing is people are realizing that it's not true anymore that the only way to get leverage is just to hire more PMs underneath you and be more senior, that we've got a better understanding of what's happening in businesses now. It's easier to converse directly with the code base and talk to your engineers than it ever has been. And so you don't actually have to get into this all-scale thing. And I don't really think consumer or enterprise is the cutting point anymore. I think it's more the culture of the organization itself. How much of this shift, in your mind, is AI-driven because AI now enables non-PMs to do PM-esque work, and how much of it was pre-AI? And then I want to talk about what this actually looks like at your team, but let me ask that question first. I don't think it's explicitly because of AI, but I do think AI makes it a lot easier. I think it's two things. I think AI certainly means that there's an enormous amount of leverage for an IC. Now, I don't know how much other people feel this, but I was talking to a couple of our senior leads the other day, and we feel that we're so capable of doing things now with AI that you almost feel a bunch of pressure about the stuff you're not doing because you know that if you carved out a couple more hours, you could move a lot of stuff. It's certainly easier to move fast with AI tooling if you've got well-honed judgment. You can pull data now on a Hex thread that is basically what it would take a week or two weeks with an Amazon L7 data scientist in 2017. And so if you're empowered and have good judgment, you can basically make really quick decisions and just keep people moving, which is extraordinary. But more than just AI, I think a lot of those ratio pushes also came with a bunch of other cultural pushes like hire great people and get out of their way, bottoms-up roadmaps, and all of those pieces where I think there's been a bit of a cultural shift in tech over the last little while, which is that actually top-down is pretty good because folks at the top, generally speaking, can make quick decisions and remove all of this alignment debate. They have probably more macro context than most folks. And assuming that they are genuinely in touch with ground truth and are good enough, it's actually a really efficient model to be able to have senior leadership involved in a lot of those decisions, which means it's not just the tooling that makes them efficient, but you can have one very senior PM across more things, and they can be more efficient than having three relatively entry-level PMs. But certainly AI makes all of that a lot easier again. So, just coming back to the broad premise, which I think is very important to clarify, this point about regretting product management exists isn't saying we don't want or think PMs are useful. It's that it is better to not assume we need a PM in every place. And it is great to enable other functions to do the PM work. And also, PMs take away the reps from people being able to do the things that PMs do. And if they can do that work, they can actually execute better, build better products. I think it's also better for PMs to not be mapped specifically to a team than it is to say, we go where the work is, you will build more and better reps. You're going to work out more muscle relatively entry level PMs. But certainly AI makes all of that a lot easier again. So just coming back to the broad premise, which I think is very important to clarify, this point about regretting product management exists isn't saying we don't want or think PMs are useful. It's that it is better to not assume we need a PM in every place. And it is great to enable other functions to do the PM work. And also PMs take away the reps from people being able to do the things that PMs do. And if they can do that work, they can actually execute better, build better products. I think it's also better for PMs to not be mapped specifically to a team than it is to say, we go where the work is, you will build more and better reps. You're going to work out more muscle groups by moving around on the things you work on, as opposed to saying I'm attached to whatever this EM owns. So let's follow that thread. What does the team look like? What does the PM slash eng design team look like at Whatnot? What does this org look like in this worldview? Yeah, we've just passed 20 PMs. We have 21, 22 PMs in the building today, which, for those following what our trajectory is, is pretty small considering the volume of GMV that our sellers move. We're very loosely organized into three groups, buyer, seller, and what we would call trust and risk. So the folks looking after our standards, payments, safety, et cetera. And then within those broad groups, we basically reassign the PMs pretty regularly. So people have loose alignment. You might be broadly a growth PM or broadly work on discovery, but even amongst those groups, it gets allocated and moved around pretty quickly. And that's because the way that we do planning is every six months, the CEO, myself, some other folks, and senior leads will sit down and define what needs to be true over the next six months. What do we have to get done as a company, both in terms of outcomes and critical projects? And then we sit down and we go through that list and say, who's the DRI, who's accountable for that? And that's mostly how we end up allocating PM work. And so quite regularly, you'll have something. We've just finished a planning cycle literally this morning, and you'll quite regularly go through those and you'll get to the end and say, cool, there's this thing that's second or third priority in a bunch of different teams' roadmaps that feels really important. Who owns that? We actually don't have an owner for that. And we'll go and grab a PM and be like, congratulations. This is the thing we need you to deliver over the next six months. It's rarely, you need to build a feature that works exactly this way, that does this thing. It's a little more high level than that, but, like, how do you go and work out what needs to be true? And then you map the human beings that you think can guide that. Not every name is a PM name, but overwhelmingly, when you go through that planning process, it tends to be PMs, and it tends to be PMs who have the right skillset vis-a-vis what it is, whether it's more financial, whether it's more algorithmic and recommendations based, whether or not it's core user feature. Let me follow that actual specific thread at the end there around what you look for in product managers that you hire. So you also wrote this brutal quote: in the last two years, 31,832 people applied to be a product manager at Whatnot. We hired one. Yes, sir. Pretty great. Pretty great. So there's a few things here I want to talk about. One is just, what is it you look for in the folks that you hire, especially these days? What do you find? What's trending up in what you find you need in really successful PMs at Whatnot, and what's maybe trending down? I can tell you what's definitely trending down. It's folks who spend a lot of the time in their interviews talking about alignment meetings and driving alignment and stakeholder management and those pieces, because there's definitely a group of PMs, and I certainly used to be one of them earlier in my career, whose specialty wasn't technical or customer oriented. It was politics. And so folks who tend to naturally lean toward driving alignment, building relationships, tell me about a time when you failed, and you're like, oh, I didn't keep the CEO up to date with something, and that led to a pivot, is definitely a thing that is a bit of an anti-pattern that trends down. What we tend to find really jumps in a PM interview is, over the course of your interviews or your case study, can we see both the macro thinking and the micro thinking? I think the system works something like this, and I can describe an end state, but can I almost exude impatience on, and here's how I would validate that very quickly, here's where I would push to get that done? And are you specific about the things that you've built? All right. There's an awful lot of folks who've worked at Fang, Uber, pick any scale company, where they babysat things that existed and maybe polished the edges of it, as opposed to the idea of saying we were given this problem and I had to go and come up with something unique and novel, or I had to really iterate our way through a complicated change. But I made decisions along the way and we moved, because I think it's easy in a very large organization with inertia to go along with what's happening and not necessarily be an agent of change or be a decision maker, which is ultimately what you need PM to do. There's something you said there that I just had Elizabeth Stone on the podcast. She's CPTO at Netflix, and I asked her what's the trait that is also most trending up. And she said exactly what you said initially, which was the systems thinking, thinking big picture, thinking about the bigger business. And her advice there to work on this, and I want to ask you if you have any other advice here, say someone hears this, you're like, oh wow, I got to work on my systems thinking skills. Her advice is take one click back from your problem and think about, okay, for my manager, how do they think about this problem and how does that impact the rest of the business? Thoughts on just how somebody might develop the skill and get better at systems thinking. I think the skill is exactly the right way to say it. I think you can get good at it from just the mental exercise. So you can do it in small ways. One of the things I ask a lot in product review when someone says, how we want to run an experiment is, okay, what do we do if it's green? What do we do if it's red? And if folks are like, actually, I don't know how my strategy would change, like, cool, we haven't really thought about that. So stop and go and do the mental exercise of how it would work. And then I think it's the same thing. If you can build quick local solutions, if you have done the mental exercise in your head, I've said, well, what would happen if we had a thousand times more usage of this than we expected? Or what are the unexpected knock-on effects that this could have? And how do you just start doing all of that in your head before you get pen on paper, before you get code on the system? And I think it helps actually unblock people to move faster too, because I think the other thing that PMs are often slowed down by is, oh, risk. Oh, legal might, finance might, another team might. And I think one of the monikers we use internally is no then go. As in, think through all the things that could go wrong, understand where scale will break, understand the things that might happen, and then make the move on anyway, because if you've thought through all the things that could happen at scale, you're probably going to preempt a bunch of them. So I really like Elizabeth's quote there, but mine is just do the mental exercise of playing out, if it gets really widely adopted, if it happens, if there is something that goes wrong, what will it be? You don't have to solve all of them. You've just got to think through all of them. And then you end up solving more than you think. I love that. So it's essentially, don't just focus on, will this be an impactful experiment, and think about what comes next and what comes next if this is true. Like, okay, I moved it. Particularly in a higher growth environment, you're not really things that could go wrong, understand where scale will break, understand the things that might happen. And then make the move on anyway, because if you've thought through all the things that could happen at scale, you're probably going to preempt a bunch of them. So I really like Elizabeth's quote there, but mine is, just do the mental exercise of just playing out. If it gets really widely adopted, if it happens, if there is something that goes wrong, what will it be? You don't have to solve all of them. You've just got to think through all of them. And then you end up solving more than you think. I love that. So it's essentially, don't just focus on, will this be an impactful experiment, and think about what comes next and what comes next, if this is true. Okay, I moved it. Particularly in a higher-growth environment, you're not really looking for a 5% stat when you're looking for something that totally moves the business and has a compounding effect over time. And so you just have to think through what that is. Something else you said that is changing in how PMs operate that you're very excited about is this move to IC work, PMs moving away from this big org management world to actually doing the work. Talk about that and what that means for the role of product management. 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. And 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 of real advantages of it. The first is, if you are a 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 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, manage sellers who ship slowly. And you know about the power of discovery. You can, in either case, make the correct decision. One of the things that I remember plaguing Twitch for a long time, and I was probably one of the people more at fault for it than ever, was discovery team and the ads team were always at war for impressions, right? 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 got 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 says, 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? 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 running a team, owning a roadmap, writing the strategy doc? Imagine it's the second bucket. 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'd 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 a stand-up and we go? I think all of that is core individual IC work. There's a lot of people that have worked their way up the ladder in 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, I thought I was done with this. I could just work through people. I could think big picture. How do you feel about that? And what would you say to folks in that bucket? I think there are probably still a load of organizations where that is really valuable, and 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 will 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 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's 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. What it makes me think about, 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're talking. The CTO of Workday is just a member of technical staff at Anthropic, a CEO, CTO of Instagram, Box, the CTO, super.com CTO. They're just engineers now at Anthropic. 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 actually end up coming and building as ICs. 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 alignment meetings, and they miss actually talking to customers and talking to engineers and shipping things. 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're talking. The CTO of Workday is just a member of technical staff at Anthropic, a CEO, CTO of Instagram, Box, the CTO, Super.com CTO. They're just engineers now at Anthropic. 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 actually end up coming and building as ICs. 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? 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. 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? And just to fully understand why this is happening and why this should happen, what I'm hearing, there's many combinations. One is AI is enabling this, which is great. Perfect timing. Yes. What are the other motivations to do this? Is it just the product ends up being better? Is it fewer people? 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. 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. What we found is that's actually not true, right? 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. 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. 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. 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, when you don't end up just making loads of trade-offs. 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 few things, so I tend to say sometimes, shout out Ron Swanson, and then push your best people to be really in the weeds of stuff. 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. 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. Now I can sit and talk to Claude and understand roughly LOEs. 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. 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? You can get answers really quickly. 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 empowered to go and make a decision. 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, just for people looking for a job, struggling to find a job? Any other advice for them? David Starr, 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're 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 helping you where you might move to. I think there's a lot of chatter online, obviously, about PMs are engineers now. I think that's all well and good. It's a great muscle to 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, 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 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. 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. This point you make about PMs not shipping to production, I so agree with. This is my mind changed on this recently with a previous podcast guest, with this point that PMs already 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 PMs' time than sitting there shipping stuff. I mean, this sounds really silly, mate, but it takes me substantially longer to go through the minutiae of git commit and all of the pieces that are second nature 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 going to fall foul of a thousand classic traps that every other engineer learned how not to do when they're in L4. 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 the top three of, like, 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, you're going to, you're going to fall foul of a thousand classic traps that every other engineer learned how not to do when they're in L4. 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 like, wow, this has really unlocked our productivity and the quality of what we do? The first one, I think by a country mile, is data science. We use Hex threads internally at Whatnot. I'm sure there are other comparable products, but I think it's almost hard to remember a time as a PM before you had tooling like that, where you could genuinely start pulling very nuanced cohorts of data, where you could grab an individual user where you've heard a report, actually understand, let's pull logs, help me understand exactly what this user did and saw, how many other users look like this, what would impact be. And then all of a sudden you can build pretty meaningful sensitivity models or forecasts of what might happen, regression models, et cetera, really, really, really quickly, which is incredibly powerful. The other thing that we found is it helps us move much more quickly with shipping things because you can spot regressions and weird knock-on effects of two products mixing more quickly than you used to be able to. And I think in really large, complicated systems, that's always one of the things that ends up slowing you down, release trains and all of that, versus if you build the right AI tool, you can spot regressions really quickly, which lets people just go. So I don't know what the future of data science looks like, but I think as a product manager, I've spent less time in the last year talking to a data scientist than I ever have in my career, even though I've probably spent 10 times more time in data and understanding actually how the product's working than I ever have in my career. So that one I think is really powerful. Second one I've already mentioned, which is stop bothering engineers with how does the code base work, and actually just go and talk to Claude and understand it, which is really helpful. I used to say early on in my career that the goal was always to understand your systems at the boxes-and-lines level of which system drives which thing. And now there's no excuse not to understand that, or a nuanced layer. But the other one, and this might be very specific to Whatnot, so I don't know that this will help everyone, but one of the things that I've been lucky to do in my career is basically work on live products for a decade now. And so it's always been really cool to be able to ship a product and then watch a customer use it and watch them figure it out. So I think people have just gotten this experience with Listen Labs and others in that cohort of watching people use your product, but I've always been able to sit and watch people use the thing for the first time and go through that new-user comprehension gap. What's really cool with a bunch of the AI tooling right now is as they're describing, oh, I'm having a problem, you can literally be watching the code base live and work out, is that actually a bug that's happening right now, right now? Or is that a comprehension gap where it doesn't work as expected? And suddenly you've got this video artifact of someone using your product. You can be analyzing the code base in real time, and you can be talking through AI to the code base to understand what's actually happening. And it's like a feedback loop on steroids because all of a sudden you know exactly what's going on customer-side, code-side, and observe-side as a viewer in real time, which is really cool. That sounds both awesome and very stressful, to be building products that are that live in real time. I think about Netflix, where they invest in live now, and that's all you've done for 10 years, and how big of a deal that was for them. I know the scale is different, but. Honestly, my second week at Whatnot, I remember sitting in a room watching. Whatnot, for those not familiar, is a commerce, largely auction platform, that live commerce platform. And there are varieties of different ways to run an auction, but one of them is what's called sudden death, which is when the timer ends, it ends. Otherwise, in the classic auction environment, if somebody bids in the last five seconds, it adds 10 seconds back on the clock. And a seller can decide what auction model they want. And I was sitting there watching a seller who was like, these are taking too long. I wish this seven-second timer was actually three seconds because I want to move more product. And I watched two engineers in the office look at each other and be like, that's a config. We could totally do that. And so they went and updated it in real time and then jumped in the chat of a show and just said, refresh your app. And then all of a sudden, bang, it was operating that way. And I was like, cool, I'm with my people. I'm in the right place because that's the level of responsiveness that you can get in a live environment. And obviously, AI means that that's really easy for lots of people to take on. Not that I would touch production code in that kind of way because that's a disastrous idea. But for the qualified humans, it's a wonderful one. That is very cool. This episode is brought to you by Mercury, radically different banking loved by over 300,000 entrepreneurs, and now with Command. I've been a customer of Mercury's for over six years. I have never once thought about leaving. Mercury is what happens when banking is built by product people, not by bankers. They make it so easy, dare I say fun, to send invoices, move money around, set up virtual cards for folks on my team. Does your bank have an API, a terminal-native CLI, or an AI-ready MCP server? I don't think so. And just recently they launched Command, a conversational interface built directly into Mercury, which acts as your financial operator. I've been using Command to transfer money around, to figure out what categories I've been spending the most money in, analyze my cash flows. And just today I used it to find out how much I've made from a specific sponsor over the past year. I just asked, how much have I made from X over the past year? Ten seconds later, I have an answer. It is so freaking cool. Visit mercury.com to learn more and apply online in minutes. Mercury is a fintech company, not an FDIC-insured bank. Banking services provided through Choice Financial Group and Column NA, members FDIC. Coming back to this data science point, I have a friend who's a data scientist, and he said it's a rough time for data scientists because of this exact thing. And to add a little more color, their time used to be: asked to do some data analysis, do some work with the data, come back, here's the results, here's what I'm confident in, this conclusion. Now their time is basically seeing half-assed data science work from non-data scientists and just like, show me, is this right? And then half the time it's wrong. And they're like, what the hell is my job now? It sucks. Yeah. Listen, I have a lot of empathy for that because I've certainly seen it. Another plug for why having fewer, more senior PMs is helpful because they are folks who've seen more of those reps and understand. But I also think a lot of the time that lack of clarity comes from the other thing, which is organizations who have historically underinvested in data engineering and data structures and good data labeling and whether or not you've got your taxonomies right, but whether or not you really understand whether or not your data systems and structures are set up well. And so what we found is a lot of our best data scientists are pushing in that direction of like, are we actually correctly updating all of the ways in which our tracking and attribution works so that it's less easy for people to misunderstand those? And then yeah, using an AI tool to find a piece of data, much like using an AI tool to write code, doesn't absolve you of responsibility to make sure that that was good analysis, good code. It just tends to be leverage for those people who are naturally inclined that way. So thinking about these different functions, data science, user research, design, engineering, PM, which is organizations who have historically underinvested in data engineering, data structures, and good data labeling, and whether or not you've got not just your taxonomies right, but whether or not you really understand whether or not your data systems and structures are set up well. And so what we found is a lot of our best data scientists are pushing in that direction of, are we actually correctly updating all of the ways in which our tracking and attribution works so that it's less easy for people to misunderstand those. And then, yeah, using an AI tool to find a piece of data, much like using an AI tool to write code, doesn't absolve you of responsibility to make sure that that was good analysis, good code. It just tends to be leveraged for those people who are naturally inclined that way. So thinking about these different functions, data science, user research, design, engineering, PM, what I'm hearing so far is we'll need probably fewer PMs, we'll need fewer data scientists. Are there any other roles that you think they're trending down in terms of what we'll need, and are there any roles trending up, like, wow, we're going to need a lot more of this kind of person? Well, funnily enough, as I say, I haven't spoken to data science in a while. We've certainly still hired plenty because I do think all that tracking and attribution and measurement is really, really powerful. I also think one of the flip sides of "we need fewer" is fewer for the same output doesn't necessarily mean fewer in macro, because if you are using the systems right, you can just grow more quickly. You can build more things. You can take on more stuff. So I would be surprised, actually, if we ended up with net fewer. I think it's more like net fewer vis-a-vis customer impact for both. Certainly, I think trending up over time within these roles are these, and I don't remember the exact label that people used to use, but this idea of tech leads that are a hybrid EM, where you're running a very small team, running at things, because the same way that we'd say the cost of trying something has come down, the idea that says you can have core focus, which is the thing we're very big on, we've also found incubating a lot of smaller teams to go over and sit in the corner and just try and build this thing, going, it's not quite prototyping, but it's like, go and take a swing at a thing that we've historically thought was too hard, is getting cheaper and increasingly has very high leverage. So the idea of engineering manager light, for want of a better term, is the thing that I definitely think we'll see more and more of. It's not quite the technical member of staff, although that must be lovely, but certainly not the full-blown EM role, I think, is one that definitely will come about more often. So maybe just to close the loop on this part of the conversation, there's this trend towards everyone's a builder. PMs are shipping a little bit, being a little more engineer. Engineers are taking on more of the PM work. How do you think this maybe plays out over the next couple of years in terms of what product teams look like broadly? Is it still PM, engineers, a designer, data scientist somewhere? How do you envision the canonical product team over the coming years? Great question, and I don't know that I know what it looks like everywhere. I think what it'll look like at Whatnot is it probably still looks mostly like it has historically, which is there are reasons that you would have a specialist designer, specialist engineers, specialist product management. I think those very concrete teams will largely be reserved for very specific projects or things that we have high confidence or conviction that we need to solve, or we're pretty high-confidence, high-conviction that we have a path forward on a thing and we want to make good progress. And I think at the edges around that, there's going to be a lot more free space for people to play on, like, hey, I'm reasonably sure I can go and make a meaningful improvement to this thing, and it doesn't matter if you are a designer, an engineer, a product manager, a data scientist. You can and you should, right? If you're sitting there on a Friday afternoon and you can't focus on the PRD you're writing, but you're pretty sure you can go and fix something, go for it. And so I think it probably doesn't morph in the more formal sense, but I do think there's just a lot more free space for people who are well-versed in the customer problems, well-versed in the code base, and understand some of that macro context. They'll just be empowered to do more and more things. 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, are very PM-y skills. I'll share a few examples from this post. What do we, who is really good at this stuff, these things: identifying what to build, distilling and communicating requirements, prioritizing everyone's ideas for the highest-ROI opportunities, giving feedback in 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, do you agree with this idea that the PM-y skills seem to be the most valuable now as AI takes on the building? Definitely agree. Also, props for bringing in the receipts, even with a timestamp, my friend. Well done. I think what 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. Yeah. Marty Cagan calls this product theater. A lot of people just do the things that PMs should be doing. And listen, I'm guilty of this. We rewarded it for so long that it doesn't surprise me that product theater is a core skill set for a lot of folks. I just think that there's not a lot of place to hide in that anymore. 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 really successful product. Yeah. The number of people who do really well in a product interview, Lenny, and then you give them a case study. 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. Okay, so kind of 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 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 is there anything else you've learned about elements to building a very successful, world-class product team? I mean, nuance required in my "hire people and get out of the way" as well, I will say. But a couple pieces to build off of it. I think in general, the hire great people and get it. How quickly the thinking decays from folks who are good at the theater, but not the specifics, is really telling, I think. 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 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 elements to building a very successful world-class product team? Nuance required in my "hire people and get out of the way" as well, I will say. But a couple pieces to build off of it. I think, in general, the "hire great people and get out of their way" became this 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're doing 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, I'm probably in a better position than any of my directs to understand how all of the different pieces of our system, buyer or 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 incumbent on me to learn that and understand that over time, because I'm asking them to make decisions and I am approving things that they're doing. And so time spent actually working alongside those teams, in the trenches, trying to solve something, is 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 you'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, culturally sets the tone for the team that we're just seeking truth, and it makes it very much a like 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 PM, your engineers, and say, I have some credibility, 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, right? 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? Based on address signals, how do we calculate address signals? Is that a Google-normalized thing, or is that free text input? And if you don't actually push yourself down to sit alongside your IC engineers and your IC designers and your IC PMs, you don't actually know that stuff. So you can't make good macro decisions without the micro. So increasingly, I push myself to 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. With a very product-minded founder, CPO is classically 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? Yeah. Funnily, that's been most of my career, actually. I worked for three founders in a row who are all very product-minded, and at 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, it 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 could 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 spend a bunch of 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 customer intuition to make the thing in the first place and make it 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. Awesome. So a couple of things you've learned here for building, and this, I think, in consumer is especially important, is counterintuitively to how maybe people think things should work, you're finding that the best teams, companies, products end up coming from top-down, founder-led, almost, micromanagement is a dirty word to a lot of people, but it's basically being in the weeds. In spite of how people may feel, this actually ends up leading to better stuff. Top-down works well if leadership is good enough to be in the weeds and be specifically correct. I think where it falls apart is where you don't actually know ground truth and then you attempt to manage people from above. And that's where I think the term micromanagement comes from. Otherwise, if you're working from the same data and you have it, I don't know a junior engineer or an entry-level designer who isn't stoked to sit there and work alongside the CPO or the CEO and ship something, because you're just unblocked. There's no alignment meetings. There's nothing to do. They also find that you can give way better feedback if you're literally in the detail. And I think the nuance is just, how do you make sure you can do that in enough places? There's never been a better time to attempt to be in the detail on things because you can literally query it in real time. I think that's such an important nuance here. The story told is so powerful, this idea of Grant just, okay, I'm going to clear my day. I'm going to spend time going deep on this stuff. That feels like a very necessary ingredient for someone at the top to be making right-good decisions because, to your point, if they don't have all the details, they're not making a decision out of real data. And we can do that because, as I said, we plan what we're doing nothing to do. They also find that you can give way better feedback if you're literally in the detail. And I think the nuance is just, how do you make sure you can do that in enough places? There's never been a better time to attempt to be in the detail on things because you can literally query it in real time. I think that's such an important nuance here. The story told is so powerful, this idea of Grant, just, okay, I'm going to clear my day. I'm going to spend time going deep on this stuff. That feels like a very necessary ingredient for someone at the top to be making right-goard decisions because, to your point, if they don't have all the details, they're not making a decision out of real data. And we can do that because, as I said, we plan what we're doing, and then we allocate, and then we're dividing and conquering. So he's probably trying to nail three or four most important things at a time. And he's the CEO. He's going to call the ball and say, these are the four things I own right now. And I'm going to be like, great. I'll be over here then. And then within those, what am I doing with the rest of my day that is more important than nailing the five things I've said we'll get done this half? If it's anything other than maybe hiring, standing meetings, any of that stuff, you can just clear it and set the tone for the team that, until we understand it, we can't do anything else. Say somebody is looking for a CPO role or a first PM role, similar, working for a founder. What would be your advice for them to land in a place where they're happy and not just super frustrated by this middle layer where they just don't actually have any agency? Yeah. I mean, I think the first thing you've got to work out is why do you want it, right? There's this idea that the CPO's job, you get to decide all the roadmaps and all those things. And I've got bad news for you. That's not strictly true. But I think it also comes down to spending some time with that person to work out, how do we jam on a topic? How do they like to get push? How do they not? And then you spend a lot of your time calibrating. So before I joined Whatnot, I think Grant and I had five or six different coffees where we talked about how do you get this type of team to move? How do you work on those things? And then I obviously went through a series of interviews and actually came down to LA, where Grant and Logan were based at the time, and spent a whole day with them, just in a room, going through a couple of different problems, talking through different things in the roadmap, really getting into it. And I tried through that to be my most ordinary self, as opposed to interview self, if that makes sense. Because you kind of got to ask yourself, do I really want to spend my whole time having this discussion and this debate? But I like being a CPO or a product lead because, in a lot of ways, what I'm doing is helping translate that vision and that intuition into reality. And then there is an art to learning how to push somebody without competing with them. And I think a lot of the times I've seen the CPO-CEO relationship go badly, it ends up with the CPO competing with the CEO for vision, and they end up at loggerheads. And I think that's not your job. I want to ask more about that, this art of pushing back and nudging things in your direction. Is there one trick or one tip you might share with folks to be good at that? Because a lot of people deal with execs, and they're always trying to get them to agree to what they want. I think the first thing is, don't treat it as a trick. I mean, you're not trying to get an answer and a yes. You're trying to seek truth, is my first statement. And so I wouldn't say it's especially common that we start out of alignment, but I do think part of your role, if you're one of the more senior product folks in the room and the CEO, or if you're a director and it's the CFO in the room, is pushing the team in a way that you don't really expect or you don't understand. Start from a place of curiosity. Does that person have more context than you? Or is there a thing that you're not aware of that is guiding it? So I often try and start with, can you, am I hearing you right, that this is your prior? Is there a piece of context or something that I don't have that helps inform that prior? Cool. Make sure everybody's on that same baseline. And I coach my fans to do this with me all the time too. If I'm coming at you from an angle you don't expect, pause and make sure that you understand why. And then after that, I try and do a couple of different things. You're obviously just, people are people, right? They have good days. They have bad days. Sometimes it can be as simple as, is your mind made up on this, or are you open to input? If the answer is no, I'm pretty set that this is the answer, shut up. Don't pick a fight for the purpose of picking a fight. If the answer is actually yes, you're welcome to push me, but I'd need to see data. If I don't have any data in the room, if it's just my opinion, then the terms of the debate are pretty clear. If I have fresh data, bring it. If I really believe a thing and I don't have data, question why, or go get it and then go back to them with the data. But if the answer is, if nobody's got data, it's just two opinions, the CEO's opinion is going to win. And that's okay. Check your ego at the door, get to the answer. But if you've got data, bring it. And then sometimes it's just make sure that you're debating for the right reasons. I think it's easy in your PM theater that you're describing, wanting to make sure that you set the framing and the tone. And there are genuinely times in our industry where nomenclature matters and exactly what word is used can be really important. But a lot of the time it doesn't. There's a concept that I heard come up a bunch when I talk to people who work with you. The phrase was "play the accordion." Explain. So I mentioned earlier, I'm not huge on frameworks, but I do think there's a mental model which is quite useful that goes to the thing that you and I discussed earlier on. Think through a problem, do the mental work, even if you're not shipping at all, which is obviously the magic of code, that you can ship things and iterate really quickly and get data as you go. And I think one of the trappings that comes with that is you're just iterating forward and throwing spaghetti at a wall, and you don't really know what direction you're going in. I think there's a second failure mode, which is people sit down and write up these long roadmaps and strategic vision docs of what we'll do over the next two or three years, that kind of loses the comparative advantage we have over every other industry, which is learning. A-B tests mean that you can update your understanding of a problem and therefore change your direction as you go. So the point of the analogy of play the accordion is, if you think about a piano accordion, before you can play a note, you've got to stretch it all the way out, bring the air in. So what is it we're trying to get done? But you don't make music until you press the key and push it all the way back into V1. And then when you go to play the next progression, you pull it all the way out again. Okay, given what we just learned, what do we do? And then you go and build the next thing again. And you've got to get used to this motion that says, this isn't creating value. Pulling it out doesn't actually do anything. All the value is created here. But until you are going through this motion constantly of saying, well, reevaluate what we understand, how does this change what we're doing, you're probably not playing the right thing. And I know I'm probably bastardizing, somewhere in the comments, there's going to be a musician who points out to me that this is actually also one of the ways you make music. But I found it just a the way back into V1. And then when you go to play the next progression, you pull it all the way out again. Okay. Given what we just learned, what do we do? And then you go and build the next thing again. And you've got to get used to this motion that says this isn't creating value. Pulling it out doesn't actually do anything. All the value is created here. But until you are going through this motion constantly of saying, well, reevaluate what we understand, how does this change what we're doing, you're probably not playing the right thing. And I know I'm probably bastardizing. Somewhere in the comments, there's going to be a musician who points out to me that this is actually also one of the ways you make music. But I found it just a generally very valuable memory device for PMs to be you've got to constantly be zooming out and pushing back in, zooming out and pushing back in. Yeah. That is such a fun analogy. Because it's like, even though you make music expanding it, it's inward, or it's learning from the compression. What did we learn? How do you communicate to everyone? Exactly. Back to shipping. It's a different kind of music, internal music, external experiment. Yeah. Because genuinely there are people who are really big on roadmaps and there are people who are really big on iteration. I think the honest answer is you've got to do both. You can't overindex on either. So the lesson here is run experiments, but then make sure you think about the implication of the result at the bigger picture. And then what are we trying to do? Have a plan. I think the system works this way. I have this belief that if we change the way that discovery algorithms work for X, Y, Z reasons, it will have this impact. What's the smallest thing I can do to prove that? Okay. It worked. Great. No change to plan. V2. Oh, that didn't work. V3 is going to have to be different. And you just want to always be going through that motion. People not watching on YouTube, Tom is moving his hands. Just gesticulating. What's a context where you had said to someone, hey, we go play the accordion or we're playing the accordion? What are they usually doing wrong? Tom is going to be shipping something in a very local sense without necessarily understanding impact. So, an example right now is, the core of most marketplaces is listings, right? If you try and think about amazon.com without listings, there's basically nothing there. It's a bunch of left rail or right rail and some videos. In video commerce and live commerce, whatnot, you don't really historically need listings. If I want to sell you a pair of AirPods, I could literally hold them up to screen and show you them and describe them and say, they're AirPods. I'm going to start them at a dollar. And as a buyer, you now have all the information you need in order to make a purchase decision, which is great. And so you may not have to invest in making listings the way that someone else does. And that's probably net good for a seller because it takes three and a half minutes to make a listing, and it takes zero minutes to describe a thing and hold it up. But you then zoom out and say, oh shit, new buyers are going to come to live commerce and expect search to function. If I don't know what you're selling until after you've sold it, there's no possible way that I can put somebody in the right stream for AirPods because we didn't know you have them and I therefore can't direct people to it. And so you go through this exercise of we don't need to fix it, it works. And then you're like, okay, great. What does that have implications for other things? Okay. Then what would we do? Oh, we're going to make everyone make listings. And you zoom back out again. If every seller is now spending three minutes for every listing that they're making, the number of things they can sell per hour is now dramatically, dramatically lower, which means it's bad for sellers. Okay. Shit. We can't do that again. And so you just have to keep stretching through what are the longer-term implications or what are the knock-on effects of things we're adopting? That is extremely helpful. What's interesting about whatnot is there's this spectrum of whatnot, and then there's this whole trend of agentic commerce where agents are going to be buying the things for you and just working with each other, create a whole new agentic economy. And this is the opposite: humans live talking to each other, buying from each other. Thoughts on that trend and how that might impact you guys? Listen, I, for one, welcome our agentic overlords for things like, I don't want to have to think about light bulbs, air filters, any of the programmatic stuff that I need to run my life. Right. I'm also pretty great with it for really high-intent things. I need a particular cable for my computer. I'm looking for outdoor lights for my house, things where there are really taxing searches. I think about this: got to go to a wedding, which means I need black shoes, but delivered by Thursday because if they don't get here before Thursday, they're no good for me, kind of things. Absolutely. But most of commerce in America isn't actually high intent. How many years are we into e-com now? Like 30 years into e-com, and e-commerce has never exceeded 20% of retail spend in America. Right. The vast, vast, vast majority of retail shopping in the United States is still people going in person and buying things. In the UK it's somewhere, it's like 75, 25. And it turns out actually that a lot of shopping is low intent. I'm going to the mall. I might be because I've got a wedding coming up and I don't have anything to wear. And I'm going to wander around and see what people have available because I don't actually know specifically what I want. And actually the value of stores is that that person who runs that shoe store has agency and taste, and she curates a selection of shoes. She has a level of customer service. She has a window display, which can show me the types of things she has. And I can wander around the mall and actually work out what it is I want to buy or be educated by it. And as it turns out, it's quite pleasant. There's a reason that the mall is a social thing. And so I think agentic is going to be huge. Retail is a seven and a half trillion dollar industry in the U.S. though, so I don't think it's a winner-takes-all thing. What I think live commerce does is it's the first time that we've ever managed to bring together scale and convenience of the internet and also that same social, cultural experience of physical shopping, because at Twitch, we used to basically assume that if it's less than a thousand people in the stream, it's noneconomic because you're operating on CPMs. But you can go into a stream on whatnot and see 30, 50 people in that stream. And if you imagine for a moment that you're running a shoe store at a mall and you had 50 people in your store, you'd never close. You would literally never shut down the store because that's so much more foot traffic than you can ever imagine being in a store, because commerce has totally different economics to entertainment and CPMs aren't the thing that you have to worry about. So I think it's not really in competition with agentic. I think it's a completely different customer need. Amazing. There's room for everyone. I want to end maybe with a question about Twitter. So you were at Twitter. Yes, sir. A PM at Twitter working on growth. I feel like everybody that worked at Twitter as a PM was just scarred from the experience of Twitter. Everyone's do not do things this way. What's something that stuck with you from that experience? What did you learn? What did you unlearn? It is funny. I have said to a friend before that asking someone who was at Twitter in the 2015, 16 era is a little bit like a therapist asking somebody to tell them about their childhood. It's like, you know the trauma that you're bringing up. Yeah. For those who are not familiar with that lore, I think we had nine heads of product in the two years that I was there. It was that level I want to end with a question about Twitter. So you were at Twitter. Yes, sir. A PM of Twitter working on growth. I feel like everybody that worked at Twitter as a PM was just scarred from the experience of Twitter. Everyone's do not do things this way. What's something that stuck with you from that experience? What did you learn? What'd you unlearn? It is funny. I have said to a friend before that asking someone who was at Twitter in the 2015, 16 era is a little bit like a therapist asking somebody to tell them about their childhood. It's the trauma that you're bringing up. Yeah. For those who are not familiar with that lore, I think we had nine heads of product in the two years that I was there. It was that level of chaos. I think my favorite quote was from someone on the partnerships team who said, it felt like Kara Swisher lived in the events. That was how often drama was going on about the place. I think probably two overwhelming things away from my time at Twitter, other than some incredible friends, and I will say that the product diaspora from that era of Twitter is pretty incredible and everywhere. The first one is, if you truly find product-market fit, if you manage to bottle lightning, it doesn't matter how badly you screw up the organization of it. It's huge. Twitter genuinely had that level of product-market fit that you could emotionally feel how much people loved your product. It's a really powerful litmus test to learn relatively early in your career. That's what PMF is, not, hey, the graphs look okay. There's a level of fervor that goes in. I think maybe on the flip side, less positive, what it definitely learned is most of the time you hear it's really complex, it isn't. Leadership's just weak. So the two years that I was there, everyone knew we were going to have to lift the 140-character limit, right? There was working group after working group. The Project Beyond 140 was everywhere because we knew, for example, that people in Japan tweeted six times more often than people in Western markets. It was largely, when we spoke to them, because Kanji lets you say heaps more in the same number of characters than a Romance language did. We knew that was the inevitable end state, but there's obviously a bunch of work that was needed and trade-offs, and no one wanted to make the call. So there was just another design sprint, another cycle. It was another year and a half after I left, I think it was maybe even almost two years after I left, before someone actually did it. And it turns out nobody died, the soul of the place didn't fall apart. I imagine the same discussion went on for editing tweets, which took another two and a half years. Sometimes things aren't actually that complicated. It's just weakly. Yeah. It's funny how far it's come. Now you can write entire blog posts on Twitter, like articles. On the product-market fit piece, I think even more important, there's the network effects of a Twitter, which you spent a lot of time thinking about building marketplaces. To me, watching Elon basically change everything, I forgot who tweeted this, but everything changed: the brand, the name, the website, number of people working there, everything. Yeah. The people, the team. What was the thing that stayed the same? It was basically the network effects of Twitter. Yep. That's the place to be. So everyone's there, and that's hard to break. Even in spite of how much you tried to mess it all up, it's still kicking. That's it. There's your bottle of lightning. Genuinely, you can tell. Yeah. Okay. I'm going to take us to a recurring corner of the podcast, fail corner. Why I like doing this is because people see you, see people like you coming on the podcast, have this illustrious career. Everything's going great constantly. You're just killing it. And they don't see the things that don't work out and the times that you failed. In their life, things often go wrong. So the question for you is just, what's an example of a time in your career where things failed, something you built, some career move you made that didn't work out? And then what'd you learn from that experience? Honestly, mate, and it's very nice of you to say nice things, but I feel like I fail more often than I succeed across the course of my career. Genuinely. To the blog you referenced right at the start, I published in the back of that the actual document we use internally to talk about how we build. And it starts with batting 500 is the goal. You're hoping to be right as often as you're wrong. So there's probably just too many specific examples of times I've screwed up in my career, but there probably is a really common thread to it. I think it's probably an easy trap for any PM to fall into, which is averages mean nothing to the individual, is probably the thing that I'm really scarred by. In any sizable population, it's really attractive to go and look at average utility or average adoption of something. And then you find that only 3% of people use something and then, cool, we can probably get rid of that feature. It's not used widely. But if you don't go a layer deeper and be like, actually, for only 3% of something, there's a group of people for whom that's 100% of what they do. This is their core use case. And for expediency's sake, because somebody doesn't want to maintain a feature anymore, you're just going to deprecate it. And then it turns out you blow up the use case of that group of humans. And then, to your last point about network effects, the ongoing spiral effect of that can be enormous. I think about it a lot in e-commerce. This is somebody's business, right? If we're just not reliable or deprecating a feature, it's kind of like a Westfield mall just turning off the power in the lead-up to Christmas without thinking about it. So there are real downstream impacts to people's businesses that often come from a lack of nuance in understanding metrics, particularly averages. They just lie to you all the time. And I think I've probably screwed up in all of the ways in my career, but most of the time I've made genuinely disappointed-in-myself levels of decisions, it's typically that I've relied on averages without thinking about the individual use cases that are hidden underneath. It makes me think about Jeff Bezos's quote: when you have data and an anecdote, trust the anecdote. Yeah. That's exactly right. Well, Tom, we've gone through everything I wanted to talk about. Is there anything else that you wanted to share, anything you want to leave listeners with before we get to a very exciting lightning round? I think all I'd add, mate, and I've really enjoyed the discussion, so thank you, is I don't think there is one way to do product management. And I don't think there is one way that AI will shape the industry. We're pretty confident that for Whatnot, the product we're building and the culture of the company that we have, this model of fewer PMs who are more senior with a lot more autonomy is right for us. I don't pretend to presume that that will be true for the entire industry, but I do think there has never been a better time to go back to the roots of the actual product work and getting out of that theater. And I think that probably is true everywhere. Even if there are people who are wonderful people managers and really derive their satisfaction from doing that and growing and coaching, I'm sure there'll be loads of places where that's still valuable. So assume that at least half of what I've said is wrong on the same basis that half of the things I've probably ever shipped are not correct. That's why I love these conversations and why I think this work that we do together is important. We are living through the wildest time in our careers. So much is changing, so much is being rethought, as you've described. And it feels like the only way we can make our way through this successfully is to learn from how other people are approaching it, see what they've learned, see what has not worked, take bits that resonate, ignore the bits that seem bombastic or not applicable. Exactly, because no one knows exactly where there are people who are wonderful people managers and really derive their satisfaction from doing that and growing and coaching. And I'm sure there'll be loads of places where that's still valuable. So assume that at least half of what I've said is wrong on the same basis that half of the things I've probably ever said are not correct. That's why I love these conversations. And why I think this work that we do together is important is we are living through the wildest time in our careers. So much is changing, so much is being rethought, as you've described. And it feels like the only way we can make our way through this successfully is to learn from how other people are approaching it, see what they've learned, see what has not worked. Take bits that resonate, ignore the bits that seem bombastic or not applicable. Exactly. Because no one knows exactly where. Elizabeth Stone had this great way of putting it. We're in this kind of, there's a storming phase and then a norming phase. And we're in the storming phase of holy shit. I remember in my PM career, as I started writing and stuff, everyone was always asking me, how has product management changed over the last decade? I'm like, it hasn't changed. It's the same. But it feels like now it actually significantly changed. Although, to your point earlier, actually the core thing and also not will all be the same. Yeah. Yeah. So that's why these are so useful, just for people to see, here's how a team is operating and what they've learned, and here's things to try. It may not work for you, but this is how we learn from each other. With that, we have reached a very exciting lightning round. I've got five questions for you. All right, here we go. What are two or three books that you find yourself recommending most to other people? Okay. Not to be cliched, but The Hard Thing About Hard Things I still think is the best book written about product management, just from a breadth of things that you have to go through and try and do and screw up a lot. Slightly left field, but the best book anyone's ever recommended to me to read, which I now recommend to others, is The Purpose Driven Church by a pastor called Rick Warren. Emmett Shear, the CEO at Twitch, used to make sure that people read it. It's this wild examination of why people emotionally invest in something and how to engineer emotional investment into it from a group of people. It's literally a how-to-go-and-build-a-church guidebook written in the nineties. Definitely worth a read if you're in a community product of any form. And the last one is, if you're looking for fiction or fantasy, which is where I tend to go in the evening, Babel by R.F. Quang. I love when books have never been mentioned before. You get added to the canon of recommended books. It's very fun. David Morgan, favorite recent movie or TV show that you've really enjoyed? David Morgan, Star City on Apple TV. If you liked For All Mankind, it's kind of like the flip of that, but it's the Soviet side. It's like watching The Americans and For All Mankind mixed together. David Morgan, favorite product that you have recently discovered that you really like? David Morgan, This is a very deep cut, so I will apologize to most listeners. Hopefully you've detected the accent. I'm told constantly that my Australian accent is going, but one of the things that I love is every time I go home, I realize actually a bunch of the government services apps in Australia have become phenomenal. You ever had that kind of concept where you're like, I wish the government has all my data. I wish there was just one place where I could, with one click, get my driver's license renewed. I could transfer titles and do all of the admin that slows you down in life. Service NSW actually nailed it. Bizarre to me that I would ever come on a podcast and say, actually a government-run app in Australia, of all places, is it, but I was home recently and had to do all of my life admin, and it's incredible. David Morgan, Wow. Something I heard recently about Australia, while we're on that topic, real quick tangent from lightning round, is with the solar panel build-out that has happened there, there's more electricity available in Australia than they can use. David Morgan, First of all, solar is huge in Australia. David Morgan, So they're giving people free electricity in the middle of the day because there's so much available, and they're like, use all your stuff in the middle of the day because this is otherwise going to go to waste. Bizarre. There is a pitch somewhere that says if AI actually needs loads of electricity in order to be data centers, Australia's entire 21st-century economy should be power. David Morgan, Incredible. That's such good news, that we are finding ways to generate so much energy from solar panels. Bizarre, small piece of regulation about 20 years ago that said, if you're building a new property, you've got to put solar panels on the roof. And it turns out it works great. David Morgan, Oh my God. I love this. I love this optimism of the future because climate energy, use the way through, not the problem. Hear, hear. Okay. Two more questions. Do you have a favorite life motto that you often come back to in work or in life? In my uni days, or back in college for American translation, I used to have a party trick of I'd memorized If by Rud Kipling, because I thought it was deep and really meaningful. But I think, if I'm being really honest, I'll figure it out. Yeah. It's probably the closest. It turns out most things are not as hard as people think. We'll work it out. I'll figure it out. If you're willing to devote the required time, money, effort, energy, you can solve almost anything. And if you're not, then it's probably not that big of a problem. Final question. I imagine people ask you this a lot, but I'm also just curious, what's something you bought on Whatnot in the past month or so that was just awesome, delightful, surprising? The most fun thing I bought recently, I'm not joking, is a live lobster. Recently, one of the things that's really taken off on Whatnot is our fresh and specialty foods category. And so there's this wonderful seller who goes by E Fish Co, who has a seafood store down on the dock in San Diego. And every morning as the boats come in, he literally goes out and live streams all of the crates of seafood coming in off the boats. And then he auctions them off live on Whatnot and ships next day to your door. So I got a California spiny tail lobster shipped direct to my door courtesy of a live stream. And how does this work? They put it in ice, ship it next, it was in a dry-ice kind of container, and it's a UPS overnight on my door the next day. And that is why agent e-commerce is going to be great, but not all-encompassing, because I had no intention of buying a spiny California lobster that morning. Unless your agent decides you need lobster today. And we gotta be honest with you, it was delicious. Amazing. I did not know you could buy stuff like that. Tom, where can folks find you online if they want to follow your writing, slash hiring, talk about what you're hiring for? And finally, how can listeners be useful to you? If you're looking for me online, I'm TD Robbo, T D R O B B O on Twitter, or X, I guess, which is where I do most of my musing. It's a mix of product management and yelling about Warriors games, so apologies in advance. And then on LinkedIn is the other place I put most of my work writing. I will say I try for quality over volume, so don't expect daily drops from me on either. Bangers, just bangers once a year. That was the nicest thing anyone said about me in ages, just dropping casual bangers. And how can folks be helpful? Honestly, would always welcome feedback around Whatnot and how people are finding it and what more we can do better. So hit me up on either of those platforms with hot takes, feedback, or thoughts. And then you're hiring PMs, even in spite of the many strong opinions about product management. Maybe just talk about that and where folks can apply. Sure. Listen, we are constantly looking for PMs. The intent of explaining how many people applied versus hired was not to discourage people. It was more along the lines of the proliferation of product management doesn't itself naturally lend to the people with the skillset that you and I have spent the better part of 90 minutes talking about. That was the nicest thing anyone said about being ages, just dropping casual bangers. And how can folks be helpful? Honestly, would always welcome feedback around whatnot, and how people are finding it and what more we can do better. So hit me up on either of those platforms with hot takes, feedback, or thoughts. And then, you're hiring PMs, even in spite of the many strong opinions about product management. Maybe just talk about that and where folks can apply. Sure. Listen, we are constantly looking for PMs. The intent of explaining how many people applied versus hired was not to discourage people. It was more along the lines of the proliferation of product management doesn't itself naturally lend to the people with the skillset that you and I have spent the better part of 90 minutes talking about right now. But we hired two people yesterday. I'm very excited for them to come start. And we've always got a variety of PM roles open at whatnot. If you just Google whatnot jobs, the right application process will pop up there. Or I've found that the Valley is small enough and product management is not that obscure that you can probably find one of the 20 or so humans who work at whatnot and reach out to them. But we're looking at a variety of things right now, payments very high on our list of what we're doing, as well as logistics. So if anyone is really excited to come work on the future of shipping lobsters overnight, it turns out there's quite a lot of nuanced product work that happens there. Adam Meckler Amazing. Tom, thank you so much for being here. Tom Malkus It was a pleasure, mate. Thanks for having me. Adam Meckler Bye everyone. Adam Meckler Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at Lenny's podcast.com. See you in the next episode. Adam Meckler 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 kind of like 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 just kind of going back and forward in, in reviews. You can see my scar tissue coming through. And on our team, everybody is like, there are managers. There's like, 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 kind of a couple of real advantages of it. The first is if you are a kind of ZP 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 are not 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 like working through three layers of, you know, we divide the problem up against 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, you know, handle the workload of multiple kind of like 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 shift slowly, which is, you know, manage sellers who ship slowly. And you know about the power of kind of like a discovery. You can, in either case, make the kind of correct decision. You know, 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, right? Like where do ads go in the feed? What's the impact to discovery metrics? What's the impact to kind of ad dollars? One of the first things I did when I got 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 kind of like 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 kind of 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 kind of intuitively correct decision early, just because why wouldn't you want, you know, Messi playing for your team when you, rather than trying to kind of have the academy coming along all the time. 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, running, owning a roadmap, writing the strategy doc? Imagine it's the second bucket. Uh, whatever is required to kind of like most effectively ship is the short answer. Mm-hmm . Have I personally shipped some production code at whatnot? Yes. Uh, do I think that's really the best use of my time? Not really. You know, I'm, 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, you know, me and Claude code did not get right. But I do think it starts with like, 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'd actually understand it? Have you sat with engineering and design? You know, 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 a stand up and we go? I think all of that is just like core individual IC work. There's a lot of people that have worked their way up the ladder, a product, become a VP and it doesn't feel exciting to go back to being an IC. Some people like, clearly you love it. You enjoy it. A lot of people are like, I thought I was done with this. I could just work through people. I could think big picture. How do you feel about that? And what do you, what would you say to folks in the, in that bucket? Uh, 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, 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 will 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, you know, I mentioned earlier that like you have to have a matching culture to kind of go with this kind of environment where that's the expectation, you know, where people are like, I don't want to talk about it. I want to just, you know, let's go and do that thing. And in a lot of ways, you know, every, every startup is a reflection of their founders. And so that naturally tends to be, you know, how do they think and how do they want to run the organization? But I've actually found that for a little lot of the cases, you go and talk to somebody who's spent the last five, six years as a, as a senior director at, you know, Meta who spends their entire time in alignment meetings and they miss actually talking to customers and talking to engineers and shipping things. 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 and anthropic. I pulled up this list as you're talking. The CTO of workday is just a member of technical staff and anthropic, a CEO, CTO of Instagram, box, the CTO, super.com CTO. They're just like engineers now at anthropic. Yep. If it is my greatest desire that the whatnot product bench basically looks like that. All of these people with like great skills and great understanding and actually end up coming and building as ICs. What about the, like the, the comp of this path? You know, 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? I actually think it's easier, uh, spicy take, but like go and take the, uh, 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? You know, D2 VP money, particularly if they're having the level of impact, uh, that those folks are having there. Like why not? 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. Yes. What are the other motivations to do this? Is it just the product ends up being better? Is it fewer people? Uh, I certainly think the product ends up being better. Like one of the things that folks have been telling us for a long time is yeah, that won't scale. Like, oh, leadership, isn't going to be able to stay hands-on with what's going on. You're going to need to go on higher tons, more layers. And what we found is that's actually not true, right? It requires a different muscle. You have to make an effort to make sure you genuinely understand, you know, like 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. You know, 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. Uh, and if you push, you know, 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 kind of, you know, data label, because suddenly there's a very smart person who's very invested in like understanding how we do that and helping guide it. And so just that attitude that says like, 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 kind of push our best people to be in the weeds everywhere means that you fix lots of things as you go, when you don't end up kind of just making loads of trade-offs. And I think there's a general belief that like, it's too easy otherwise for growth to hide all sins. Like you get bigger and you just end up scaling and everybody's kind of like working off of averages. So culturally, I think you've got to be really committed to like, let's, you know, whole ass few things. So I tend to say sometimes shout out Ron Swanson, uh, 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, you know, distracting actual velocity in order to help scope future stuff. And now I can sit and, you know, talk to Claude and understand roughly LOEs. Um, 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, 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. So coming back to people that are trying to get a job as a PM, uh, 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? David Starr, Start doing IC work in the role you're in would be my push. Like get back to the basics of like, make sure that you're taking on kind of practical work. Because I just think it's like good to make sure that you're keeping those muscles, you know, well honed. I think it also starts with like pushing internally for those things. Like I would bet that if you started bringing that level of productivity back into the role that you're in probably helps you where you are in addition to kind of help you where you might move to. But I think there's a lot of chatter online, obviously about like PMs or engineers now. And I think that's all well and good. Like it's a great muscle to go and go and hone. As I said, I've, 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 like 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 like take advantage of the scale and the scope that you've got that you can see more and bring more to things. Like, I think most folks who've sat in a, you know, 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, you know, lead a horse to water as opposed to kind of help them understand the answer and then keep moving. And I think there's like something in our coaching styles that we can get back to of like, help somebody understand what good looks like relatively quickly, as opposed to just endless review. Yo-yo. Uh, this point you make about PMs not, uh, shipping to production. I so agree with, this is my mind changed on this recently with a previous podcast guest, um, with this point that PMs already like the leverage PMs have so much more leverage. If they're not sitting there trying to ship to production, they can enabling the team to ship better and faster and making sure the things that shipping are better is a much better use of PMs time than sitting there shipping stuff. I mean, this sounds really silly, mate, but like, it takes me substantially longer to go through the minutiae of like getting, get commit and all of the kind of like pieces that are second nature to engineer aligned than it does to actually work out what the problem is and be able to describe it. So yes, like good practice to try and, you know, make sure you're doing something. Uh, 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, you know, otherwise you're just going to get, you're going to, you're going to fall foul of like a thousand classic traps that every other engineer learned how not to do when they're in L4. 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, uh, other than prototyping, which is the very uh, clear benefit of AI for PMs and product teams. What else, what are maybe in the top three of like, wow, this is really unlocked our productivity and, and the quality of what we do. I mean, the first one, I think by our country mile is data science. You know, we use hex threads internally at whatnot. I'm sure there are other kind of like comparable products, but I think it's almost hard to remember time as a PM before you had tooling like that, where you could genuinely start pulling very nuanced cohorts of data where you could kind of grab an individual user where you've heard a report actually understand, you know, like let's pull logs, help me understand exactly what this user did and saw, how many other users look like this, you know, what would impact be. And then all of a sudden you can build pretty meaningful sensitivity models or like forecasts of what might happen, regression models, et cetera, really, really, really quickly, which is like incredibly powerful. Um, the other thing that we found is it helps us move much more quickly with shipping things because you can spot regressions and weird knock on effects of two products into mixing more quickly than you used to be able to. And I think in, you know, really large, complicated systems, that's always one of the things that ends up slowing you down of like release trains and all of that versus like, if you build the right AI tool, you can spot regressions really quickly, which basically lets people just kind of like go. So I don't know what the future of data science looks like, but I think as a product manager, I've spent less time in the last year talking to a data scientist than I ever have in my career, even though I've probably spent 10 times more time in data and understanding actually how the product's working than I ever have in my career. So that one I think is really powerful. Second one I've already mentioned, which is like stop bothering engineers with how does the code base work and actually just go and talk to Claude and understand it, which is really helpful. You know, I used to say early on in my career that the goal was always to understand your systems at the boxes and lines level of, you know, which system drives which thing. And now there's no excuse not to understand that or a nuanced layer, but the other one, and this might be very specific to whatnot. So I don't know that this will help everyone, but one of the things that I've been lucky to do in my career is basically worked on live products for a decade now. And so it's always been really cool to be able to ship a product and then watch a customer use it and watch them kind of figure it out. So like, I think people have just gotten this experience with like Listen Labs and, you know, others in that cohort of watching people use your product, but I've always been able to sit and watch people use the thing for the first time and go through that new user comprehension gap. What's really cool with a bunch of the AI tooling right now is as they're describing, oh, I'm having a problem. You can literally be watching the code base live and work out, is that actually a bug that's happening right now, right now? Or is that a comprehension gap where it doesn't work as expected? And suddenly you've got this video artifact of someone using your product. You can be analyzing the code base in real time and you can be just talking kind of through AI to the code base to understand what's actually happening. And it's this, it's like, you know, a feedback loop on steroids because all of a sudden you know exactly what's going on customer side, code side, and observe side as like a viewer in real time, which is really cool. That sounds both awesome and very stressful to be building products that are that live in real time. I think about Netflix where they invest in live now and that's just like all you've done for 10 years and how big of a deal that was for them. I know the scale is different, but. Honestly, my second week at Whatnot, I remember sitting in a room watching, so Whatnot for those not familiar, kind of commerce, largely auction platform, that live commerce platform. And there's varieties of different ways to run an auction, but one of them is what's called sudden death, which is like when the timer ends, it ends. Otherwise, the classic auction environment, somebody bids in the last five seconds, it adds 10 seconds back on the clock. And a seller can decide what auction model they want. And I was sitting there watching a seller who was like, these are taking too long. I wish this seven second timer was actually three seconds because I want to move more product. And I watched two engineers in the office look at each other and be like, that's a conflict. We could totally do that. And so they went and updated it in real time and then jumped in the chat of a show and just said, refresh your app. And then all of a sudden, bang, it was operating that way. And I was like, cool, I'm with my people. I'm in like the right place because that's the level of like responsiveness that you can get in a live environment. And obviously, AI means that that's really easy for lots of people to take on. Not that I would touch production code in that kind of way because that's a disastrous idea. But the qualified humans, it's a wonderful one. That is very cool. This episode is brought to you by Mercury. Radically different banking loved by over 300,000 entrepreneurs. And now with command. I've been a customer of Mercury's for over six years. I have never once thought about leaving. Mercury is basically what happens when banking is built by product people, not by bankers. They make it so easy, dare I say fun to send invoices, move money around, set up virtual cards for folks on my team. Does your bank have an API, a terminal native CLI or an AI ready MCP server? I don't think so. And just recently they launched command, a conversational interface built directly into Mercury, which acts as your financial operator. I've been using command to transfer money around to figure out what categories I've been spending the most money in, analyze my cash flows. And just today I used it to find out how much I've made from a specific sponsor over the past year. I just asked how much have I made from X over the past year? 10 seconds later, I have an answer. It is so freaking cool. Visit mercury.com to learn more and apply online in minutes. Mercury is a fintech company, not an FDIC insured bank. Banking services provided through Choice Financial Group and Column NA members FDIC. Coming back to this data science point, I have a friend who's a data scientist and he said, it's a rough time for data scientists because of this exact thing. And to add a little more color, basically their time used to be asked to do some data analysis, do some work with the data, come back. Here's the results. Here's I'm confident in this conclusion. Now their time is basically seeing like half-assed data science work from non data scientists and just like, show me, is this right? And then they're in half the time it's wrong. And they're like, what the hell is my job now? It sucks. Yeah. Listen, I have a lot of empathy for that because I've certainly seen it. Another plug for why having fewer, more senior PMs is helpful because there is a folks who've seen more of those reps and understand. But I also think a lot of the time that lack of clarity comes from the other thing, which is organizations who have historically under invested in data engineering and data structures and good data labeling and whether or not you've got your kind of not just your taxonomies, right, but whether or not you really understand whether or not your data systems and structures are set up well. And so what we found is a lot of our best data scientists are pushing in that direction of like, are we actually correctly updating all of the ways in which our tracking and attribution works so that it's less easy for people to kind of like misunderstand those. And then yeah, using an AI tool to find a piece of data, much like using an AI tool to write code, doesn't absolve you of responsibility to make sure that that was good analysis, good code. It's just tends to be leveraged for those people who are naturally inclined that way. So thinking about these different functions, data science, user research, design, engineering, PM, what I'm hearing so far is we'll need probably fewer PMs, we'll need fewer data scientists. Are there any other roles that you think they'll, they're kind of trending down in terms of, we'll need, and are there any roles trending up like, wow, we're gonna need a lot more of this kind of person. Well, funnily enough, like, as I say, I haven't spoken to a data science in a while. We've, we've certainly still hired plenty because I do think that kind of, uh, all that tracking and attribution and measurement really, really powerful. Um, I also think one of the flip sides of we say, we need fewer, it's like fewer of, for the same output doesn't necessarily mean fewer of in macro, because if you are using the systems, right, you can just grow more quickly. You can build more things. You can take on more stuff. So, you know, I would be surprised actually, if we ended up with like net fewer, I think it's more like net fewer vis-a-vis customer impact for both. Um, certainly I think kind of like trending up over time within these roles are these kind of like, and I don't remember the exact label that people used to use, but this idea of like, um, tech leads that are kind of like a hybrid EM where you're running a very small team kind of running at things because same way that we'd say, you know, the cost of trying something has come down the idea that says you can have kind of core focus, which is the thing we're very big on. We've also found incubating a lot of smaller teams to kind of go over and sit in the corner and just try and build this thing going, you know, it's not quite prototyping, but it's like, go and take a swing at a thing that we've historically thought was too hard is getting cheaper and increasingly has very high leverage. So the idea of like engineering manager light for want of a better term, uh, is the thing that I'm definitely think that we'll see more and more of it's like not quite the technical member of staff, although that must be lovely. Um, but certainly not the kind of like full blown EM role, I think is one that definitely will come about more often. So maybe just to close the loop on this part of the conversation, there's this, you know, trend towards everyone's kind of a builder. PMs are shipping a little bit, being a little more engineer engineers are taking on more of the PM work. How do you think this just kind of maybe plays out over the next couple of years in terms of what product teams look like broadly? Is it still PM engineers, a designer, data scientist somewhere? Is there, how do you kind of envision the canonical product team over the coming years? Great question. Uh, and I don't know that I know what it looks like everywhere. I think what it'll look like at whatnot is it probably still looks mostly like it has historically, which is, you know, there are reasons that you would have a specialist designer, specialist engineers, specialist product management. I think those kind of very concrete teams will largely be reserved for like very specific projects or like things that we have high confidence or conviction that we need to solve, or we're pretty high confidence conviction that we have a path forward on a thing and we want to make good progress. And I think at the edges around that, there's going to be a lot more free space for people to play on like, Hey, I'm reasonably sure I can go and make a meaningful improvement to this thing. And it doesn't matter if you are a designer, an engineer, a product manager, a data scientist, you can, and you should, right? If you're sitting there on a Friday afternoon and you can't focus on the period you're writing, but you're pretty sure you can go and fix something, go for it. Um, and so I think it probably doesn't morph in the more formal sense, but I do think there's just a lot more free space for people who are well-versed in the customer problems, well-versed in the code base and understand some of that macro context. We'll just be empowered to do more and more things. 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, uh, 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 in this, from this post. Like what, what do we, who is really good at this stuff? These, these things, identifying what to build, distilling and communicating requirements, prioritizing everyone's ideas for the highest ROI opportunities, uh, giving feedback and design to improve impact, developing go-to-market strategy, understanding business strategy. Like 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, did you agree with this idea that the PM-y skills seem to be the most valuable now as AI takes on the building? Definitely agree. Also props for bringing in the receipts, even with a timestamp, my friend. Well done. Um, I think what 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 a hundred percent correct that like, 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, you know, optimal efficiency is the point of leverage when doing things gets cheaper, trying things is cheaper, et cetera. Um, 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. Uh, and so I just kind of push us back as a function into like that core work. Yeah. Marty Kagan calls us product theater. A lot of people just do the things that PMs should be doing. And listen, I'm guilty of this. We have, we rewarded it for so long, uh, that like, it doesn't surprise me that that product theater is, is a core skill set for a lot of folks. I just think that there's not a lot of place to hide in that anymore. 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 don't have, 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 really successful product. 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, uh, is kind of really telling, I think. Okay. So kind of going, uh, 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, uh, contrarian take that you don't agree with this hire great people get out of their way. So I wanna hear more about that. And just, is there anything else you've learned about just, uh, elements to building a very successful world-class product team? I mean, nuance required in my like hire people and get out of the way as well, I will say. Um, but a couple, 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 like macro saying for let them work out what the roadmap is, let them work out what the problems are, just like completely devolve, you know, like what's going on. And I think the real answer is obviously the better people you hire, the more you can kind of like totally trust that they're not what they're doing. But we tend to live in a verify then trust land, as opposed to a like totally trust or even trust, but verify, which is like, I'm probably in a better position than any of my kind of directs to understand how all of the different pieces of our system buyer or seller kind of trust fit together. They're almost certainly in a better position than me to understand the nuance of like how any of those individual features work. You know, 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, you know, the PMs on that team. Good. But like, 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, like 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 kind of Grant, who's our founder CEO do, is you'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, you know, again, easier with AI data tools. Let's literally pull up the tickets. Let's literally pull up the code. Let's like 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, kind of very culturally sets the tone for the team that like, we're just seeking truth. And it makes it very much a like us versus you. Like reviews got very into like, 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 PM, your engineers and say, I have some credibility. I can get, you know, 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, you know, we use planning to align the company on like, what are the really important things we have to solve? That's mostly a resourcing discussion, right? Like 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 like, 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 like exactly how does that work? You know, how do our like, you know, 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 like a Google normalized thing? Or is that like, you know, free text, but to 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, you know, I push myself to 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 like hiring people and then like 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. 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? Yeah. I mean, kind of funnily, that's been most of my career. Actually, I worked for three founder founders in a row who are all kind of very product-minded and whatnot. I've got two, which is a blessing actually. In general, I try not to kind of double up if, you know, Grant or Logan, our founders are on a thing, probably doesn't need me. Like what's the advantage of an extra layer? You know, I think jokingly, one of the PMs on the team has referred to it as the two dads problem, where you've just got like two people issuing kind of like 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 like, 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 like fully half my team could be working on something. And I couldn't tell you day to day where it is because you know, 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 spend a bunch of time doing that alignment. I think the second one is like, 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 like, you know, hey, are you open to feedback on this? Have you made up your mind? You know, are you open to a push on this? And you just find that rhythm kind of working with folks. Generally speaking, you know, there's a reason that founder led companies do so well in our industry, you know, 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, you know, making sure that we've got coverage on the places where our founders are. Awesome. So a couple of things you've learned here for building and this, I think in consumer, this is especially important is counterintuitively to how maybe people think things should work. You're finding that the best teams, companies, products end up coming from top down founder led almost, you know, micromanagement is a dirty word to a lot of people, but it's basically being in the weeds is in spite of how people may feel, this actually ends up being leading to better stuff. Top down works well if leadership is good enough to be in the weeds and be specifically correct. I think where it falls apart is where you don't actually know ground truth and then you attempt to manage people from above. And that's where I think the term micromanagement comes from. Otherwise, if you're working from the same data and you have it, I don't know a junior engineer or a entry level designer who isn't stoked to sit there and work alongside the CPO or the CEO and ship something because you're just unblocked. There's no alignment meetings. There's nothing to do. They also find that like you can give way better feedback if you're literally in the detail. And I think the nuance is just like, how do you make sure you can do that in enough places? There's never been a better time to be in, to attempt to be in the detail on things because you can literally query it in real time. I think that's such an important nuance here. The story told is so powerful, this idea of grant, just, okay, I'm going to clear my day. I'm going to spend time going deep on this stuff. That feels like a very necessary ingredient for someone at the top to be making right-goard decisions because to your point, if they don't have all the details, they're not making a decision out of real data. And we can do that because, as I said, we plan what we're doing and then we allocate and then we're dividing and conquering. So he's probably trying to nail three or four most important things at a time. And he's the CEO. He's going to call the ball and say, these are the four things I own right now. And I'm going to be like, great. I'll be over here then. And then within those, like, what am I doing with the rest of my day that is more important than nailing the five things I've said, we'll get done this half. Like if it's anything other than maybe hiring standing meetings, any of that stuff, you can just clear it and set the tone for the team that like, until we understand it, we can't do anything else. Say somebody is looking for a CPO role or a first PM role, kind of similar, basically working for a founder. What would be your advice for them to land in a place where they're happy and not just super frustrated by, by this kind of middle layer where they just don't actually have any agency. Yeah. I mean, I think the first thing you've got to work out is like, why do you want it? Right. There's this idea that like the CPO's job, you get to decide all the roadmaps and all those things. And I've got bad news for you. That's like not strictly true. But I think it also comes down to like spending some time with that person to work out, like, how do we jam on a topic? How do they like to get push? How do they not? And then you spend a lot of your time calibrating. So like, before I joined whatnot, I think Grant and I had like five or six different coffees where we talked about like, how do you get, you know, this type of team to move? How do you work on those things? And then I obviously went through a series of interviews and actually came down to kind of LA where Grant Logan were based at the time and spent a whole day with them, just like in a room, going through a couple of different problems, talking through different things in the roadmap, just like really getting into it. And I tried through that to kind of be my most ordinary self, as opposed to like interview self, if that makes sense. Because you kind of got to ask yourself, do I really want to spend my whole time like having this discussion and this debate? But like, I like being a CPO or kind of a product lead, because in a lot of ways, what I'm doing is I'm like helping translate that vision and that intuition into reality. And then, you know, there is an art to learning how to push somebody without kind of competing with them. And I think a lot of the times I've seen the CPO CEO relationship go badly and ends up with like, the CPO is competing with the CEO for vision and they end up at like loggerheads. And I think, you know, that's not your job. I want to ask more about that. This art of pushing back and, and, you know, nudging things in your direction. Is there kind of one trick or one tip you might share with folks to get, to be good at, because a lot of people deal with exacts and they're always trying to, you know, get them to agree to what they want. I think the first thing is like, don't treat it as a trick. I mean, you're not trying to get an answer and a yes, you're trying to kind of seek truth is like my first statement. And so I wouldn't say it's especially common that we start out of alignment, but I do think, you know, part of your role, if you're one of the more senior product folks in the room and the, the CEO, or, you know, if you're a director and it's the CFO in the room is like pushing the team in a way that you don't really expect, or you don't understand is like, start from a place of curiosity. Does that person have more context than you? Or is there a thing that you're not aware of that is guiding it? So I often try and start with like, can you, can, am I hearing you right? That this is your prior, is there a, you know, piece of context or something that I don't have that helps inform that prior cool. Make sure everybody's on that same baseline. And you know, I coach my fans to do this with me all the time too. Like if I'm coming at you from an angle, you don't expect pause and make sure that you understand why. And then after that, you know, I try and do a couple of different things. You're obviously just, people are people, right? They have good days. They have bad days. Sometimes it can be as simple as like, is your mind made up on this? Or are you open to input? If the answer is like, no, I'm pretty set that this is the answer. Shut up. Like, don't pick a fight for the purposes of picking a fight. If the answer is like, actually, yes, you're welcome to push me, but I'd need to see data. If I don't have any data in the room, if it's just my opinion, then I, the terms of the debate are pretty clear. If I have fresh data, bring it. If I really believe a thing and I don't have data question why, or go get it and then go back to them with the data. But if the answer is like, if nobody's got data, it's just two opinions, the CEO's opinion is going to win. And like, that's okay. Check your ego at the door, get to the answer. But if you've got data, bring it. And then sometimes it's like, just make sure that you're debating for the right reasons. I think it's easy in your PM theater that you're describing of like, wanting to make sure that you set the framing and the tone. And there are genuinely times in our industry where like nomenclature matters and exactly what word is used can be really important. But a lot of the time it doesn't. There's a concept that I heard come up a bunch when I talk to people who work with you. The phrase was play the accordion. Explain. So I mentioned earlier, I'm not huge on frameworks, but I do think there's a mental model, which is quite useful that goes to the thing that you and I discussed earlier on, like think through a problem, do the mental work, even if you're not shipping at all, which is like, obviously the magic of code is that you can kind of ship things and iterate really quickly and get data as you go. And I think one of the trappings that comes with that is you're just iterating forward and throwing spaghetti at a wall and you don't really know what direction you're going in. I think there's a second failure mode, which is people sit down and write up these long roadmaps and strategic vision docs of what we'll do over the next two or three years that kind of loses the comparative advantage we have over every other industry, which is learning. Like A-B tests mean that you can update your understanding of a problem and therefore change your direction as you go. So the point of the analogy of play the accordion is if you think about like a piano accordion, before you can play a note, you've got to stretch it all the way out, bring the air in. So like, what is it we're trying to get done? But you don't make music until you press the key and push it all the way back into V1. And then when you go to play the next kind of like progression, you pull it all the way out again. Okay. Given what we just learned, what do we do? And then you go and build the next thing again. And like, you've got to get used to this motion that says like, this isn't creating value, like pulling it out, doesn't actually do anything. All the value is created here. But until you are going through this motion constantly of saying, well, reevaluate what we understand, how does this change what we're doing? You're probably not playing the right thing. And I know I'm probably bastardizing somewhere in the comments, there's going to be a musician who points out to me that this is actually also one of the ways you make music. But I found it just a generally very valuable, like memory device for PMs to be like, you've got to constantly be zooming out and pushing back in, zooming out and pushing back in. Yeah. That is such a fun analogy. Because you know, it's like the, even though you make music expanding it, it's like inward, or it's like learning from the, the compression. What did we learn? How do you communicate to everyone? Exactly. Back to shipping. It's like a different kind of music, internal music, external experiment. Yeah. Because genuinely there are people who are really big on roadmaps and there are people who are really big on iteration. I think the honest answer is you've got to do both. You can't over index on either. So the lesson here is run experiments, but then make sure you think about the implication of the, of the result at the bigger picture. And then what are we trying to do? Have a plan. Like I think the system works this way. I have this belief that if we change the way that discovery algorithms work for X, Y, Z reasons, it will have this impact. What's the smallest thing I can do to prove that. Okay. It worked. Great. No change to plan. V2. Oh, that didn't work. V3 is going to have to be different. And you just kind of want to always be going through that motion. People not watching in YouTube. Tom is moving his hands. Just deculating. What's like a, what's, what's like a context where you had said to someone, hey, we go play the accordion or we're playing the accordion. Like, like what are they usually doing wrong? Tom is going to be shipping something with a, in a very local sense without necessarily understanding impact. So, uh, an example right now is, you know, the core of most marketplaces is listings, right? Like if you try and think about amazon.com without listings, there's basically nothing there. It's a bunch of, you know, it's a left rail or right rail and some videos, um, in video commerce and live commerce, whatnot, you don't really historically need listings. If I want to sell you a pair of AirPods, I could literally hold them up to screen and show you them and describe them and say, they're AirPods. I'm going to start them at a dollar. And as a buyer, you now have all the information you need in order to kind of like make a purchase decision, which is great. And so you may not have to invest in making listings the way that someone else does. And that's probably net good for a seller because it takes like three and a half minutes to make a listing. Uh, and it takes zero minutes to describe a thing and hold it up. Uh, but you then zoom out and say, Oh shit, new buyers are going to come to live commerce and expect search to function. If I don't know what you're selling until after you've sold it, there's no possible way that I can put somebody in the right stream for AirPods because they didn't, we didn't know you have them and I therefore can't direct people to it. And so you go through this exercise of like, we don't need to fix it. It works. And then you're like, okay, great. What does that have implications for other things? Okay. Then what would we do? Oh, we're going to make everyone make listings. And you're like, zoom back out again. If every seller is now spending three minutes for every listing that they're making, the number of things they can sell per hour is now dramatically, dramatically lower, which means it's bad for sellers. Okay. Shit. We can't do that again. And so you just, you have to keep stretching through the, like, what are the longer term implications or what are the knock-on effects of things we're adopting? That is extremely helpful. What's interesting about whatnot is it's, there's like this spectrum of like whatnot. And then there's this whole trend of agentic commerce where agents are going to be buying the things for you and just working with each other, create a whole new agentic economy. And this is like the opposite humans live talking to each other, buying from each other, uh, thoughts on that, on that trend and, and how may, how that might impact you guys. Uh, listen, I, for one, welcome our agentic overlords for things like, I don't want to have to think about light bulbs, air filters, any of the programmatic stuff that I need to run my life. Right. Um, I'm also pretty great with it for like really high intent things. I need a particular cable for my computer. I'm looking for, you know, outdoor lights for my house, things where there are really taxing searches. I think about this, you know, got to go to a wedding, which means I need black shoes, but delivered by Thursday. Cause if they don't get here before Thursday, there are no good for me kind of things like absolutely. But most of commerce in America isn't actually high intent. Like how many years are we into e-com now? Like 30 years into e-com and e-commerce has never exceeded 20% of retail spend in America. Right. The vast, vast, vast majority of retail shopping in the United States is still people going in person and buying things. Uh, in the UK it's somewhere, it's like 75, 25. And it turns out actually that a lot of shopping is low intent. I'm going to the mall. I might be because I've got a wedding coming up and I don't have anything to wear. And I'm going to wander around and see what people have available because I don't actually know specifically what I want. And actually the value of stores is that that person who runs that shoe store has agency and taste and she curates a selection of shoes. She has, you know, a level of customer service. She has a window display, which can show me the types of things she has. And I can wander around the mall and actually work out what it is I want to buy or be educated by it. And as it turns out, it's quite pleasant. Like there's a reason that the mall is a social thing. And so I think, you know, that agentic is going to be huge. Retail is a seven and a half trillion dollar industry in the U S though. So I don't think it's a like winner takes all thing. What I think live commerce does is it's the first time that we've ever managed to kind of like bring together scale and convenience of the internet. And also that same kind of like social cultural experience, uh, of physical shopping, because you know, at, at Twitch, we used to basically assume that if it's less than a thousand people in the stream, it's non-economic because you're, you're operating on CPMs. So, but you can go into a stream on whatnot and see 30, 50 people in that stream. And you, you imagine for a moment that you're running a shoe store at a mall and you had 50 people in your store, you'd never close. Like you would literally never shut down the store because that's so much more foot traffic than you can ever imagine being in a store because commerce has totally different economics to entertainment and CPMs aren't the thing that you have to worry about. So I think it's not really in kind of like competition with Igentic. I think it's a completely different kind of like customer name. Amazing. There's room for everyone. I want to end maybe with a question about Twitter. So you were at Twitter. Yes, sir. A PM of Twitter working on growth. I feel like everybody that worked at Twitter as a PM was just scarred from the experience of Twitter. Everyone's do not do things this way. What's, uh, what's something that stuck with you from that experience? What did you learn? What'd you unlearn? It is funny. I, uh, I have said to a friend before that asking someone who was at Twitter in like the 2015, 16 era is a little bit like a therapist asking somebody to tell them about their childhood. It's like, you know, the trauma that you're, you're bringing up. Yeah. For those who are not familiar with that lore, I think we had nine heads of product in the two years that I was there. It was that level of kind of chaos. I think my favorite quote was from someone on the partnerships team who said, it felt like Kara Swisher lived in the events. That was like how often drama was going on about the place. Um, I think LendingEye probably took two overwhelming things away from, from my time at Twitter and other than like some incredible friends. And I will say that the product diaspora from that era of Twitter is pretty incredible and everywhere. The first one is like, if you truly find product market fit, like if you managed to bottle lightning, doesn't matter how badly you screw up the organization, uh, of it, like it's huge. And like Twitter genuinely had that level of product market fit that you could emotionally feel how much people loved your product. And it's a really powerful litmus test to learn relatively early in your career. That's what PMF is not like, Hey, the graphs look okay. Right. There's like a level of fervor that goes in. Um, I think maybe on the flip side of like, less positive is like what it definitely learned is like most of the time you hear it's really complex. It isn't leadership's just weak. So, you know, the two years that I was there, everyone knew we were going to have to lift the 140 character limit, right? There was working group after working group, like the project beyond one 40 was like everywhere because we knew for example, that like, uh, people in Japan tweeted six times more often than people, uh, in Western markets. And it was largely when we spoke to them because Kanji lets you say heaps more, uh, in the same number of characters than, uh, you know, a romance language did. We knew that was the inevitable end state, but there's obviously a bunch of like work that was needed and trade-offs and just no one wanted to make the call. And so there was just like, you get another design sprint, you get another cycle. And it was another year and a half after I left, I think it was maybe even almost two years after I left before someone actually did it. And it turns out, you know, nobody died for the soul of the place. Didn't fall apart. I imagine the same discussion went on for editing tweets, which took another two and a half years. Like sometimes things aren't actually that complicated. It's just weekly. Yeah. It's funny how far it's come. Now you can write entire blog posts on Twitter, like articles, not being bad on the product market fit piece. I think even more important, there's the network effects of a Twitter, which you spent a lot of time thinking about building marketplaces. Like to me, watching Elon basically change everything. I forgot who tweeted this, but just like everything changed the brand, the name, the website, uh, number of people working there, everything. Yeah. The people, the team, like what, what was the thing that stayed the same? And it was basically the network effects of Twitter. Yep. That's the place to be. So everyone's there and that's hard to break. And even in spite of how much you tried to mess it all up, uh, it's still kicking. That's it. There's your bottle of lightning. Genuinely, you can tell. Yeah. Okay. I'm going to take us to a recurring corner of the podcast fail corner. Why I like doing this is because people see you, see people like you coming on the podcast, have this illustrious career. Everything's going great constantly. You're just killing it. And they don't see the things that don't work out and the times that, uh, you failed and in their life, things often go wrong. So, uh, so the question for you is just, what's an example of a time in your career where things fail something you built some career move you made that didn't work out. And then what, what'd you learn from that experience? Honestly, mate. And it's, it's very nice of you to say nice things, but I feel like I fail more often than I succeed across the course of my career. Genuinely, uh, to the, to the blog you referenced right at the start, I published in the, in the back of that, the actual document we use internally to talk about how we build. And it starts with like batting 500 is like the goal. So like, you're hoping to be right as often as you're wrong. So there's probably just too many specific examples of, of times I've screwed up in my career, but there probably is a really common thread to it. And I think it's probably an easy trap for, for any PM to fall into, which is like, um, averages mean nothing to the individual is probably the thing that I've like really scarred by, uh, in any sizable population, it's really attractive to go and look at like average utility or average adoption of something. And then you find that like, you know, only 3% of people use something and then like, cool, we can probably get rid of that feature. It's not used widely, but if you don't go a layer deeper and be like, actually for like, you know, it's only 3% of something, but there's a group of people for whom that's a hundred percent of what they do. This is their core use case. And for expediency sake, because somebody doesn't want to maintain a feature anymore, you're just going to deprecate it. And then it turns out you like blow up the use case of that group of humans. And then to your last point about network effects, the ongoing spiral effect of that can be enormous. You know, I think about it a lot in e-commerce of like, this is somebody's business, right? If we're just not reliable or like deprecating a feature, it's kind of like a Westfield mall, just turning off the power in the lead up to Christmas without thinking about it. And so like, there are real downstream impacts to people's businesses that often come from just like a lack of nuance in understanding metrics, particularly averages. Like they just lie to you all the time. And I think, you know, I've probably screwed up in all of the ways in my career, but most of the time I've made genuinely, like I'm disappointed in myself levels of decisions. It's typically that I've relied on averages without thinking about the individual use cases that are hidden underneath. It makes me think about Jeff Bezos as a quote, when you have data and an anecdote, trust the anecdote. Yeah. That's exactly right. Well, Tom, we've gone through everything I wanted to talk about. Is there anything else that you wanted to share? Anything you want to leave listeners with before we get to a very exciting lightning round? I think all I'd add, mate, and I've really enjoyed the discussion. So thank you. Is like, I don't think there is one way to do product management. And I don't think there is one way that AI will shape the industry. So like, we're pretty confident that for whatnot, the product we're building and the culture of the company that we have, that, you know, this model of like fewer PMs who are more senior with like a lot more autonomy is right for us. I don't pretend to, you know, presume that that will be true for the entire industry, but I do think there has never been a better time to go back to the roots of like the actual product work and getting out of that theater. And I think that probably is true everywhere. Even if you are still, you know, there are people who are wonderful people managers and really derive their satisfaction from doing that and growing and coaching. And I'm sure there'll be loads of places where that's still valuable. So assume that at least half of what I've said is wrong in the same basis that half of the things I've probably have ever shifted are not correct. That's why I love these conversations. And why I think this work that we do together is important is we are living through the wildest time in our careers. So much is changing so much as being rethought as you've described. And it feels like the only way we can make our way through this successfully is to learn from how other people are approaching it, see what they've learned, see what they've has not worked. Take bits that resonate, ignore the bits that seem bombastic or not applicable. Exactly. Cause like no one knows exactly where Elizabeth Stone had this great way of putting it. We're in this kind of, there's, there's a storming phase and then norming phase. And we're in the storming phase of holy shit. Like I remember in my PM career, as I started writing and stuff, everyone was always asking me, how has product management changed over the last decade? I'm like, it hasn't changed. It's the same basically. But it feels like now it actually significantly changed. Although to your point earlier, actually the core thing and also not will all be the same. Yeah. Yeah. So, so that's why these are so useful just for people to see, here's how a team is operating and what they've learned and here's things to try and it may not work for you, but this is how we learn from each other. With that, we have reached a very exciting lightning round. I've got five questions for you. All right, here we go. What are two or three books that you find yourself recommending most to other people? Okay. Not to be cliched, but the hard thing about hard things I still think is the best book written about product management. Just from a like breadth of things that you have to go through and try and do and screw up a lot. Slightly left field, but the best book anyone's ever recommended to me to read, which I now recommend to others, is the purpose driven church by a pastor called Rick Warren. Emmett Shear, the CEO at Twitch, used to basically make sure that people read it. It's this wild examination of why people emotionally invest in something and how to engineer emotional investment into it from a group of people. It's literally a like how to go and build a church guidebook written in the nineties. Definitely worth a read if you're in a community product of any form. And the last one is if you're looking for kind of like fiction or fantasy, which is where I tend to go in the evening, Babel by RF Quang. I love when books have never been mentioned before you get added to the canon of recommended books. It's very fun. David Morgan, favorite recent movie or TV show that you've really enjoyed? David Morgan, Star City on Apple TV. If you liked For All Mankind, it's kind of like the flip of that, but it's the Soviet side. It's like watching the Americans and For All Mankind mixed together. David Morgan, favorite product that you have recently discovered that you really like? David Morgan, This is a very deep cut. So I will apologize to most listeners. Hopefully you've detected the accent. I'm told constantly that my Australian accent is going, but one of the things that I love is every time I go home, I realize actually a bunch of the government services apps in Australia have become phenomenal. You ever had that kind of concept where you're like, I wish the government has all my data. I wish there was just like one place where I could with one click, get my driver's license renewed. I could like transfer titles and do all of the admin that slows you down in life services, New South Wales, actually nailed. Bizarre to me that I would ever come on a podcast and say, actually a government run app in Australia of all places is it, but I was home recently and had to do all of my life admin and it's incredible. David Morgan, Wow. Something I heard recently about Australia while we're in that topic, real quick tangent from lightning round is with a solar panel build out that has happened there. There's more electricity available in Australia than they can use. David Morgan, First of all, solar is huge in Australia. David Morgan, So it's like they're giving people free electricity in the middle of the day because there's so much available and they're like, use all your stuff in the middle of the day because this is otherwise going to go to waste. Bizarre, There is a pitch somewhere that says if AI actually needs loads of electricity in order to be data centers, Australia's entire 21st century economy should be power. David Morgan, Incredible. That's like such good news that we are finding ways to generate so much energy from solar panels. Bizarre, Small piece of regulation about 20 years ago that said, if you're building a new property, you've got to put solar panels on the roof. And it turns out it works great. David Morgan, Oh my God. I love this. I love this optimism of the future because, you know, climate energy like use the way through not, not the problem. Hear, hear. Okay. Two more questions. Do you have a favorite life motto that you often come back to in work or in life? Uh, in my uni days or, uh, back in college for American translation. Uh, I used to have a party trick of I'd memorized if by Rudd Kipling, because I thought it was like deep and really meaningful. Um, but I think if, if I'm being really honest, uh, I'll figure it out. Yeah. It's probably the closest, you know, like it turns out most things are not as hard as people think like we'll work it out. I'll figure it out. If you're willing to devote the required time, money, effort, energy, you can solve almost anything. Uh, and if you're not, then it's probably not that big of a problem. Final question. I imagine people ask you this a lot, but I'm also just curious, what's something you bought on whatnot in the past month or so that was just awesome, delightful, surprising. The most fun thing I bought recently, I'm not joking is a live lobster. So, um, recently, one of the things that's really taken off on whatnot is our like, um, fresh and specialty foods kind of category. And so there's this wonderful seller who goes by E fish co who has a seafood store down on the dock in San Diego. And every morning as the boats come in, he literally goes out and live streams all of the crates of seafood coming in off the boats. And then he auctions them off live on one month and ships next day to your door. So, uh, I got a California spiny tail lobster shipped direct to my door courtesy of a live stream. And how does this work? They put in ice, uh, ship it next, it was in like a dry ice kind of like container and it's a UPS overnight on my door the next day. And that is why agent e-commerce is going to be great, but not all encompassing because I had no intention of buying a spiny California lobster that morning. Unless your agent decides you need lobster today and we gotta be honest with you, it was delicious. Amazing. I did not know you could buy stuff like that. Tom, where can folks find you online if they want to follow your writing, uh, slash hiring, talk about what you're hiring for. And finally, how can listeners be useful to you? If you're looking for me online, I'm TD Robbo, T D R O B B O on Twitter, which is, or X, I guess, which is where I do most of my musing. Uh, it's a mix of product management, uh, and yelling about warriors games. So apologies in advance. Uh, and then on LinkedIn is the other place I've put most of my kind of like work writing. I will say it's, uh, I, I try for quality over volume. So don't expect, uh, daily, daily drops from me on either bangers, just bangers once a year. That was the nicest thing anyone said about being ages, uh, just, just dropping casual bangers. And how can folks be, be helpful? Honestly, uh, would always welcome feedback around whatnot, uh, and how people are finding it and what more we can do better. So like hit me up on either of those platforms with, you know, hot takes, uh, feedback or thoughts. And then, uh, you're hiring PMs, even in spite of the many strong opinions about product management, maybe just talk about that and where folks can apply. Sure. Uh, listen, we are constantly looking for PMs. The, the intent of kind of like explaining how many people applied versus hired was not to discourage, uh, people. It was more along the lines of like the proliferation of product management doesn't itself naturally lend to the people with the skillset that you and I have spent the better part of 90 minutes talking about right now. But you know, we hired two people yesterday. I'm very excited for them to come start. Um, and we've always got a variety of, of PM roles open the whatnot. If you just kind of Google whatnot jobs, um, the, the right kind of application process will pop up there. Or I've found that, you know, the Valley is small enough and product management is not that kind of obscure that you can probably find one of the 20 or so humans who work at whatnot and, and reach out to them. But we're looking at a variety of things right now, uh, payments very high on our list of what we're doing as well as logistics. So if anyone is really excited to come work on the future of shipping, uh, lobsters overnight, uh, it turns out there's quite a lot of nuanced product rates happen there. Adam Meckler Amazing. Tom, thank you so much for being here. Tom Malkus It was a pleasure, mate. Thanks for having me. Adam Meckler Bye everyone. Adam Meckler Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast. You can find all past episodes or learn more about the show at Lenny's podcast.com. See you in the next episode. Adam Meckler