Rich Mironov: AI Should Change Product Management... Just Not The Way You Think

If I can deliver products 10 times as fast or 10 times as much, my customers don't automatically decide to spend 10 times as much on me, right? Budgets don't go up because development gets faster. So we're going to see 10 times as many products in each market segment, but no more money to spend. The world isn't going to grow at the rate that my engineers can get faster. Hello and welcome to One Night in Product, the show where I chat to some of the brightest minds in and around products from across the globe to help you see product management in a whole new light. If that sounds up your street, don't forget to dive into the back catalog on your favorite podcast app or on YouTube, and of course, follow, share, or drop me a comment or review. And if you'd like to speak to me about how I can help your company identify growth opportunities and build the capability to pursue them, drop me a line. The email address is in the show notes. I'd love to chat. On this episode, I'm speaking to the returning Rich Miminov, longtime product management thought leader, consultant, and product leadership coach, who LinkedIn recently informed he just celebrated his 25th anniversary at Miminov Consulting, a company I'm assuming he started in his late teens, and which he co-runs with his adorable chief canine officer. Rich wrote The Art of Product Management, which feels very apt given that just like art, some people now seem determined to outsource the whole thing to AI. He also wrote Money Stories, which is equally apt because sooner or later, all these AI companies are going to have to probably start making some money. He's here tonight to talk all about what product management means in a world where we can apparently 10x everything with AI, and whether all those extra Xs are actually going to get us anywhere useful. Rich, thanks for coming. Rich Miminov Oh, it's my pleasure. Always. Thanks. Adam Well, the pleasure is all mine. Is it ours? I don't know. It's a mutual pleasure. Like sharing an ice cream or something like that. But let's get away from that horrible and painful image. And first things first, I have to just ask, obviously, you and I saw each other back in London, not a while back, I ended up having to take a big old pile of books home, which was very well appreciated. But just for the listeners, what are you up to these days? And how are you filling your time? Rich Miminov Since I relocated to Portugal about a year and a half ago, which is my part time sloping down, not working so hard, not in the full time grind anymore story. I'm continuing to write, you know, I got a book out late last year, which we'll talk about, I hope. I'm doing some part time coaching of chief product officers and heads of product, mostly at enterprise B2B companies that are big enough to have political and organizational problems. And, you know, trying to keep my pulse on what's happening, really, in the product space. So getting some conferences in Europe and, you know, networking with all these folks who are doing really important work. Tom Clougherty Well, that's, yeah, we talked about the book as well. And of course, we've got all of the books, all three of your books behind. Rich Miminov Yeah, three of them, two of them, one's a reissue. So there's three covers, but there's only two different books. Tom Clougherty But, but yeah, so obviously, Al, that fell on my foot. So this is Money Stories, which is the new one. And of course, the last time you came on the podcast, we were kind of talking about that a little bit, and maybe some of the concepts that underpin it. You've subsequently written a book, it's nice and thin, but at the same time packed with insights, trying to help product teams make a better case for product prioritization, you know, to teams that maybe don't necessarily care about all this product thinking that we keep talking about. Book's been around for a little while now, obviously, you've been talking, doing conference talks about some of the concepts from it as well. How's the feedback been so far, both on the book and Money Stories in general? I think, well, good feedback, of course, because I can't hear the not so good feedback. But I think it's a useful concept. And so folks, you know, folks are finding that it's a good translation guide, in particular, when we're dealing with the executives on our go to market side of our companies. So VPs of sales and chief marketing officers who, in my observation, are deeply, deeply uninterested in how we build products and our product operating models and tech debt and all the stuff that we do and love every day, most of them don't care about. And so it's a bit of a head shift in a translation guide that says, if you want someone who controls budgets at your company to care about what you're doing, it's much more useful to talk about how it's going to make them money than why it's going to follow some particularly operating model or structure or flowchart. Because what they hear when we say that is they'll never get what they want. And by the way, they mostly won't get what they want. But at least we're talking about tradeoffs in money, instead of in losing people and staff. Have you heard any stories, though, because, you know, obviously, you know, you and I have spoken about this before, we work or have the companies that you've worked for in the past and the companies I work for, within the UK, you know, tend to be certain types of companies, where stuff like that is absolutely true. And kind of winning those kind of hearts and minds is an important part of the of the job. Yeah. But also it kind of, you know, when you start talking about money and revenue and such, it starts to some people sound a bit not producty. Have you ever had any of that feedback? Oh, sure. Given a talk or such that you kind of almost hadn't, not necessarily betraying, but certainly kind of going against these principles of user first and, you know, making sure that we cause delight and stuff like that, and kind of boiling it down to cold hard numbers. Sure. And I just observed that many of the folks that are companies who are making the decisions about whether they hire us and give us money and let us do things, aren't very interested in user joy and aren't very interested in product wonderfulness, or even whether we've correctly solved the exact problem that the customer has instead of the one that they really wanted us to fix. Right. If you're in charge of revenue at some big software company, particularly on the B2B enterprise side, you get fired if we don't bring enough numbers in this quarter. And all of these philosophical arguments about how many designers can dance on the head of a UX platform, honestly, they don't matter so much to the rest of the company. And so we get very self-involved. We get very wrapped up in the goodness and the perfection of what we think we're doing. And mostly that doesn't land with the rest of the company. So I think it's much more about reading the room and understanding how things really do work instead of having some, you know, platonic ideal for how we do backlog management. Because you know what? The world just doesn't care. Yeah, no, fair enough. Well, you know, check out the book, try not to drop on your foot that that did hurt quite a lot. But, you know, this idea about... It's only 80 pages and it's soft cover. If you've got dangerous feet there, let me know. I'll ship them somewhere else. But talking about how the world works, oh, and you know, how it should work and how it does work and kind of what's going on out there and sort of the wider world of product management. One of the things that you've been writing a lot more about recently, and kind of the reason that we wanted to do another run through today is this idea around what's going on with AI. And you've been writing about some of the conversations that you've been having with product leaders, with CEOs about this kind of AI boom, what it means for their businesses. So obviously a lot of hype out there at the moment and kind of people talking about the impact that it's going to have on product management, but also software development and companies in general. One report I read recently, before we talk about your stuff, one report I read recently said with a straight face, what once took a team of 12 to build one product, now 12 product builders deliver 12 products. Now, I do have to ask, do you, Rich Mironov, need 12 times as many products? Because I'm not sure I do. And I'm curious if that's just me. Rich Mironov And in fact, that's the place I jump in here. It's to say, I actually believe that there are some companies that can generate code 10 times as fast, maybe even 50 times as fast, right? I'm not sure that the code that's being generated is of commercial product quality. And so I think the next step where we all start to slow down is on the engineering side and say, well, are we doing security checks and usability checks? And does it fit the architecture? And does it actually work in an enterprise sense? Because if, you know, just imagine I'm shipping a manufacturing ERP system and my customers are building cars, right? It turns out if the thing falls over a lot or gets hacked, or when AWS has some outage, you know, it disappears. There's a lot more to a commercially viable product than, did I generate code fast? And I haven't yet seen that companies are delivering 10 times as many workable, tested, thoughtful, useful products as they're generating code, right? But that's still the engineering problem, right? So when we talk about the product problem, I work backwards because as good product folks, we start with users and budgets in the world, right? And here's my starting observation. In any one particular market, if it's not a new market, there's already a bunch of incumbents and there's already a bunch of money being spent and the budgets are pretty well set and the customers are more or less satisfied, right? So if I'm a new entrant into a market, right? The way I make money is I take customers away from the existing players because budgets don't go up, right? If I can deliver products 10 times as fast or 10 times as much, my customers don't automatically decide to spend 10 times as much on me, right? Budgets don't go up because development gets faster, okay? So, and you know, if I just sort of grab some market, right? So again, I'm thinking a lot about manufacturing ERP markets, right? There are only so many manufacturers, they're running so many factories and so many assembly lines and stuff. Their budget didn't go up because I could ship code faster. In fact, I think it's the reverse that happens, which is as more companies can come into this market as new entrants and as more of the current companies in the space can ship product faster, right? We have more competition, more features, more fighting for that attention. And I expect prices to come down, right? If I'm the new entrant to this market, the very best way for me to win customers is to commit at a quarter of the price of the existing players, right? So we're going to see 10 times as many products in each market segment, but no more money to spend. And that's going to put on price pressure and that's going to actually depress the total amount of budget that's going to be spent on this segment, right? You know, we may be servicing supermarkets, there won't be 10 times as many supermarkets just because my engineers are efficient, right? Or, you know, nail salons and health spas and private gyms, right? The world isn't going to grow at the rate that my engineers can get faster. So to summarize, and this is something that you wrote in one of your articles, this idea that 10 times more products, you know, let's be more conservative and not go for 12 times, but you know, 10 times more products doesn't mean 10 times bigger markets or budgets, that's just what you said, or 10 times more revenue, exactly what you said, kind of touches on everything you just said. And it kind of feels obvious if you sit there and think about it, because again, I don't need 10 or 12 times as many things in my daily life. Most of our customers don't need that either. They've not got money to buy all those things. So given that that does sound so obvious, and maybe it's just that we're super smart, although we, you know, knew, obviously that the product people like to think they're smart, maybe we're not always the smartest, but yeah, we're not stupid. And the people that are talking about this stuff ain't stupid either. So why do people seem to be actually thinking that this narrative of like 10 or 12 times as many products is actually a good plan, based on the kind of people you've seen? I think if you look at the loudest voices in the AI conversations, they're the people who build AI products. The benefit from you making 12 times as much stuff. That's right. And they're the people who are being highlighted and applauded in the press releases of companies that make AI products. And the ones who are being invited to come to the front of the auditorium at big conferences to talk about how they're building AI product 10 times as fast, right? And almost all the metrics for this last 6 or 12 months have been code delivery metrics. Lines of code and stuff. Lines, right. I mean, we all read the book about how in the 1960s, you know, IBM did keystrokes and lines of code and it didn't end well. I think this is some combination of sort of willful blindness and not paying attention, right? Because the CEOs of companies aren't actually being rewarded for delivering code faster. At some point very soon, they're going to have to be rewarded for delivering revenue faster, right? And actually, let me take one side trip here because I think there's a special case here where this isn't true, okay? Which is if in the short term, you're building AI tools for AI teams that are using it to build AI software so they can ship AI software fast, right? You're actually in a revenue growth market because everybody's going to throw away all their old tools and stop their subscriptions to their old SaaS development stuff. And the pressure is so tremendous to spend tokens and token max and to get people, right? For the next, I think we still have probably six months left in the measure of success for most companies is whether they're consuming AI and showing AI adoption, right? And if we want, we'll come back to five or six historical examples where this didn't work out either. But I think we're at the moment where the price of a token is as high as it will ever be in history, okay? Token prices are going to fall. Free models are going to proliferate. People are going to figure out how to work around the fact that they're spending 10 million pounds a year on tokens. I'm not sure what they're getting, right? So I'm expecting this huge deflation in the actual revenue stream of companies that ship AI tokens and tools. And it's what happened when we got to browsers and what happened when we got to mobile. There are all these tools vendors and you never hear about anymore because 12 months later, it turned out the tools weren't the answer, right? But right now, if you're making money pricing tokens, it's a good moment, right? But that can't last. Law of gravity is going to apply itself. And everybody else is going to have to start asking the question of, was I able to generate more revenue or maybe fire a lot of people and have it not hurt, which I also don't particularly believe, right? I either have to make a lot more revenues in the AI tools to build product, not just build more code, or I have to dramatically reduce my headcount to pay for the new AI tools. And I think both of those are still unproven for the most part in most markets. And they both may end up not being as true as the white papers from the AI vendors would tell us is true. And they obviously all have their own kind of motivations for doing that as well. But I recently did a straw poll of some product leaders in some of the communities I'm in trying to find you basically, you know, trying to get some background info before this to see like what's actually going on. It's easy for me as a consultant, as a coach, as you as a coach, I go out and sort of speak to the types of people that come to us. And maybe there's a whole different world out there. But I thought I'd sort of cast a bit of a wider net, trying to see what was going on out there. And, and it seemed like exactly to your point that a lot of teams or organizations out there with teams, they're not really 10x in the products, but they're almost trying to one 10th X their teams. And sort of exactly as you say, kind of build the same amount of stuff that they were already going to build, but just do it with fewer people. Sure. Now, from an OPEX perspective, I can sit there and say, well, that sounds fantastic. You know, I've reduced my cost base. And that's brilliant. But is that really the kind of inspirational future that we've been promised by these AI companies that somehow we're just gonna have fewer people making the same stuff? Like, shouldn't we be thinking bigger than that anyway? Well, maybe. I mean, every company gets to choose what they think is important, right? But if I look at the history of software development over the last, say, 50 or 60 years, every year, there's been more software engineers and more product managers and more designers needed because there's more things to do, right? And, and I don't think you can cost cut your way into market success and profitability as a software company. Now, if you're a bank and you honestly don't care about any of your depositors or customers or credit card holders, which most banks don't, and you're gonna build the same mediocre to crappy systems faster and cheaper with AI, I think the banks are gonna wanna have fewer employees who are humans, right? And they're gonna... But that's a pretty short-term small win and it doesn't grow revenue over time, right? There was a, if I can take a side trip here, there was a great piece that I got from Stefan Wolpers. A lot of us follow him today. And his thought was that Agile transformations and AI transformations rhyme, right? They're not the same, but all of the things that we went through 20 and 30 years ago, where we brought in consultants who trained everybody on Agile for two days, and we counted the numbers of retrospectives and we... Oh, story points, right? We decided the story points were the thing that engineers had to do more of. And so of course, what the smart engineers did was they wrote more tickets with smaller stories so we could have more story points, right? And he went through like five of the lessons we learned in the Agile transformation, which were the individual tool was never where the wind came from. It was always in the larger organizational reworking of how work gets done and where the bottlenecks are and how we envision what we're doing and sort of redefine our jobs, right? And for those of us who've been in the game for four or five decades, this just has a lot of resonance in throwing tools and throwing money against adoption of things instead of clearly doing the work to figure out where the wins are. Now, I think there's a lot of wins to be had here. It's not that the AI tools aren't good. It's that when the CEO tells everybody, we're going to fire you if you don't use your AI tools for eight hours a week, right? That's not an effective way to figure out where we're going to get leverage. Yeah. No, it's definitely interesting that kind of push to almost use AI even if you don't want to, or even if there's a better way, or kind of cram AI features into your product because you've got to have a chatbot and an agent and an MCP server and everything else because if you don't have that, you're not cool. But another thing you called out and something I've seen elsewhere is this idea that we don't really need to do proper product discovery anymore. And I know that when you and I have spoken before, previous episodes of the podcast, it's always been about like, well, yeah, but there's just been this idea of, you know, from your perspective, I remember from our first podcast chat, it was like, your first thing you do when you go in to see a new product team is find out when it was that they last spoke to a customer and whether they were happy with that. And if it was too long ago, then why have they not changed that or whatever? But then there's this kind of counter narrative aside from things like synthetic users, which obviously is a whole different ballgame. But this idea that actually, now that we've got agentic software development, we can just sort of set up a bunch of agents to scan all of our feedback channel. agents to scan all of our feedback channels and Slack and sales calls, still automatically build everything, push it out to customers or to users. They'll just sort of see it and use it. And maybe they'll like it and maybe they won't. And if they don't, they'll stop using it and maybe we'll turn it off. And it kind of feels like there's this kind of Frankenstein product possibility out there where people are just getting pushed stuff. And it kind of makes me wonder whether that's actually what users really want, like to just be kind of experimented on all the time, rather I think, I think you hit on probably three fundamentally wrong conceptual things there, right? Not that they were, they were your mistakes, but if we follow the chain of logic and we ask how things work in the world, instead of how our software developers imagine that they work, right. Or our CEOs, here's where we're going to trip up and let me give you sort of three, three real challenges. The first one is let's imagine that you're a current user of our product. Okay. And you're actually using it to get some stuff done. You're not spending all day waiting to find out what we've thought of. Right. And we used to ship you two new features a month and 25 bug fixes and a couple of minor UX things that we didn't tell you about because they were obvious. Right. Um, and that was okay because at two new features a month, you could actually find out about them. We'd send you a newsletter. We'd send you a change list. We'd send you the, uh, nobody ever reads, uh, release notes, but we'd send them to you anyway. Right. And, and at two features a month, you might take 10 minutes to read up on those two features and see if you wanted to try one, right? So now let's, let's 50 X it. Cause our engineers are really much better than 10 X. Okay. So they've got a subscription. That's right. So we're gonna, we're gonna build and ship and bolt and bundle in and send you 100 new features a month. Okay. And you're, you're not even going to discover that 98 of those even existed. Right. You're not going to look at the change log and you're not going to look at the release notes and marketing can't get your attention around a hundred features because you're actually trying to do your job right. Or whatever you hired our software to do. So you're only going to try out three or four of those and you're going to give them much less attention because there's three more right behind them. It's six, a hundred more right behind them. Right. So what we've done is we've moved the problem of thinking about what's good. From engineers and product managers, designers to users who are busy doing something else. Right. And so my expectation, if you're shipping a hundred new features a month is that 96 of them will get almost no use and almost no review and almost no feedback, regardless of whether they were good. Right. In fact, we're probably going to piss off our users enough that they stop paying attention. Right. Um, the user attention is, becomes the scarce resource in the world. And for us to expect it, every team is going to put 10 new things a week out. Right. And that our users are actually going to have enough time and attention and love for us that they're, they're going to choose what's good. I think it's fundamentally wrong. Right. It, it just doesn't work. Right. And then the second thing I think we're assuming here that's wrong is that most of the requests we get from most of our users and prospects are good things to do and make sense, right. And fit in the product. Right. And the answer is whenever you go look at all the tickets that we're getting, right, a good two thirds of them, either are bad ideas or make no sense or are illegal or are going to hurt the users or blow up the product. Right. Um, you know, we're going to end up with folks who are trashing all their data and bringing down their systems and adding, uh, 57 new reports to the dropdown that had six reports on it. Right. Um, fundamentally, I think doing everything our users ask for is a bad idea. Right. Now we used to be able to, to say no, simply by saying, we're going to put it on the backlog and never getting it there. And that was a polite way of saying F you. Right. But now we have the opportunity to take, to directly wire every incoming ticket and request to code generation. Right. And to take every incoming request as a good idea and push it right in the product today. And, and we're going to discover, we're going to be surprised to discover. I know that most of those are really, really terrible ideas, right. Or misunderstood or didn't solve the problem or break something in our system or undercut the fundamental reason people are using our stuff. And so we're going to once again, discover that we need to think and strategize and plan so that on the one hand, we can figure out which two features this week or this month, we really want to market and promote to our users because we think they're important enough that they're going to matter and which 650 requests we're going to turn down because they're going to trash all the value that we built. And we can automate that if we choose, but notice that's not a code generation problem. That's a product problem. Yeah. And one of the things you say as well is of course, these Frankenstein products that potentially come out of the back of this, they end up having to be supported forever as well, right? Because if you've got one person using or a little small group of people using one bit, a little bit, a small group of people using another bit, you end up with an incredible surface area that you have to maintain. And again, that's not just code, that's internal support, that's documentation that has to be kept up to date, trying to keep everything kind of maintained. Although again, what I hear over and over again is I hear the AI denial here. I say, well, we're going to automate support and we're going to automate the answering of all user requests and questions and we're going to automate updates, right? And so we don't need to have a support team anymore. Now I think half of that's true and half of that's not. I think a lot of support can in fact be automated, but ultimately people are going to have interesting questions about what it is or isn't supposed to do. Right. We old folks remember the distinction between, is it a bug or is it a feature? Right. Um, we're going to, we're going to be in that muddy gray space again, where one person decided it was a bug and another person decided it was a feature. And so alternate days we switch or maybe we give them each a different version. Yeah, no, I mean, obviously, big, deep side, but, but it's obviously again, it's easy if you just say that AI is going to fix all those things to kind of wave away all of those, let's say objections, because you just, exactly as you say, you can, we'll just put, we'll just fix that bit with AI and we'll fix that bit with AI and we'll fix that bit with AI. And it's, it's kind of the, you know, there were certain people out there that are being pushed to do all that stuff with AI. I guess there's also been stories. I think it was Flana who fired a bunch of people and replaced them with like support people and replace them all with AI and ended up having to hire them all back again because the job wasn't being done very well. Let's not be black and white about this. There's a, there's a spectrum here, right? So imagine that I have a thousand tickets in my backlog, right? Um, my agent and I can probably find 300 of those, which are truly bugs. On their face, they're bugs with one minute of inspection, they're bugs. And we should probably wire those directly in the system and fix all the obvious bugs, right? So let's reduce our backlog by a third with all the things that really, really, everybody agrees are bugs. However we get there, right? We have some, you know, agent that's evaluating them and we have some person doing a quick once over, right? Um, so there's going to be parts of this that really, really do get faster and easier. Okay. Once it's a small to medium sized feature, now we have to ask about the impact on the product, the impact on the customer and the legality and the, you know, a compliance and the economics, maybe giving away that feature means that nobody has to pay for our premium subscription anymore and we go out of business, right? So as the features get bigger, there's more risk, there's more judgment, right? The, the blast area is bigger. And when we get to a whole new product where we're going to have to name it and have campaigns and have marketing and sales go out and sell it, um, there better be an economic basis and there better be a customer base identified that doesn't already have it solved. And then when we're going to build a whole new company, right now we're at the far end, it would be great to know that 900 other solo product engineers didn't have the same idea and are launching the same thing this week in the face of a market that, um, doesn't need help. Well, this is another thing that you, that you wrote about was how easy products become features. You know, like anyone can have an idea. They can put it, you know, they can build a product around the idea. Then all of a sudden, you know, if they're unlucky, then one of the AI providers creates a, just puts that into their, a feature into their product instead, or you just kind of get completely outflanked by someone who looks at your idea and, and puts them, of course, that's always been a, a possibility. That's always been the case. And, and again, let's reach back, let's reach back for a couple of examples that I was alive enough to remember and that are gone now, right? So when browsers arrived in 1994 or five and Netscape was bigger than God, right? Um, there were a whole bunch of companies that, that created HTML authoring tools. So you could build websites, right? Now I predate that. So my first website I wrote with a, with a text editor and, and a hard coded HTML, you know, real men, right? But, um, but there was this whole crap of companies, this whole raft of companies that were building HTML and website construction tools, right? And for about two years, they were the talk of the town, right? Um, and the VCs were busy pumping money in, um, four years later, six years later, it turned out that the Microsoft folks added this tiny little feature to Microsoft word that said, save as HTML, right? Um, and, and, and 50 other equivalents of that, right? The, the ability to write HTML ceased to be a product and then it ceased to be a feature and it became, well, if, if your thing doesn't save as HTML, boy, are you stupid, right? Um, you know, e-commerce was a really big thing, but now if you're going to start an e-commerce company, you better sell something interesting. And if you're going to start an e-commerce software vendor, you got to figure out what you're doing that, that the Shopify's haven't been doing for 15 years, right? So, um, every marketplace becomes a product and every product becomes a feature and every feature becomes an also ran somewhere down in the mouse type on page five of the feature list, right? So, you know, we're going to discover once again, that, you know, uh, the standalone tool that lets you create MD files, right. Or, or actually I'm talking to some folks later today about, um, they've got a really good idea for an AI tool. It's going to generate an AI intrusion detection system that checks your AI code for AI generated intrusions. Right. Makes perfect sense. Right. Now, turns out that if you look at all of the major vendors of security software, they've all either announced or ship this because it wasn't a new idea. And every security engineer who's been excited about their AI tools is actually spinning up this, a very similar thing. So it's not enough to say that I can build a thing. Yep. And, and I don't expect my engineering team to have to learn that lesson because that's why we have product managers. But one of the things that we do find product managers, at least in some organizations, gravitating towards is trying to get kind of stuck in with the engineers themselves, right? So rather than doing some of the other stuff that we'll talk about in a minute, there's this idea of like, well, we've got all these cool tools. Now we can gravitate towards sort of doing some of this coding stuff ourselves. We can build up via Vibe code, our own stuff, either as a prototype or try and dump it into the product. I've seen teams out there that apparently have product managers going and working on bug fixes rather than escalating them to the engineering team, because apparently the product manager's time is worth less than the engineering team to work on all the small bugs. Is it, as far as you're concerned, almost like a bias towards, yeah, for product managers that maybe historically have been seen as a little bit kind of, like, what do they do? All of a sudden they've got this kind of power at their fingertips to look productive and actually produce something themselves that people can see. And it kind of drags people towards wanting to look like they're doing stuff versus maybe doing some of the fuzzy stuff around it. Let's put a more positive face on that. Okay. Cause we're not talking about silly people who aren't introspective and don't know what they're doing. Right. Um, first let's recognize the organizational reward systems where big companies are firing people who can't generate code or build prototypes with the latest AI tools. Right. So, and endlessly at conferences, you and I are meeting people who say, I'm a product manager and my management team, my C-suite has told me that the only product managers we're going to keep are the ones who can step into the AI tools. Right. Product builders. Product builders. Now, really, really smart, thoughtful folks faced with that choice, and who have maybe kids at home and want to send them to uni and write, um, and mortgages to pay will do the right thing and step in to be product builders, right. Whether it's a long-term answer or not, whether it's good for the company or not. Right. Um, one of the very few things I learned when I did my MBA many, many decades ago was that people do what you pay them to do, not what you want them to do or what's smart. Right. If we've created a reward system where we're firing all the product managers who don't, who don't use enough AI tokens to build prototypes, then smart product managers are going to do that, whether they enjoy it or not. Right. And the tools are seductive and they're fun. And it's, it's a lovely way to spend your day. Um, and it really does feel more productive. Yep. Right. I don't have to wait for my designers to build me a prototype. Right. Or a mock-up I can do that in six shakes of a donkey's tail or whatever you say in the UK. Right. Lamb's tail. Lamb's tail. Lamb's tail. Yeah. Now, whether that's good or not, we're going to see whether that's a good organizational strategy we're going to see, but I think product managers are running toward the things we're rewarding them to do. Um, now the ones who are reformed engineers are going to do that naturally. And the ones who are reformed marketers and product marketers may resist some, but when there's a leaderboard in front of the HR team that shows people how many tokens you consumed, let's, let's not blame product managers for doing the things that they're being whipped to do. Well, let's talk about the, one of the other concepts that you introduce. And of course, I'm never going to whip a product manager or blame a product manager who's being whipped. But there's this kind of fuzzy work that goes around it, that you talk about in your, uh, other article around, uh, barbell shaped product management, the kind of how you see the future of product management, you kind of described back in the old days, you had this kind of the fuzzy front end of strategy, discovery, prioritization. You had a middle, which was like the development product managers seem to spend a lot of time working on getting a development done. And then at the end, you had to kind of the go-to-market stuff as well. And you kind of do that as a circle, big, fat, middle, two fuzzy ends. Now you've moved to this kind of conceptual model of like a barbell shaped role, and I am going to have to call out the fact that in your article about this, you use the dumbbell, not a barbell, but apart from that. I use the word barbell because dumbbell is insulting to everyone, but there was somebody else who did a similar thing and used dumbbell, right? Yeah. And I've always wondered about the, the, the etymology of dumbbell, but anyway, whatever type of, of, of weight it is that you're using, you've kind of got this new model of, of, of, you know, effectively a, uh, a barbell with a big fat front and a big fat end and a, and a sort of a narrow middle. So what does barbell shaped product management look like to you? And, and how should product managers really be spending their time if they can in this new future? And I'm going to say should, because I don't know that we're there yet. Yeah. Right. Um, and again, working from first principles, if we believe, and I do that most of the things we ship are going to fail if we don't do the thoughtful work at the front, that's going to be important. And if we believe as I do that the things that we build have to be marketed and sold and brought to market, then that's going to be really important to do. Right. Um, so in, in, in the sort of previous model and, you know, I started in the industry two years before electricity was discovered, so we actually had to. Carve our PRDs into stone tablets and carry them over to engineering. Those are the days, right? But, but if we think of a circle or an oval in the classic model where the middle, let's say 60%, right, the middle two thirds was working with engineering on specs and working with engineering on roadmaps and schedules and, and trying to explain why things are going to be late and we couldn't have everything we wanted. Right. So if two thirds of the old work was either babysitting engineering or trying to help engineering where we weren't of any use, right, because engineers are usually telling us that they want less help, not more help. Um, and then the fuzzy front end, what do we get? 10 or 15% worth of time for discovery and user interviews and economics and market surveys and being out in the field and figuring out what's true. And lots of questions about problem versus solution. And in the back end, we had another 10 or 15%, which we sometimes gave to product marketing, which was how do we turn this thing that we built into money? And so we need demos and we need customer referrals and we'd skews and pricing models and, um, sales training and all the things that turn code into money. Right. So if we squeeze the middle and we say, okay, engineering doesn't need us 60% getting in their way and bothering them and sitting in scrum meetings, right. Or retrospectives, we're going to shrink that down to 20% from 60%, right. It won't be zero. And we'll sit with them and we'll love them. We'll give them direction, but 20% that leaves the 80% for what is really value add, right? And so I'm going to put 40% up front and say, we're going to spend 40% of our time talking to users and understanding the world and the scoping out the competition and running the numbers and telling money stories and making sure that we do a legal check on the name we're going to use for our products. Cause Lego is owned by somebody else. Right. And, um, and all the things that are going to go into, is it a product? Not just as a code, right. And then we're gonna spend the other 40% on the backend, trying to turn it into money. So more calls with customers, more sales calls, more sitting in with marketing, more drafting white papers, more, you know, what are the phrases that need to be on our automated robotic phone calls? Right. Um, now maybe we don't need as many product managers as we did before. I can't tell. Right. But I know that we're going to spend a whole lot less time on engineering and that's going to force us. engineering, and that's going to force us to spend a whole lot more time on the front end for what should we build, and a whole lot more time on the back end for how do we turn it to money. So, so the barbell is simply taking the circle or the oval where we used to spend the time with engineering, shrinking it down and pushing it to the outside. Right. And again, that's the exact opposite of the product builder, unitary product engineer model, forward deployed engineer, who does it all because the folks who are going to do a really good job at building code are mostly not good at the two things I just described. Now they're out there. There's some unicorns go hire them, right? Pay them a lot of money. But on average, we don't train our engineers to do those edge things. And we don't train our product managers and product marketers and designers to be the people responsible for great production code. So it makes good headcount sense to say that we're going to lump everybody under some one title and save two thirds of our staff, just in the previous iterations where I've seen this, it ends really badly and nobody's willing to stand up and admit what we did. Well, there's an interesting additional wrinkle to that though, because arguably that first model that you call out where like they were spending 65% of their time in that middle, they probably should have been spending more time on the edges already. But of course this new paradigm potentially gives them an opportunity to move towards the edges. Because if we think about some of the dysfunctions that you and I have both spoken about, you know, PMs being handed up high HIPPO decisions, sales and marketing teams taking full ownership and not getting the product team involved in any of that kind of edge stuff at all, it kind of feels like a lot of PMs and product leaders get kind of pushed or forced towards the middle because that's the place where almost like the company wants them in the first place. Like maybe that's what the CEO or the leadership team even thinks product management is. So there's this kind of inwards pressure, or there has been in the past, is inwards pressure pushing PMs into that middle. And now of course we're saying that, you know, they don't need to be there as much because of all the things that you've just said, and they should maybe start to expand their horizons again, but that pressure from the outside could still remain. So is there a way that you've found to kind of advocate for product managers, product teams to spend more time there and kind of maybe push out against the inward pressure that might be coming from those commercial and leadership teams? Yeah. So I think this is a really hard problem with no easy solutions. By the way, um, one of the easiest... No framework or infographic on LinkedIn for us, no? That's right. One of the easiest solutions I reject because I've never found it to work is to have a book about a perfect product operating model and to give everybody who's on the go-to-market exec team, a copy of the book and tell them that this is how we're going to do our job. I've just never found that to work. Right. Um, uh, in fact, uh, let, let's take the counter because again, you know, I mostly coach VPs of products and CPOs. And at the beginning of this year, I had eight folks. I was coaching, I'm sorry, nine folks. I was coaching three of them have lost their jobs in the last quarter. Right. And I think, I think it's a direct result of, uh, very, very high expectations from the executive team that wants it to be true that we can 10 X engineering and that we can 10 X the throughput of product managers, and that that's going to lead to 10 X the revenue right now, I don't actually believe that's, what's going to happen, but the white papers and the assumptions. And McKinsey's got some slide deck here that tells you, you can let go two thirds of your folks. Right. Um, and you know, um, a bunch of big companies have taken the ax to engineering and product and design, and they're being rewarded in the market for it in the stock market. Not in the right now, not in the product market. And so I think it's a very, very tough time to be the head of product and to go to your executive team and say, you guys are wrong, right? We can't do this with a, you know, half, half the staff. Um, and it's going to have bad results. Um, because the, the reward for standing up and saying that is that you, um, you get to dust off your CV and get in the job market right now, the reward for telling the executive team exactly what they want to hear. Is that you're two or three quarters away from losing your job because you can't actually deliver those things. So, you know, we are, we are in a moment where it's really very difficult to be a leader of engineering or product or design, because the meme out there is that we can do a lot more with a lot fewer people, I think there's very, very little evidence beyond code generation. I think there's very little evidence that we can create a lot of great products with fewer product managers and great designs with fewer design leaders and great engineering work with a lot fewer great engineers. But right now the market is telling our leadership and their boards are telling them that they need to cut staff. Because look at this list of all these other companies that say they're AI first and cut staff. Right. You know, their names. I don't need to reel them out. I think, you know, it's that's where we are right now. So I don't have any magic answer where I can tell a chief product officer to stand up in front of their executive team and raise one or two middle fingers and say, you guys are being misinformed and lied to, and that those shiny press releases don't represent truth. Well, there's an interesting point there. Like, yeah, okay, fine. We all know there's no easy answer. Obviously you can't give them a book. We all know that. I'll just slip a quick sort of side channel myself here of like the time that I turned up at a client office, they were trying to go through this whole product transformation and they'd bought a copy of some very well-known product books and kind of dispersed them around the office and I was sitting waiting for someone to turn up at their desk and I looked in front of me and there was a monitor exactly my eye height, which was at that height simply because two of those books have been placed under the monitor as a stand. Like that's kind of the, the almost like the inevitable fate of any of those books that get given to non-product people in any organization, but these people have to say something or do something. Now, obviously you said earlier, you pay someone to do something, you give them that leaderboard. They're going to go and probably do some of those things and try and make the best of it. Is that really the, like you coach a lot of people, I coach people. Is that really the strategy for now? No, it's not. Try and get through it or are there some things they can do of any ages? So, so I come back to my first principles and again, I've been spending the last five or eight or 10 years talking in various formats about money stories. Right. And the useful note here is that money isn't the same as code. And I know I've said it about 11 times and it's already since we're on here, but money's not the same as code. And so I think the responsible and useful thing to do is to look across the table as you know, and by the way, I'm always advocating that the head of engineering and the head of product need to be shoulder to shoulder and aligned on every issue when we're in public, right? We never fight in public and we never disagree in public. And for the head of engineering, the head of product to say, we can build more things faster, let's look across the table to sales and marketing and let's ask sales and marketing to make a commitment that they're going to sell more of the things we build and turn more of it into money and let's talk about increasing our quotas and increasing our hit rates on lead gen and growing our target markets. Um, because that's how it turns into money. Right. And, and I observe that the really smart folks across the island sales and marketing who are smart, right. Um, they've traditionally used as an excuse why they didn't hit their numbers, that engineering was late. Okay. We're taking that off the table, right? We can no longer blame engineering for being underproductive. So the next set of discussions is going to be that the products weren't the ones we wanted or the markets weren't ready or that they didn't adopt. Right. And so we're going to get to the next real part of the conversation by saying, um, we're, we're going to add five more new products to the roadmap next quarter. We now need marketing to come up with five new marketing plans for the five new products. And we need sales to commit to sales targets, quotas that they're going to get paid on or get fired for, for the five new products. Right. Um, or maybe we don't need to build them. So we can't hide behind our backlogs anymore. We can't hide behind engineering is going to be late anymore, even though they're always going to be true. Right. Um, and so, so this turns the tables a little bit from, you know, who's at fault to, we need a plan to actually grow our market, not to make the company hire EBITDA by cutting staff. And, you know, if sales will sign up to make a lot more money when we deliver these products and marketing will deliver a lot more leads, I believe them because that's their job. And if they won't sign up for higher quotas and more leads and more, you know, and more prospects, then let's have a real conversation. Um, we, we as product folks have been too quiet, too polite, too much hiding behind engineering to disengage from the business, too unwilling to stand up and say, either this is a five to $10 million product as agreed to by sales and marketing and the CEO, or let's not build it. Yeah. I think that thing about being disconnected from, you know, the rest of the business from the commercial outcomes has been something that I've seen across so many companies. I know you have too. And every CEO picks at product management and says, we're not involved enough. And we don't know the customers enough. Now true. Sometimes not true. Sometimes it's an easy out. So don't give them the out, I guess, is the obvious. You give them the easy out, they're going to take it. And the next quarter when there's no revenue, it's going to be my fault and I lose my job. Yeah. And no one wants that. It's a, it's a tough market out there anyway. That's right. But, but playing devil's advocate just for a second, because you know, why not? We can fight against our own arguments as well. Some people out there, as we kind of touched earlier, they're, they're already saying this is the future. Obviously many of those work for companies that rely on this being the future for those companies to be successful, you know, there are people out there talking about how their 10 X and everything with agentic coding. They've installed their second brains and their personal operating systems. They've automated everything they're shipping millions of lines of code. And there's people like you and me sitting there saying, well, hang on a minute, it's a bit more complicated than that, but also we kind of have an interest in it being more complicated than that, because, you know, we, we might get to help people decomplicate it if, uh, if they come and ask for help. So I guess the ultimate question is, you know, if we think about all these things that, that, you know, we're saying are more complicated than maybe some of the other people are saying, is it just that we're kind of fuddy duddy Luddites that just need to get with the program and we're just not big picture enough, or is there any kind of way to almost have a, not an argument, but maybe more of a constructive debate with someone who's so completely AI-pilled that anything that you say to them, like what we've talked about today just sounds like, oh, you just don't get it. Well, let me give you three yes answers. Okay. One. Yes, I'm an old fuddy duddy and I've been here too long and I'm a naysayer and, you know, I didn't take any of the pills. Okay. I'll, I'll sign up for that right away. You know, um, back in the day when whatever story you want to tell. Right. So, so I think that's one I'll give you the second one though. I will say, um, I believe this is true. Okay. Um, and I, and again, from first principles, I can't make the numbers work, but, but people don't want to look at the numbers. The third one is, and there's an, there's an intermediate argument here that says, well, Rich, you're just giving us the engineering faster job argument. And so you've moved the bottleneck to product and maybe we'll make product faster, so we'll move the bottleneck to marketing. Well, can't we make marketing faster? Right. And can't we make sales faster? And can't we make finance faster? Can't we run a company with 40% fewer people? Because we've outsourced a lot of the work to AI. And I think that may be very possible. I don't think that's good for the world economy. Right. Cause there's a lot more people out of work and I think it's hard. So again, if we go back to lessons of previous transformations, um, how long is it going to take for us to completely rethink and retool the sales motion of a company that sells to businesses, right? Especially when the businesses aren't yet using AI tools to choose their products. Right. So if you're in a business where people buy because you have a sales team. Okay. Um, uh, we're going to discover in marketing that you can build the campaigns really fast, but there isn't more buyers out there and good campaigns still work better than bad campaigns. And so the senior marketing folks with taste and experience and insight actually supervise agents who build way better campaigns than generically. Right. Um, and again, if we come back to the buyers, um, how many newsletters are you getting every day? How many things from Substack? How many Lenny's, how many invites to events, right? Um, you can't read them all anymore. Right. And so just imagine a world where every company has automated its outreach. Right. So I don't like it. I already don't like it. So, so I, I think the answer is in the middle here. The answer is always in the middle, which is we're going to find some improvements and we're going to find some optimizations and we're going to use the tools. Um, they're not going to change the world. I believe they're not going to change the world. Browsers didn't change the world. Mobile phones didn't change the world, although everybody has one in their hand now and, and now we have addiction problems, right? But that took 30 years, right? Um, the tech world wants the world to adopt things faster than the world adopts things. And I see the hiring and firing cycle based on tech's view of the adoption. Curve, not the world's view of the adoption curve. We're going to discover that we've moved too fast and that some of this is harder than it needs to be, but some of it won't be well, hopefully some people will actually, I had one more yes for you, which is, um, so you, you and I have talked about it, but not everybody knows I am, I'm only working one third time these days, having moved to Portugal and dialed back my calendar. So I actually don't make more money regardless of how this goes, right? In fact, I'm hoping to be completely retired by the time this plays out. So I have no special economic incentive to tell one story or another or to make it shiny or make it ugly. But it's a, it's an interesting point though, because you sit there and you say, and it's obvious to say, if you think about it, but you sit there and you think, well, someone, for example, we talked about them earlier, someone who runs an AI company, like that's the thing that they do, or they run AI courses or they run AI workshops or AI transformation programs, whatever. They have a vested interest in AI working and being needed and wanted, et cetera, because that's how they make their money. And, and it's what they see every day. It's what they're faced with. It's what they live. So they're in a bubble as well. But then at the same time, and, you know, whilst I would hesitate to compare myself to the work that you do, I think that whole thing around being a solo consultant and actually being able to go and tell the truth and the good and the bad things and the things that will work and won't work based on your experience, rather than everything having to have like AI as a solution, for example, feels like an incredibly powerful and freeing way to go into someone. Cause you can go in there and exactly as you said earlier, you can sit there and you can say, look, this stuff's going to work, do that right now. This stuff, maybe don't do that. Maybe try and do a different thing and try and make the best out of it, rather than like starting with AI and do the things that are going to work well now. And let's wait six or 12 months and let somebody else bloody their noses. On right now, there's always the first mover advantage. You know, everybody's going to get there first. Somebody's going to steal my market share. And that might be true, but I'm always true. Well, it was always true, but in some markets that will be more true. And I think in most markets it'll be less true, but someone has to actually make a determination that says our business is going away. When I look at the European car market, which is being increasingly dominated by Chinese, all electric cars, because the European car manufacturers were late to the party, that's real. And, and you can't wave your hand and say, Oh, you know, that's not real, but markets vary and situations vary. And before you take the AI pill, it's really worth thinking about whether your market's going to go that way. Well, absolutely. Plenty to think about there and lots of pros and cons to work through in our heads and, you know, futures to imagine. But if people want to come and find you after this, imagine those futures with you or check out your books, find out about money stories, or argue with you about how many X's they can get out of their AI token bill, where can they come and find you? Cleverly. My name is my email address. My last name is my domain. It's also how to find me on Substack. And LinkedIn. I mean, there aren't, there's nobody else with my name. And I'd say that anybody who's in one of those leadership product jobs and needs 45 minutes of free coaching, who needs to be propped up a little bit or, you know, supported, drop me a line, right? I've got time. If somebody can't find me there, ask Claude. Well, we'll get together and create some kind of skill after this that people can install into Claude Code that will dial, maybe dial up a rich hologram or something as well. Like we, we probably have the technology to work on that. Take all my sound bites and deliver a workshop. Richbot. There you go. We just need to make Richbot. But before we do that, I'll make sure to link everything into the show notes and put all your different details and links and places in, and they won't have any excuse not to find you Rich. So hopefully some people will. Perfect. But anyway, always a pleasure. Never a chore to chat Rich. Obviously it's always good to kind of hear what you're seeing out there and, you know, kind of compare and contrast what we're seeing out in the market. Obviously we'll stay in touch, but yeah, as for now, thanks for coming on. Thanks so much. And I look forward to seeing you in person again soon.