Fireside Chat with Marty Cagan and Martin Eriksson (ProductTank London)

Welcome, everybody. You ready to get started? Okay. Welcome, everyone, to Product Tank London. This is the last event that we have for 2025, and we've got something special lined up for all of you. And just before we get started, by way of hands, who here, this is your first Product Tank? All right, love it. Love always seeing some new faces. And then I assume the rest of you, you've been to a Product Tank before by show of hands. No? Okay. All right. Wonderful. Well, thank you all so much for joining us. For those of you who maybe don't know what Product Tank is, let me grab my clicker because, you know, that's part of my job. Product Tank is a meetup for product people, by product people. And Product Tank's been going on for 15 years. And it started actually here in London at a pub some time ago by someone who's joining us tonight. And so no matter where you are in the world, for those joining us online or maybe those who have traveled here, there's probably a product tank chapter near you because there's over 200 around the world. Now, notice that this says product people. It does not say product managers. So we welcome people who love building products, who love the craft, wherever you might be on that journey. So we're really excited to have you all with us tonight. But since we're a community, right, we really thrive on the support of our members. of our sponsors, our hosts, and our guests and speakers, but also from the organizers themselves. So if you don't know us, here we are. So this is the organizer group that we have here in London. It includes Amanda, who's a PM at checkout.com, Kunal, who's a PM at Visa. They were helping bring people inside. We've also got Sarge here, who's a senior PM from Sokin here in London. And I'm your host tonight. My name is James Ganaka. I'm a... founder of product sphere and a pm career coach that's a little bit about us but we're all volunteers we all do this for our love of the craft and our love of supporting the community because we all have diverse product experiences come from different parts of the world we've worked on different things but what we do have in common is we love helping other people grow and learn in the space of product so that's us if you want to get involved in the community there's many ways you can do that you can speak at a product tank event We host at least 10 a year here in London. That's a QR code you can scan if you want to contact us about speaking. You can also host or sponsor a Product Tank event. We wouldn't be able to put these on without the support of our sponsors. We've already got some exciting things lined up for 2026 as well. You can also write for mindtheproduct.com. You've got interesting experiences or stories that you want to share and give back to the community. Or you can become a member of the Mind the Product community. right join a global network of people there's a great big slack channel there's other things that you can get in terms of content from mind the product so that's us tonight's agenda i'm going to spend a few more minutes just kind of welcoming you all and welcoming our host and then we're going to get into our fireside chat with our special guest tonight we'll do that for about 45 minutes we'll break for a bit so you have a chance to either eat some more pizza have some more drinks but then we're going to come back and we're going to do an audience q a So as we're going through tonight's fireside chat, if you have some questions, I'll give a code in a bit in terms of how to submit those. Then we'll close, have some more drinks, connect with some other people, and then we'll get on with the rest of our evenings. So as you may be taking photos or maybe you want to share a summary of what you've learned tonight, please do follow us on LinkedIn, tag us, tag our speakers, right? Make sure that you can share the insights with the broader community so we can again... Increase our impact that we have on the broader product community Now with that I'd like to welcome our sponsor and the CPO of train line Nina to come say a few words Please give a round of applause Welcome, everyone. We are so excited to have you here tonight. There's over 200 people here and listening online. We're really excited to welcome Marty and Martin, our special guests for the evening. I think I can probably speak for the room in saying that they've influenced how many of us think about product, how we build product organizations, and super excited for the conversation. So I'm Nina. I'm the chief product officer at Trainline. I've been here about five months. The rest of my product career was... spent largely at Hotels.com and Deliveroo. And if you don't know Trainline or if you just know our app, we are the leading rail and coach platform in Europe. And probably what's a little bit less well-known is how much product and technology sits at the heart of our mission. So our mission is to make rail travel seamless, easy, enable people to make greener choices. And product and technology really are at that heart of the mission. We are a truly product-led company. And so we, you know, we're really excited. We're hiring for some roles. Quick plug, check our career site and folks who have a train line lanyard are happy to talk to you about it. You may have seen in Marty's book, Transformed, he talks about train line as, you know, a kind of company and a very, you know, sort of. outdated, sleepy industry that are innovating and evolving and really changing the way that we build product in terms of driving for customer outcomes and building empowered product teams. So we're working on that every day and we're excited about that. But thank you really for all of you for being here. Thank you to Product Tank for partnering with us on hosting this event. We really love connecting the community and hope to do more events like this in the future. So without further ado, I will hand back to James to welcome our special guest this evening. Thank you so much. I can speak personally to having a delightful customer experience as both a personal and business traveler, thanks to TrainLine. But also, again, just want to thank you for having us. Okay, so I mentioned earlier that we're going to be taking some audience questions at the end. Because there's such a large group here and we've got folks online, best way to do that is to stay in this code and enter your questions into Slido. So whatever the topics that we cover tonight are things that we might have questions about. But make sure that you thumbs up or upvote things that you want to you know be asked because We probably won't be able to get to all of the questions And the time that we have so that is how you will do that and that just leads me to introduce our speakers So I'd like to welcome Marty Kagan from Silicon Valley product group and Martin Erickson the founder of product tank and executive chairman of mind the product. Thank you Thank you See how long it takes me to kick over my can of coke, but How you doing Marty? I'm good Thank you everybody for coming. We just established that Martin's official name is Martin. So today you have Martin squared up here. Yes. The Martin and Martin show. We'll try to confuse you as much as possible with which one's which. Where should we start? Wherever you like. What do you think? Well, I mean, I think the headline conversation was what is the future of product management? And I think a lot of that is obviously being brought about by AI today. So you obviously get to travel and talk to a lot of product leaders, product companies, both. struggling ones and successful ones. What are you seeing out there for the role of product? Yeah, I think it's more uncertainty and more of a wild time than anything I've seen, which is a long time. Internet was by far the biggest disruption I had seen and lived through and experienced, but this one has overshadowed that for sure. And I think one of the hardest things is... None of us know just how smart these models are going to get. Even the people working on the models don't know. So it makes it really hard to know where things are going to land in any time frame. We all have ideas. There's some very optimistic people out there, and there's some less optimistic people out there. But there are some things that are settling in, I think, at least for the sort of foreseeable future. And one of the things that was in question, I'd say one to two years ago, was like, what is the role of product management? But now that seems to be a lot less of an issue. Now it's become a lot more clear what is necessary for successful products, especially successful AI products. And of course, I run into this problem all the time. Most of the products the companies I'm working with are still conventional products. So that's a different discussion, because then it's about how is AI used to help you build those conventional products. And that's a lot easier discussion. And even that, though, is a moving target, especially for developers. Look at that. But the other topic is how does it change when you're building smart probabilistic products. And that's where it's become increasingly clear that product managers of a certain kind, the kind I've been talking a lot about, are really in demand because those are really hard kinds of products. I don't know how many of you may have had a chance to start working on those kinds of products before, but they're not easy. And the whole ideas we talk about around discovery and delivery is the starting point. So they're not really optional like they are in conventional products. So lots to talk about. I was listening to a podcast this week where I think you shared that you actually worked on an AI product in like the 80s. In the 80s. How ridiculous is that? Yeah. I actually shared, too, the very first article I ever published was talking about that effort. It was called the HP AI Workstation. We thought AI, I mean, there's been several almost AI periods in the last 50 years. And this was literally from the 80s. And believe it or not, I graduated with a degree in computer science with a specialization in AI, which is so ridiculous because we had no, we were so far from AI. But we thought maybe it can't be that hard. It was. So anyway. Yeah, I did do a product, and the problem was it was $100,000 and nobody would buy it because there was no market for this stuff. And it was not smart in any real form. They had these things called expert systems, which were basically just rule-based systems, which were not scalable. It was an interesting thing for universities, but a terrible product. But that's actually what motivated me to learn how a product really works. Because on that product, I was playing an engineering role. And I realized it was a terrible time. It wasn't ready for a product. So you talked about, I think, I mean, there's the two categories, right? So I guess I'm curious in the room, like, how many people have actually started using AI in anger, I suppose, in your work, right, as a tool to be a better product person, right? Or to do your work faster, better, right? You said in anger? In production, I suppose. OK. And then how many are actually building products with AI? So probabilistic versus deterministic. About half the room. So yeah, I think it looked like 95% I think are trying the tools and maybe half the room are actually trying to build products. So I think that's the major distinction I'm seeing as well, right, in organizations as you go into that. Like I think table stakes is definitely thinking about the tooling, the process, how can you automate parts that you don't want to do. But then I think the bigger question is how do you actually rethink your product strategy given? what AI is capable of, right? To your point, the capabilities moved on so much, right? They have. So most companies I know are revisiting their product vision first because the things you can do are so much more. And then, of course, once you revisit your product vision, you've got to revisit your product strategy. You've got to revisit your teams, your skills. So there's a lot that follow that. Yeah. But one of the things that's interesting is when we talk about using AI tools to build products, we are seeing already speeds go up, not as much as the marketing people will have you believe. But honestly, 20% is a lot. I've worked on software tools for my whole career. 20% is more than we've ever got. So that's meaningful to me. But it's not like 10x or anything like some people will say. think in the future we could get to something like that but just realistically we're just not there now and but that doesn't mean it's not meaningful changes But when we talk about building AI products, what the community doesn't talk about that much is just how hard they are and how much work they take and how much they cost, which some people talk about. Everybody figures out. But also just how hard they are to discover and deliver and train. So those kinds of products are actually, I'd say, on average, take longer than conventional products for us to build. Roadmaps moving faster? Not really. Not really. Some things take a little longer, some things to a little faster, but not really. I think the interesting thing is what we can do. Yeah. Yeah. I think for me, it's just calling up the same kind of conversation we've been having for the last, I don't know, five, ten years, right, which is product has to be all about impact because even if we're... It doesn't matter if we're going 20% faster or 100% faster. We're never going to have enough resources to do everything we want to do. So we still have to be focused on actually delivering customer value, business value, as quickly as possible. There's some fascinating research that came out of MIT last couple of weeks, looking at AI investment, showing that 95% of the investment they see was considered a failure and did not deliver any business value. In the organizations you're talking to, what do you think makes the difference between people who are doing it well and actually embracing AI, whether it's the tooling or building a probabilistic product? Yeah, and that was like the most pessimistic study I saw. There's also some that are much more. But realistically, these companies are in learning phase. They're figuring out how this stuff works. And there is a cost to that for sure. And I think that kind of all got washed in. So I think that's normal and I'm not too worried about that. It is true. We're in this hype cycle where every single company I know feels like they have to have AI next to their somewhere on their website. And so they're all doing something. Most of it is meaningless, just like everything else. You get these hype cycles. And I understand. It's like, can you be the one company in your category that doesn't claim this? Nobody wants to be that company. So everybody is doing it. And I get these, yeah, we're having to do the sort of token effort to show that we're doing it. But it doesn't actually mean it's meaningful yet. Some companies are doing meaningful things. And I love that. And I think the truth is, just like with any new, this happened with the internet. It happened with mobile. It happens all the time. When you feel like you have to do this everybody just gets to this point pretty quickly with it Do you know any company that says we don't do mobile that makes sense? Of course they do so But once you do that then it becomes more interesting and it's now like all right What are you really doing on mobile and is it something that's meaningful? And I think then we'll start to see companies differentiate. Yeah I mean, I think the mobile analogy is actually very good, even though I think this is a bigger impact event than mobile. But I think the way we approached it was very much like, oh, okay, well, everyone needs an app, right? And we all had that pressure of like, well, everyone has to build an app. Even when it was ridiculous, right? No, you don't need an app. And then we moved into mobile first. And then we moved into, you know, having mobile product managers and all of these things. And now it's just, you know, table stakes, right? It's just part of what we do. So I think that same curve is probably what we're going to see in product, right? Where, you know, AI product manager. Does not make sense as a title, but we are seeing that in the market today because there's that reaction to we want people who have that experience. Yeah. Maybe you were leading here too, but one of the really profound changes I see as a consequence, this is not about building AI products as much as using AI, is now the people that would come to a meetup like this is a much... It's casting a much wider net. So product creators of all types. We've all known sort of very product-inclined engineers. We've known product people that love to code. We know designers that are good at all of this stuff. And we know people that are just very creative and love to build things. And those people are all now able to be product creators. And so I think that's actually a really... good thing. We've got a lot more interested talent. What it is doing is shining a light on the heart of the job, which is creation, building. It's like really creating products. I don't know how much you're talking about this in London, but in Silicon Valley, basically, if you go apply for a product manager job at a good company now, it's not the old interview. Tell me your favorite prototyping tool. Here's the problem, prototype solution. It's a pretty different interview. But it's actually the interview that a lot of these companies have wanted to do for a long time. And some companies even did. But now it's like, yeah, it doesn't matter that you don't know how to program. You don't need to know how to program. So that's a reflection of a realization of a very different role compared to what You know, a lot of people like a product owner role or something. It's very different than that. It shows just how much the gravity is pulling towards creators there. And I do think that's a great thing. So I think there's a couple of threads there. I think one is that product creators are getting more interested in this and getting interested in the core product because we're seeing a world where suddenly if we can build everything. then it really matters making sure that we're building the right thing, right? Exactly. And I think that's why you're seeing those people come through to that audience and come have that conversation and have that same aha moment you had in building that HP product, right, of like, well, we built this amazing product, but nobody wanted it. So I think we're going to see a lot of that with Vibe Coding, you know, whether it's prototype tools or using cloud code, something everyone can build, you still have to make sure you're building the right thing in the first place. And I do think that the calculus is changing in a good way. Now, there's consequences of this because a lot of people that might have a job today might not have it tomorrow, from what I'm saying. But in terms of product development, we've kind of always had three things we work on, right? You have to figure out what to work on, strategy. You have to figure out a solution. That's discovery. And then you have to build the thing. It's delivery. And building the thing took like... 80 to 90 percent of your resources that's not going away tomorrow i believe some people do believe it's going away really quick but i do not see it there's so much that needs to be done for delivery but i do see the directional and it is getting better so that 80 to 90 percent of resources is probably going over the next several years to shrink to something You know, I don't know exactly where it's going to land in some time frame. It depends again on how smart these models get. But the tools for professional developers are outrageously better today than they were even one year ago. So if you spend time with Cloud Code and Cursor and see, in particular, watch a talented engineer using those tools. very impressive. So you can imagine the cost of the whole delivery side moving over time from being the big constrained resource to not being the big constrained resource, which means, like you said, it's now that, okay, strategy, are you picking the right things to build? And discovery, are you coming up with a solution that's dramatically better your competition? That is, from the product perspective, that's always been the hardest problem. But now we can look at it and say from the company's perspective, that's now the hardest problem. What impact are you seeing that have on product teams? I think you were talking earlier about ratios changing and things, right? Yeah. I mean, I think there's near-term effects and longer-term sort of second-order effects that are trickier and potentially more interesting. But certainly, one is that now... It's not like product managers need to get their designer to go to Figma and create a prototype. Now any of us can create prototypes and work on them together and each change different parts. And I am actually very bullish on Figma's future here because they realize this and they're in a very good position to allow more than designers to use Figma to create these things. So I think that's near term. And so the lines we talk so much about. This is what a product manager does. This is what a designer does. This is what an engineer does in discovery. Now it's like we're all doing that discovery, but we're bringing different lens. So that's when I said that there's increased appreciation for product managers because they know they need somebody that brings this lens of how the business works. How do you sell? How do you market? How do you service? Things like how do you monetize? How do you fund? Is it legal? Is it compliant? Is it secure? If your designers don't have those skills or the lens, the engineers don't have that lens, and they're like, we need somebody. Oh yeah, that's what a product manager does. So that's why this type of product manager is becoming more clearly needed by these organizations. And we know the design and engineering skills that those are already bringing. So I think in the near term, teams, yeah, the ratio. I'm already seeing the average number of developers per team go down a bit. And this is very subjective. I see a lot of teams, and it's a tiny fraction of the teams in the world. And I probably see as many as any of them, but they're still just as small. But anecdotally, if you see the average of product manager, designer, and maybe seven or eight engineers, that seems to be going down to like five to seven. Five to six. So that's a sign, I think, of the companies, the engineers adopting the tools and feeling more productive. The second order effect, which I think is more, I'm speculating more here. I mean, what I just quoted is kind of what I've seen already, but now I'm speculating. The tools are helping the developers have what we call increased cognitive load. They're often limited to developers on your team, but how much they can grok. Old definition of grok, not new definition of grok. So how much they could wrap their head around. The tools are letting them wrap their heads around much, much larger code bases. The good news about that is that teams are able to have more end-to-end responsibility. And one thing that pretty much teams around the world complain to me about is too narrow. of purview. It's like I feel, how many of you, you must hear this as much as me, I hate just, I can't do anything without depending on five other teams, and I feel like just a small cog in a giant wheel, and I don't like that. I want to be like in control of the whole thing, bigger piece, something meaningful, and that's the effect I'm starting to see. So that's an impact on team topology. So at the same time a team, average team size might be decreasing, I think the scope of the team is going to increase, is increasing. That's more of a lagging thing. So inevitably, if there's any CFOs in the room that are looking at, well, we can have less engineers and those teams can have a bigger span of control. Do we need less teams, less product managers? Are you seeing any of that yet? I'm not. But the thing is, this is obvious. we can all connect the dots here and we're worried because historically this has always meant more teams more products more revenue and through every innovation the internet was a great example of that not less more right we're more productive but we can do more things i hope that's true with this but i it's hard to see that because we've never had this much uh impact on that so it's hard to imagine companies creating that many more products and then product teams to offset the efficiencies this is why i'm nervous about there are certain roles that are more vulnerable than others in those jobs i'm really worried for my friends in those jobs i think this comes back to the post optimist versus kind of pessimist view of this right i i think that the ai cycle is both overhyped and underhyped um i think there's there's things that we aren't even thinking about we're kind of you're looking at this new technology just uh and then looking at the products we're already building and how can we apply that technology we're not really thinking yet and some people are but very few people are about that like second order like well what can we actually do now with ai that we could never do before like the whole new categories of product whole new problems we can go solve um Lord knows there's a lot of huge problems in this world that we could go solve. And I'm hopeful that AI actually unlocks some of that potential to go after those things. So where are you on that spectrum? Yeah, I'm with you, though, that the smartest people I know keep saying that with all of these disruptions, we tend as a society, we tend to. overestimate the near-term impact it's going to like be 10x right away but we underestimate the long-term impact and you know I think that's all I've been guilty of that I think we all just kind of have it's a lot harder to see the long-term impact and it's very easy to get excited when you have people talking about how awesome this is and I'm really starting to get more frustrated with, you know, we're clearly in a bubble, and these CEOs have to justify these crazy valuations, and they say all kinds of nonsense. And it's like, I understand why you need to say that, but what I really hate is so many people I know that believe that. And so I keep trying to say, you know, your critical thinking capability is more critical than ever. Look closely. try to separate the marketing from the reality. There is real there. It's just not what some people are claiming. I mean, there's so many fun quotes, I think, from the journey of, you know, we've both seen the rise of the internet, mobile, everything else, right? And there's so many quotes of people who kind of miss that journey, right? I think one of my favorites is there was a Nobel Prize winning economist who in the mid-90s basically said that the internet is going to have as much impact as the fax machine on the economy. You're applying new technology to old business models. There's a world market for 58 computers. I think we continually get that wrong. As you're talking to product teams, how do you get people to think about that? version of the world, right? How do we start thinking more about what are the new big problems we can solve? How can we start getting excited about this, as opposed to maybe how do I eek another percentage point out of my conversion rate over here using an AI tool? Well, my favorite answer to this, and to me, when I work with teams, the first thing I gravitate towards are the engineers in the room. Because the people that are in front of this, and this is proving true right now across your favorite foundation model companies, the ones leading these things are the engineers. They are playing with the very latest technology every single day. And they're in the best position to see what's possible. The companies that have already come out with meaningful things, that's where they usually did it from. It doesn't come from the corporate planning and the roadmap and all that. That's not. But it comes from engineers seeing what's possible. And so the more time you spend with engineers on this, more time you spend immersed in the technology yourself, the better I think you get. Just, yeah, well, remember when there is, we're in the same stage. And this is clearly saying how old I am. But when Google first came out, which I definitely remember that was a world-changing kind of thing. I got a preview when the company was six people of a prototype, which was Google. And I was blown away. And one of the problems that happened was people were starting to believe the first search result, even when it was nonsense. And people had to learn how it really worked. What was it called back then? PageRank. the sort of the way the algorithm worked and how it's not necessarily the right answer and what you're looking for. People learn though. We're sort of in that right now. I get emails every day about this is what the model returned when I asked this question and I didn't think that was, you know, I thought you said something different or I thought and it's like they need to develop those skills to know how to really, how they really work. if nothing else to realize that these things these models are all programmed to be nice to you they are and to to sort of make you feel good about yourself not actually to help always so to not be a model i think i think i have to disagree with you a little i think you absolutely need the engineers in the room but i actually think going back to the earlier point this is where we as product people need to be better bringing better problems to the conversation right again then together with engineers figure out well if we have this better problem, a different problem. Actually, there's a new way to solve that with the technology. Oh, you're absolutely right. The biggest criticism I have when occasionally I'll meet product managers that believe it's their job to shelter their engineers from the actual problems. I'm like, what are you doing? They are like the best tool you have. Your job is to bring those problems to them, bring them to the customers, especially if the customers are really in pain and unhappy. So I'm not disagreeing with that, I'm just, I'm presuming that. I also find it very interesting to see, you know, ChatGPT's launch, they had no idea what they had, right? It was a demo, they were kind of putting it out one night. They'd forgotten to, I can't remember what it was, did they forget to buy the domain? Like it was just the most like ridiculous launch because they didn't know what they had, right? And it was like a technology looking for a solution and then the world found the problem, right? So I think it's not just about technology. I think it is about people and problems. And for me, I think the conversation inevitably ends up being about strategy, right? Because I think too much of our time, we get so focused on the little details and how do we increment and how do we get focused on our OKR that's right in front of us. But with AI, we kind of have to go and question the fundamental thesis of what are we even doing? What problems are we solving? How can we solve that problem differently? You're right. controversial but lately I've been having to sort of sit down with teams and especially product managers and there are a lot of product managers out there that think their contribution to the team is literally to explain that this is the problem and this is why it's important. I'm done now, I'm gonna go have a beer and you do the small work of solving the problem. And they literally think that is their job, to say the why. And this drives me nuts. First of all, it incredibly damages the reputation of product people around the world. But also, it's not even the job. That's the leader's job. Because that's product strategy, is identifying the most important problems to solve, the why. The product manager is there to actually solve the problem with the designers, with the engineers. I have to, you know, people give all these excuses. Like, oh, it's so hard to identify the right problem. Not really. It's not. The problems are all over the place. And it's not hard to verify a problem. What's hard, and this is what's hard about product, and this is where AI is so powerful, but it's true even without AI, is you have to solve the problem better than your competitors. If you don't, you lose. It really comes down to that. What product is hard is solving it better than everybody else, making it so your customers choose you. It's not identifying the problem. Yeah, you talk to founders all the time, and they're like, yeah, we gave up on it because we picked the wrong problem. And six months later, somebody else took the same problem, came out with a great product, and they're all successful. Why? The problem was never the wrong problem. It was a legitimate problem. It's not that hard to make sure it's a legitimate problem. The problem is they didn't solve it. So I really try to get teams to focus on product is all about solution discovery, coming up with a solution that is going to win or deliver the outcome you need. It doesn't have to be money. It could be solving for social issues. It could be a greener planet, like a train. It could be whatever. But that's what product is about. Delivery's hard, for sure, but increasingly something we can count on. And that really boils down to how well you can solve those problems. Is that where you see teams struggling the most as well? Because I think, and we talked earlier about the kind of the blurring lines between product design and engineering, especially with AI tooling. Does that become harder or easier with those blurred lines? I think it becomes easier as long as everybody on the team understands that that's what they're there to do. That's why I love focus on builders, the focus on building, the focus on creation. We've really sort of adopted that we don't care so much if they're called a product manager, a designer, an engineer, as long as they know they're creators. As long as they know they're creators, there are people for this. And that's what we want them to focus on. And when you're creating, you know, you don't want to go spend four months discovering the problem. We know the problem. What we want to spend four months doing is discovering a solution and making sure that solution is good and especially there are so many better solutions even to long-standing problems. I mentioned Google. There were many other search engines before Google. The difference was Google was actually a very good solution. Same is true with Slack. Same is true with pick your favorite product, iPhone. All of these things, they weren't the first. They were just way better than everything before it. What's great about, well, this was true with the internet. It let us solve problems in a totally different way. This is never more true than with Gen AI. And so there are so many solutions. One of the things I was trying to describe and trying to encourage everybody who can is to take a ride in a Waymo when you get a chance, when you're in a city that has Waymos. It's been 10 years of product discovery and product delivery. And AI products, it's a continuous cycle where you're doing both all the time. And it's amazing. I mean, it is amazing. Super hard product solving a very hard problem that has always existed, exacerbated by our last big revolution with mobile. Now everybody's using their phone when they're driving. We better have safer driving. Yeah, it is a pretty magical experience. It's a very weird experience, but it's pretty magical. So going back to that, I think that kind of the overlap, I think it's something I see teams struggle with, of like the responsibilities are blurring. We always like to have, you know, as much as it is a trio, we'd like to have one person who's responsible for one of those pieces. And I think especially in a remote, increasingly remote world, that's becoming harder and harder. So how do you coach people to work better together when those lines are blurring? In a way, I'm feeling better about it because it makes clear that it really is this collaboration, that we're all building this thing, which normally in discovery is a prototype and delivery is a product. And when we're building that thing, it requires these different lenses. And we each bring... different knowledge and there's no law that says one person brings one lens kind of thing. I know some people that are like great product and great design. I know some people that are great engineering and great design and you know we all know these. They're just not that common and all we really care about is that we have people that bring each of the necessary lenses. So there are those critical lenses. I think there are lenses where you understand the business dimensions. There's a lens where you understand the user implications. And there's a lens where you understand the enabling technology. The more of those lenses you can bring, the better. But all you really have to make sure is that somebody is covering each of those lenses. Because you've pretty much got a guaranteed failure if you miss any of those lenses. Yeah, I guess, do you ever see a challenge there with, you know, the product person who's very good at design butts heads with the designer over who's going to do what and who's responsible for what and who's right? I don't actually find many product people that are good at design. I meet tons of them that think they're awesome at design, but they're not. And so I do work with companies that seem to understand the difference, and they know how to test for great design, and they know the value of great design. But going forward, a lot of products won't need user experiences. Because this is kind of ironic. What's gone on with Gen AI has kind of forced this issue. But the whole MCP server stuff is something that we've been waiting for since 1996. That is literally the internet came out and all these web servers, but there was no way to programmatically figure out what they did. We have been wanting this for so long, and it took agents to basically say, yeah, well, now we need it for sure. And so now it's like happening. I'm still being a little optimistic there. But my hope is a year or two from now, pretty much every service that's out there that we care about will have programmatic interface like this. And it will be driven because of agents, because not always are services really optimally used by people. They might also be used by programs. So I love that whole thing. And that seems to be the impetus. It took that. to drive the change. But I love that change. And I think that's very powerful. But it also means that a lot more services will be designed for programs to use rather than people to use. And people will still, I think, play a major role. But it's not like you've got to go do everything. Yeah, I mean, that's a whole other conversation about design versus UX, right? I think it's because design isn't just visual design, as I know you agree. So I think as much as the interface might change, the interaction might not, right? Yeah. The interaction design is still important. So I think, you know, obviously the other advantage you have is a more kind of global view of product. Like, what are you seeing in the differences when you come over here to Europe from the U.S.? Oh, that's funny. Being from the US, you can't throw stones right now. So it is not good in the US with that caveat. There are differences everywhere, for sure. And in broader Europe, one of the problems that we deal with a lot is product owners. Product owners. Not all product owners are a problem, to be clear. But the training of typical product owners is exactly not what we need. And that's becoming increasingly clear. I've been sort of raising the volume on that for a long time. But it's kind of got out of control. Because sort of Agile, which is, I've been a champion and a fan of Agile for literally 20 years. But Agile has been hijacked by process people that are absolutely ruining. companies, absolutely ruining them. And we could talk about that intellectually or academically, but now those people have a target on their back. Because a lot of these companies, a lot of companies all over the world are looking to reduce unnecessary, what they view as unnecessary headcount. And official CSPO, PSPO trained product owners, that is a very vulnerable position. And I am encouraging all of them to upskill absolutely as fast as possible. And I feel a real urgency about that because for about a year, companies were kind of scared to death. They didn't know what they wanted to do. Were they going to hire? Were they going to fire? They didn't know. And they've been stuck. You've all seen. Very little hiring overall. But now they're starting to say, oh, yeah, well, we don't need a lot of these people. And so the layoffs are starting. And I just worry every day that I'm going to see more shoes drop. And I think it's really important that we do everything we can to make sure we're as protected as possible. And that means upskilling. Make sure you're focused on the real. You've all heard that Jensen quote, which is, you won't be replaced by AI. You'll be replaced by somebody that knows how to use AI. You're not really wrong about that, but it's worse than that. If your job is to follow a process, which by the way is what the roles in a delivery process like a product owner is, an agent can do that job. If your job is to driven entirely by data, an agent can do that job. So the point is you really have to make sure you are contributing what you can contribute, which is your thinking. So the things I'm talking about, about understanding all the trade-offs in a business and making those choices or understanding customer's purchase thinking process or reasoning so that we could make sure they're choosing our products. These are the things that we add value in. And the good news is we are actually, while we're seeing demand for the product owners or low-end product managers go down, we're also seeing demand for the product managers that I'm talking about go way up. Their salaries have gone up significantly in the last two years because companies understand that's what they need. So the sort of multiple kinds of product managers in different parts of the world, I think that is going to settle out. And the ones that will succeed, and they'll do great, I feel like. But the other ones are probably going to have to be looking for something else. Yeah, I think I have to agree. I think we've talked for years that product owner is part of the role a product manager plays, right? It's the process. It's the delivery side of it. And that is, as you say, the most easily automatable part of the job. So, of course, that's going away. And if that's all you do, then... Yeah, you're in trouble. And I'm really talking about the people in the world where that is all they do. And especially, as many of you know, there are a lot of processes out there where it is intentionally all you do. There is a product manager, and there's a product owner. You don't want to be the product owner in that equation. Do you ever have conversations with product teams or companies where they've been burned by that? So they've been like, oh, we've gone for the product model. We have product owners, and we didn't get the outcome we wanted. So now we don't believe products. Because I feel like I have those conversations every once in a while. Well, maybe another way of framing that is, do companies that have moved to agile think they're running the product model? Some of them do. And we have to disabuse them of that. You're actually running nothing like the product model. But it's not even about product model. I have this conversation all the time. And I say, you know, you have to realize there's real agile and there's fake agile. And fake agile is taking over lots of parts of the world. And we need to say, let's call it out. What is fake agile? And if you're doing all the rituals... Anything labeled safe? Anything labeled safe is making it very clear. But again, it's back to the marketing. If you notice that safe... Every year they do a new iteration and they include all the new buzzwords. So literally there's a version right now that says, safe embraces the product model. And it says we do product. And it's just ludicrous. And the fact that people believe that marketing makes me very sad for humanity. Mostly these are CIOs that are believing this stuff. But they do. So what are you going to do? It's buyer beware. Just like all this stuff. But it's not just safe. That's the sad part. There's a lot of people out there that even basic scrum, which used to be so vanilla and safe. It's not safe. Vanilla. Not bad. And today, they're doing their monthly releases or worse. They have all the rituals and none of the results. And it's really ridiculous. I don't know how companies have got away with that. But I do think the reckoning is happening and it's probably going to be driven by AI. Because it will probably obsolete so many of those roles that it just becomes moot. How do you disabuse those CIOs or CEOs who think that they've tried the product model and it didn't work? I really don't get that. I do get we tried Agile and it didn't work, or change fatigue. We tried Agile, we brought in all these coaches, we brought in all these experts, and we have all these rituals, you know, we do stand-ups, we do sprint planning, but we're getting no outcomes. So I see that a lot, and I sympathize with that. I feel like Agile was like hijacked, number one, but it was also oversold. How many of us knew agile coaches that went to all parts of the organization? They went to HR and said, you should be running this way. How ridiculous is that? But they've been arguing that, and they oversold it. They sort of, yeah, that's what will happen. I keep trying to tell everybody when I talk about the product model. I'm more telling people when it's not relevant. I'm like, if you don't have a team of developers building something, it is not for you. You'd be surprised how many people want to. It's like, that is not for you. It wasn't designed for that at all. It's designed for developers building things. Could be software, hardware, but it's building, engineering, and figuring out what to build and then building it. Why do you think we seem to find that comfort in process, right? Because I talk to a lot of product managers who believe they're doing the right job and are focused. inevitably it comes to like well there's the one right way we're not doing the right way we're not product enough we're not product model enough and often quote one of us in that conversation right um why do you think we're always drawn to like is it just that it's the easy solution i mean uh this is this is beyond my pay grade i do not know why certain cultures in the world gravitate more to process see it I'm used to it like when I go I'm in the UK I could say when I go to Germany there are some really great teams there people there are not the problem the culture though you have to first before they can do good work you have to you have to unbrainwash them from process you have to like forget all these silly rules these rules are not helping you it is Elon Musk famously says the problem in Big companies is that people use process as a substitute for thinking. And he's not wrong. There is this tendency. The difference is, I would argue, in Silicon Valley companies at least, they are so hyper-aware of that problem that they're scared to death of it. And they are always on the hunt for it and pouncing it out. I just read a terrific interview with Ruth Porat, who is the COO. She's the president of Google. She's like, the interviewer asked, what is it employees do sometimes that drive you nuts? And she said, I hate when they process people. I want thinkers. And it's true. It's a tendency that happens. And there are some cultures where that is encouraged, rewarded, and some cultures where it's like, wait, that's... Not right. We're doing different things here. And I just think it's somewhat of a human tendency. There is a company, I won't name the company right now, but I promise you, every one of you in the room use products from them. So it is a very well-known company and very good at product. And they had been working on something for about six months. So this was not a little feature. This was a major new product. And I had done a little bit of coaching with them because it was hard. And it was a real product discovery challenge. And they, to their credit, they figured it out. And they had a real home run of a product. One of those all new product lines celebrating. And about a month after this success, I got an email from, it was actually the head of design, who said, you know, everybody is, you know. We're getting a lot of praise here, and all the executives, they're asking us to sort of share what we learned so that other teams can have this kind of win. And so they went, they had this big off-site, and they tried to capture all the things they did that led to this success. And they put it on this ginormous Miro board, which you've all seen. And so they sent it to me and said, would you mind reviewing it and see if there's anything you know of that we missed? And I, you know, took forever just to look through it. It was so complicated. It looked like one of those safe diagrams, you know, where they put, but it was just, it went on and on. And I had to like, I literally said, okay, we need to talk. And I asked the product lead and the design. We did this together. And I said, look, I understand where this is coming from. You did a really good job. And you want to replicate that. I get it. Here's the problem. You know yourself. What you worked on, is that typical for what your company typically works on? No, not even close. I said, all right. And do you think anything else that you're working on, even if it was the same team? would be the same risks, the same issues? Of course not. I said, if you go forward, because they wanted to make like a playbook. They had a draft of a playbook. It was just on a mirror board. And I'm like, if you do this, you're basically creating a template for your company that is both going to slow everything down and not even address the things that they're likely to hit. So I said, that's not what you want to do. Instead, what you want to do is say, what were the principles that really made the difference here? And because of the risks, there were some things they did that were really important. Those are principles. In this problem, because of this risk, we realized this was the relevant principle, so we needed to work on a way to address that. And this is a really good company that doesn't really... I think they would say they're very anti-process. They would say, but that's just sort of human nature. And we have to fight that all the time. I mean, you sort of answered my next question, but I think it's so important that it's worth reiterating, because I think a lot of the criticism you get, I get sometimes, is like, why should we be looking at these other product organizations? We can't copy-paste what they do and apply it to us. And I know that's not... What you say is not what I say, but that's what a lot of people hear, right? It's like, oh, well, if only we could work like company X, then everything would be perfect. So how do you coach people to kind of balance learning from the best? How do you find the principles in that while balancing it with your actual context and the reality in front of you? Yeah. This is actually a complicated one, too, because sometimes when people are saying that, in my opinion, they're looking for an excuse not to do it. Because look, a lot of times we all do that. And it's a lot of work, and it may be very risky for your career, especially if your boss is the one that brought in safe or something like that. So you're nervous about these things, and you may be just looking for an excuse not to do it. Sometimes, though, the person really does, and they're worried about, well, what is the key? You know, this happened, do you remember when the Spotify model was the thing? And actually Spotify. It still is in some places, sadly. I love Spotify. I have tremendous respect for them. Look, they keep beating Amazon, Apple, Google, three of the most wealthy, best product companies in the world. They keep beating them. I love that. How cool is that? And this is a very good company. And I actually had this conversation with Henrik Nieberg, who was one of the coaches. Henrik is... By the way, one of my favorite coaches in the world, if every agile coach was like him, it would be a much better world. They're not. But I also told him, you know, he did a video, like he does videos of everything, and they're all very entertaining. But he did a video describing the product model at Spotify. And I'm like, Henrik, you didn't even talk about the real model going on there. You talked about superficial things. But worse than that. Because a lot of people picked up the superficial things and said, oh, we're the product model because we call them squads and we have tribes. That is not the Spotify model. That's just Spotify lingo for their use. So totally missed the point. But more importantly, he said something that I think was more fundamental, which was he said, oh, and this is not meant for you to copy paste. Remember that? He said, You should pick and choose what you think is useful. I'm like, Henrik, how ridiculous is that? Do you think, and I actually, because he's Swedish, I know you are too, so I'll use the same example on you. I said, you know, I love Swedish meatballs, which I do. We talked about that. I said, but if you want the recipe for Swedish meatballs and I give it to you, would I say like, but feel free to leave anything out? No. Right? It's not going to be Swedish meatballs. It's the same with the Spotify model. There are certain ingredients that cause that to succeed. You can't just pick and choose. And the Spotify model is not a process, really. It's principles. Are these principles? So we wrote with one of the other coaches, Joachim. I wrote an article which is the product model at Spotify to show people what the real model is. None of the nonsense with all the silly names, but look what's really going on. And here's why it works for them consistently. You can't just pick and choose. There are a set of principles. You can debate about how many principles there really are. They're not all equally important for sure, but there are a set of principles. And tell me, which one are you not going to do? Are you not going to experiment? Okay, good luck making this work. You know what I mean? There's just a set of things that I think you have to do. And really, this is what explains why so many companies can't transform to a good way of working. Because they're not really looking hard enough. They're not thinking hard enough. And they're looking for sort of an easy way out. You can't just pick and choose. And it is hard. No question. It is hard. But if you want to succeed, you're going. I often, the first thing I want to do is explain to the CEO what they're really getting into because I want them to say no now if they're not going to go follow through. They need to really understand. But I think that's what's really going on. And we need to be more open about, this is not like pick and choose your favorite little things. You know, working at the edges. So I think we're heading on time. So one last question maybe before we go for that break. I think one of the other questions I often get and you get criticized for is kind of talking about ambition. So I kind of wanted to dig into that. What do you think ambition means in product? I think, you know, at one point you were quoted about 60 hours a week. I mean, I think we're seeing, again, to the copy-pacing, we're seeing some organizations talk about 996. I mean... What does ambition mean in products? How much should we be working on it? How much does it take to be a great product manager? Well, I would separate those two, too. Ambition and hours. The hours thing is, I think, a real problem. But it's nuanced. The reason I warn people about 60 hours is because so many product managers are also being asked to be project managers. They are covering two jobs. And just do the math. If you're in meetings all day long for the classic work hours, and those are project management meetings, you tell me when you're going to do the product management. And hence, you do the math, you end up at least 60 hours. And the reason I tell people that is you need to let go of the project management if you want to have a life. If you don't care about having a life, then fine. Do both. If you do, you need to make that call. But as you probably know, not everybody wants to let go of the project management because a lot of people feel some sort of security in that. I try to fight that. I'm like, you should pick. You can be a project manager. We need project managers. But if you are the product manager, you have a huge obligation to make sure your engineers are not going to build worthless stuff. So that is your higher order job. And the ones that don't understand that I think are increasingly vulnerable. So the hour thing is a different thing. Career is more, that's what I talk about lately a lot, which is really what we were starting to get on. I said not everybody really wants to kind of do this stuff. So I'm really talking about agency there. Do you want to become as good at your craft as you can? Most people I work with, the vast majority of people I work with absolutely do. But I have realized there's a selection bias there. People come to me because like, oh, can you help coach me? Or can you help our company? They want to get better at the craft of product. I've been passionate about the craft of product my entire life. That's what got me into this. I know that's true for you too. But not everybody feels that way. I meet a few people. Everywhere I go, where they both, you know, this is the part that bothered me, they complain about their job, but they also say they don't want to, they're not up for this. It's like, okay, if you're not up for changing it, then you're probably in the wrong job. If you are up for changing it, good. Now, one of the things that you really is important to coach people on is agency. How much they can really change, assuming they want to change. So when we talk about career, the only thing I really need on their part is a desire to really get better at the craft. And there are so many things we can do to help people get better at their craft. And with that, I think we could keep talking about this for hours. As you say, we have been passionate about this for, well, not quite as long as you, but nearly as long as you. So we could keep talking about this forever. But let's hand back to James and go for a break. And then, yeah, get your questions ready. And we'll do a Q&A after that. Yes, thank you. Thank you. We've got a lot of questions on Slido so far. We won't be able to get to them all, so please take a moment, scan the code, upload the ones you really want to hear from, and we'll come back in 10 minutes. Thank you. Thank you, Corey. No problem. I figured. Yeah, there we go. All right. Well, thank you both so much for a very insightful chat. We wanted to give an opportunity to our community to ask some more questions, maybe dive in on a few other topics that you both discussed. And so I'm just going to go through some of these questions here that we have in the Slido. But like I said, we won't be able to get to all of them. And feel free as well to punt if you feel like there's another forum or answer to the question that you could point people to. And I think this first one might be one of those. Because someone asked, what's the best way to transition from a delivery-led culture to one that embraces a product mindset? I personally thought there's maybe some books about that. But I wanted to give it to you as well to consider. Well, Marty just did his last public workshop on that topic. Not his last workshop ever. He is not retiring. He wants to make that very clear. But yeah, I think there are several books on that topic, and that might be a longer answer than we can get to today other than Go Read Transformed. And I'm saying that as not the author of the book, but it's his book. Yeah, thank you. Okay, this next one, though, I thought also quite insightful. What do you think, if you just had to make a guess, is going to be the next major disruption when it comes to... product management or just product building in general. I'm laughing. Is Gen AI not enough for you? People want to know what the next thing is. Why don't you ask Claude? I mean, if AGI ever comes along, then obviously that might be the one. But I think we have enough disruption in front of us with AI and GenAI. And I think, again, as we were talking about earlier, I think we haven't actually thought big enough about what that disruption looks like. And we haven't thought big enough about the different things that we can actually build. So I think there's way more to come there, both positive and negative. There's going to be some ugly stuff. There's going to be some great stuff. Hopefully we as a community can err. most of that towards the good stuff but um yeah there's a lot more disruption within that space still to come i think right i don't know that we want ourselves with another major disruption right away right we've kind of got our hands full all right uh the next one comment said it seems to me that product engineering are increasingly being managed by the same sea level so like someone's alluding to the rise of a cpto Or at least, presumably, this is something that's relatively new. And so is this something that you see as a trend? And if so, how should teams consider preparing for it? I mean, the CTPO has been around forever. I was one in the 90s, a startup. It's been around forever. It's just the title is a little different. But it's the same thing. I don't think it is actually a trend. A few people have said they think so. But you know what usually happens when they do it? Is that person, once the company has any level of success, what is the first thing they do? They hire a head of product and a head of technology. It's just another layer. So, no, I don't really see it as a trend. It's something that if you're lucky enough to get somebody who's willing to give, talk about a high-hour job. That is two massive jobs in one. And I advise companies that have them, no problem, as long as the person has actually got both sets of skills. And it's hard enough to find somebody with one set of skills for those things. But I think it's kind of one of those red herrings. I think I am seeing it as a trend in Europe, maybe. I agree. The title's newer. I mean, it wasn't that long ago that all the product reported into the CTO anyway, so we just didn't call it a CTPO. I am seeing it as a trend, and I think in many ways I was resistant to it when I was a VP or CPO, and I was like, but I want my seat at the table. And then as the conversations flipped for me, where I'm often talking at the board level or the C-suite level, going into founders, having the conversation, I realize that what is the conversation we want to have at that exec level table, right? Do we want to have a conversation between a CPO and a CTO that maybe aren't agreeing about a roadmap? Like, no, that's not the conversation we want to have there, right? At that level, we want to be talking about the strategy, we want to be talking about go to market, pricing, like the bigger conversation. And so I think that's where that impetus comes from. Like, we want one voice to represent all of product engineering and design. And so I see it as a generally positive thing. Again, to Marty's point, the challenge is finding people who are... good enough or have the skills to actually cover both jobs and then hire well enough to cover the bits that they don't know. Thank you. A question around the evolution of the product role in general. So I know no one really has a crystal ball here, but where do you see the direction of the product role shifting over, say, the next five years? We kind of talked about that earlier. Do you want to go through that again or skip that question? It's about impact, it's about strategy, it's about making sure that we're prioritizing the right problem and then building the better solution. It's not about process and I think that's the trend we've seen. We've had events here in London Dave Washer calls it the product reckoning, where we finally realize that, oh, wait, we're a business function, and we actually have to achieve business value, and bottom line is a thing. I think that's only going to continue, obviously, increasing economic pressure, increasing financial pressure. So the trend over the next five years, more impact, right? Whatever tool you're using to do that, whether it's AI or being more strategic and other things. And I would argue, totally agree, I would argue that the other term we use for that is they achieve outcomes. Real outcomes, either customer outcomes, business outcomes, but real outcomes. And so increasingly you're seeing teams realize that everything else is kind of vanity. Briefly about prototyping solutions being kind of an interview experiment that companies are doing over in the U.S. Is that the right skill to be testing for when PMs should be focusing more on delivering outcomes or delivering business value? Well, I would argue yes. It is. Because that is what they should be focused on. And how do you do that? You need a solution that's better than the alternatives. And that solution needs to address the risks. In order to deliver outcomes, you need to solve for value, viability, usability, and feasibility. And that's what you're doing. When you just speculate or write PRDs, you're not actually doing anything towards that. That comes after you've actually come out with a solution. Speaking alongside Matt LeMay last month and he talked about the speed and rapid iteration of Prototyping as something that could potentially lead to more like garbage products or garbage solutions or features being shipped because it's just so easy now and Is that a solution or is that like an outcome that you think could be mitigated or is that not something that you see as an inherent risk as well when we are talking about shortening delivery timeframes thanks to things like AI prototyping? It's a yes and, right? So I think it is a critical skill for product people to be able to prototype because that's the best way for us to go and test something, right, and see whether we're actually going to have the outcome or achieve the outcome we want. But that doesn't take away the responsibility to be outcome-oriented, to be thinking about the business case, to be thinking about the customer and how to add value. That's obviously the core of the job. So it shouldn't be the only part of the interview, obviously, is like, can you vibe code a prototype? But it's a critical tool, I think, in the toolkit now. I'm going to guess here that he was actually saying something different. Because Matt, he knows. So I think what he was saying is not about prototyping at all, is that if you can deliver much faster, because most companies don't actually do discovery, right? My partner Christian likes to say, actually, everybody does discovery. Some do it before they build. Some do it after they build. And he's right. And what I think Matt was trying to say is if you reduce the cost of delivery, it's a whole lot easier to ship crap. And am I worried about that? Absolutely. And we've always seen signs of that, by the way. These MVPs that are garbage and companies ship them. They should never really ship a lot of these. They're like embarrassing. They don't deliver value. They're embarrassing to the brand. They hurt the customers. And I think that's only going to become easier. My guess is that that's what he was trying to say. And if he was, which I think he's spot on. Thank you. So you made some points about product owners earlier, and then people were asking about what does this mean for product operations as a function? And so curious for your thoughts on that. Is there a transactional element to product ops or how does it kind of fit in within the operating models that you've described? Well, since I've already offended the product owner, should I offend the product ops people too? I mean, I can do it with you if you want. I think we're actually both on the same page on this one. Well, the funny part is those are two totally different questions. Product ops is not really related to product owners. You can have product ops and not have a single product owner in your company. I can name companies like that. You can have all kinds of product managers or product owners and not have any product ops. They're orthogonal. But product ops was kind of a thing a couple years ago. It was starting to rise, and then it kind of fizzled. Now, I actually, there are lots of different definitions of product ops, but mostly we love user researchers, we love data analysts, and that's what was included in most of these definitions. And those people are still there, whether we need a whole extra, you know, another layer of management to manage them is not clear, but it just didn't. A lot of those lower level user research jobs, lower level data analysts are being replaced by tools. So I think that's more of the vulnerability. It's just become less of a focus. And also, well, this is more my bias, not a big industry trend. But I don't like giving product managers, oh, you have an assistant. you have an assistant. For the same reason I don't think any product manager should have a product owner assistant. Do developers like using Jira? Do they all get an assistant just like a product? Man, that's ridiculous. So I think product owners need to own their job, just like designers and engineers do. Product managers. Did I say that? You said owners. Thank you. I think product ops The risk I see with product ops is when you have a team, and I'm not talking about user research or data, like those centralized functions that you need, but when you have a team that's responsible for product ops, the risk is always, and I see this happen too often, that they start dictating ways of working, and it becomes, again, more about process than outcomes, and so I'm slightly allergic to it. I do think there's a place for kind of the chief of staff model where you have one person who's there to help, you know, in a larger org. where you have a lot of product teams and you maybe just need help managing schedule and events and meetings and ceremonies and things like that. But it should never take away from the product manager's individual responsibility to own how they do the work, the fact that they're going out and talking to customers. It's the same user research and data analysts. Just because we have a centralized function doesn't mean product managers don't do user research or don't look at data, right? They're still primarily responsible for doing that discovery. those other people are there to coach how to do it better. So I think that's the distinction I see, and I always get nervous when there's a big team in product ops because it starts taking away that responsibility from individual teams. And also from the leaders. A lot of what they're doing are things the product leaders should be doing, and you really can't delegate that. It doesn't work. So the other thing that kind of bothers me is historically, having somebody that kind of looks at best practices across your organization and shares them, of course, we used to call that person the principal product manager, right? That was the best product manager in your organization. But you notice in these product ops teams, they're often using it as an entry point. So this is somebody who's got the least experience. And then they're defining the practices that the others are supposed to use. That's just institutionalizing bad behavior. So occasionally you see that anti-pattern, that's not helpful either. So I personally haven't shed a tear that that has fallen off the radar. And I actually think a better way to solve it is these days. I love that dual track career thing of having principal or lead or whatever the title is. But I also believe strongly in building strong communities of practice where all the product managers help each other level up their craft as much as the leader should also be doing that, obviously. Thank you. On that topic of developing people, someone asked about the impact that AI might have on junior or entry-level product professionals. We've seen a tightening at the leadership level. at least a couple of years up until maybe recently. But what does this mean for people who are trying to get into the field when most of the jobs are mid-career or higher and how the job is doing is transforming so quickly? I think I am afraid of that, but I think actually what I've seen happen is more that middle managers getting cut, right? I think if you're looking at, especially the big tech companies, they're increasing span of control. We talked about that on the individual level, but we're also seeing that at like the senior product, group product, director product level, that they're actually more direct reports, cutting out, literally cutting out layers in the middle. So I think that's at least where I'm seeing a lot of the initial kind of cost saving coming from. We can have a different conversation about whether that's a good thing or a bad thing, but that's what I'm seeing more of. I do fear that if we don't bring in, and this is true for engineering and design as well, right? As much as we're automating these roles, if we don't bring in junior people, we don't think about that like we're not going to have anyone to take over when some of us want to go retire, right? I'm super worried about it too. I just agree with you on the leaders, but I'm not sure that's tied to the AI. I think there may be some other trends that are going on, but that is definitely happening, the increased span of control at companies, reduced middle management. But in terms of junior people, I'm worried about that, especially product managers, product owners, those roles. And if those roles don't exist, then how do people kind of make the leap? It sort of suggests that the education system needs a big revamp, which I think even the education providers, the universities, are realizing this is necessary. Gen AI has really impacted them, and education, the whole system. We all have seen that. But it creates a real problem. apprenticeships programs because apprenticeship programs of various sorts many of you know in the product world we have APM programs which are really apprenticeship programs for product managers I love those in it to me in an ideal world everybody would be able to go through one of them it is such a great way to accelerate and go from right out of school or right out of whatever to really high performing level the kind that companies really do need so it dramatically accelerates that learning curve and I think we're gonna need things like that you know if I put on I've been kind of pessimistic tonight if I try to put on the optimistic hat there are already some pretty decent coaching tools that have come and You can imagine people having a way to accelerate, like take the learnings of the world's best APM program and do a self-taught program and maybe in three months they would be ready for the level we're talking about. Same with engineers. I'm more optimistic on the engineering front. There's a lot of things people can do before even they get out of university that prepares them. But product is a harder... It'll probably happen later. Yeah, so I think for any leaders in the room, think about your team mix, right? So don't just hire a senior. Like I inherited a team at one point that was all senior product managers, which you'd think they're like, oh, that's amazing. There's all this experience in the room until about six months in and you have a review and everyone of them wants to be the next director, right? So you don't want that. You want a good mix of skills. You want a good mix of experience. You want a good mix of levels in your organization. So don't write off the junior product managers or the first-time product managers just yet. And I'll just do one more on this topic. And you mentioned earlier about middle management feeling a big squeeze, maybe related to AI, maybe not, as you said, Marty. So what can someone kind of at that level of experience do best to set themselves up for success? Sorry, what level? Middle management. So I think GPM. maybe on the cusp of director, but not quite leading large organizations yet. Well, this is another big topic. So I mentioned that a lot of product managers aren't really doing the job they need to do, and the real big demand for the kind of product managers we're talking about here. What we didn't talk about, who is responsible for creating those people? That is the product leaders. Another, I feel like I'm beating up on Europe, and I especially feel embarrassed about doing that. being an American. But there are a lot of companies, this is more on Europe proper, but there's a lot of companies that believe that you can have managers that are managing people in a product and engineering organization that have not actually done the job. goes by different names but sort of people only manager that they like you could somehow be an engineering manager that has never actually been an engineer or you can somehow be a design manager and never been a designer especially with product and to me that's so much nonsense just so far out of reality and yet they do that in a lot of big well-established companies that is the model and and of course There is nobody helping these people learn how to do their job well. Sometimes they'll try to get somebody on the side, but the problem is if it's not your manager, not everybody even listens to them. They don't feel like they're really, it's their job to get better at the craft. I was super lucky for the first 10 years of my career. I worked at a company where coaching was part of the culture. I always had, every day for 10 years, I had at least one person who had specifically told me that their job was to help me get better at my job. The one time I wanted to learn something that was outside of what my manager knew, the first thing he did was found somebody else to coach me on that. I mean, that's how you learn. So this idea of, so the point is, this is the primary job of first level managers. First level managers. Those who manage individual contributors. Most of their job is staffing and coaching. This is not something you give to HR. This is something that you do. And in fact, I was measured. A manager, I was at HP Labs at the time, and a manager was judged, evaluated by how many people they got through the promotion process. Which you can't do yourself. You have to get somebody ready and then nominate them and then your peers have to decide. Like Martin's earned it. He is now a VP or a director. And so it was all about incending people to get better. That is how we move people through. And it was our job as managers to do that. That is very strong at most good companies I know. But in some companies they seem to not understand that leadership principle. At Apple, they call it experts lead experts. You only work for somebody who knows what you're doing. Okay, so I'm going to move on from the topic of talent management, but I am going to bring up a topic that has come up a couple times that has to do with cultural and regional differences. And so you talked about a few of the cultural norms outside of the U.S. that have maybe impeded success of companies in regions like Europe. What are some of the U.S. cultural norms and organizations that are impeding their success or worse that maybe European organizations can be wary of? Oh, man, we have plenty. And the thing about the U.S., it's kind of like Europe overall. There are many different regions with very different tech cultures. And honestly, I have to admit, even San Francisco has multiple tech cultures. It can be really frustrating because literally across the street, it's a completely different place. But for example, in the East, we have a lot more of the bigger companies, a lot of the financial institutions, a lot of the defense and aerospace industries. And they can be very bureaucratic, very heavy process. the lack of innovation because of that. So that's a big cultural thing. Yeah, what else is interesting? I mean, I think move fast and break things, right, is probably a pretty bad idea, especially when you then start influencing elections and democracy. But yeah, I think there are. But to me, it brings up this point, and I think we hit ourselves over the head a bit too much in Europe sometimes and think we're behind the US. To Marty's point, I think this is all a wave, right? It's just like the technology adoption curve. There are leading companies in the world that happen to be in the U.S., but there are also a bunch of them that happen to be in Europe. And then there are laggards. There might be slightly more laggards in Europe sometimes than in the U.S., but there's just as many laggards in the U.S. that don't get it, aren't operating in the product operating model, are still stuck in IT models. So I think we have to be a little careful to be too much about looking over the fence, and the grass is always greener. And I think it goes back to that point about how can we focus on our craft and continually be improving our craft, challenging that status quo in our organizations and how we build our products. Because everyone can always do better, but I think we have to be a little careful to beat ourselves over the head too much in Europe. The thing that's really useful to separate, because honestly I struggle with this in Silicon Valley, there's a difference between those who are great at the craft of product. And those that have values that you can be proud of. There is some really not good values and leaders. We have a few of those here too. I'm particularly sensitive because it used to be there were one or two and we would sort of ostracize them. Now it's like, you know, I used to actually have a policy of removing quotes from now I'm like, I need quotes. But it's amazing how it's sad. But that is a real issue. And I help talk to a lot of people and I coach a lot of people. And sometimes they literally just have to leave that company because they can't sleep at night for what they're contributing to. And some of these companies are the best at product. So this is a totally different question about whether they're good at product. It's a tool and you can use it for good or not good. And yeah, a lot of this is driven by the motivations of the founders and the owners. So yeah, you do have to be really careful and it can be hard. And sometimes what happens is the money and the power changes people. I've seen that. Final question for you both. Just want to end this on sort of a positive and uplifting note. Yeah, not on that last one. Yeah. international norms and the challenges I don't want to end there so a lot of change a lot of disruption right a lot of good news some challenging news like what's something that you'd want this group and folks watching today to kind of take away from this that is a positive lens to look at to the future I think I'll let Marty have the last word so I think for me it is realizing that Good enough isn't good enough anymore. And so I think as we can ship more and more stuff, you know, however we're doing that, the craft of great product is more important than ever. And not everyone realizes that yet. I think they will. I think there will be a lot of reckoning where crap products get shipped, have terrible outcomes or have, you know, cybersecurity issues or all sorts of stuff that's going to kind of have a reckoning there. But there's no doubt we're going to be building more software. We're going to be solving more problems. But the craft of product is going to be more important than ever. And so the more you can focus on that craft, the more you can focus on the impact you're having, the more you can contribute to that. Thank you for doing that. You gave me time to think us up. And I did. This was actually so inspiring to me. There's a person that Martin and I both know, Teresa Torres. She's the author of Continuous Discovery Habits. She also does courses. runs Product Talk. She's a longtime product coach, one of the original two product coaches that we recommended for years. She's just really good. But I don't know how many of you heard this, but about six months ago, she's such a badass. I love this. She was playing ice hockey, and she broke her ankle really bad, actually. It needed bad surgery, serious surgery. And for three months, she told me she wasn't allowed to. put weight on it and so she was trying to figure out what to do because she couldn't really do the stuff she's used to doing but she didn't want to waste three months of her life and she decided she was going to use the time to teach herself how to build an ai product and she uh it was such um there's actually two lessons to this first of all she she shared a lot what she learned in some writing she did a terrific uh podcast She took a course on evals. Eval is the process we use to basically, it's really what product managers and designers do on an AI product to help shape the solution. And she took the course on that. She sort of went along. She built a real example. And she wanted to write about how she built that AI product and the lessons she learned, which was great. It is one of the best case studies out there. There's not that many out there right now, and it's one of the best. But that's not why you should watch. I sent some links to a video and to an article. That's not why you should watch this stuff. It's because it is such a beautiful example of somebody who is demonstrating very high agency. She ran into a thousand obstacles, and she got over every one of them. amazing humility she wasn't afraid to say like I have no idea so she would literally go to her favorite model at the time and ask like what is the next step here and she would start learning so very you know humble to be willing to say I don't know who knows this stuff I want to learn it totally open mind and also such a great critical thinker because she did not trust a single line of generated code, a single answer from the model. She knows not to. She's smart enough to know not to. And she only went forward once she understood. It took her about three months. And the whole example of agency, humility, strong thinking. to me was just beautiful. I called her and I told her I loved that. All the things she's written and I love her book. I wrote the foreword to her book. It's always been good. But this was like next level. And it was very inspiring to me. And I was trying to tell because so many of us want to learn this stuff. But there's a million reasons not to. And she said, no, I'm going to do it. And she did it. And she's now actually... quite a leading thinker on a lot of these, especially probing like how it impacts continuous discovery and continuous delivery. Her main learning was, luckily, she was right in the middle of what the skills that needed to be done, but she wanted to learn, well, how is it different for a probabilistic product versus a deterministic one? And it's really different in some interesting ways, and she wanted to wrap her heads around that. What a great example for all of us. It actually motivated me to dial up. I was already spending time, but not as much as she was spending. And I find it very inspiring. If more of us did that, anybody, let me put it this way, that's willing to do that is going to come out really good. All right. Well, that just about puts us at the time of my fellow organizers up. And I also want to thank Martin and Marty for joining us this evening. And so... This is our last event for 2025. I just want to give another big thank you to all of you for making this one of the biggest years for Product Tank ever and also thank the rest of my organizers here. We'll be in touch to get your feedback about how we can make 2026 even better and continue serving the community so again we can all make better products together. Thank you. You guys want to take a couple of photos?

In this fireside chat, Marty Cagan and Martin Eriksson will address the future of Product Management, focusing on their specific implications for companies and product professionals in the UK. 

Our guests:
Speaker 1
Marty Cagan - Partner @ Silicon Valley Product Group

Marty Cagan has been helping companies move to the product model for more than 40 years. Before founding the Silicon Valley Product Group to pursue his interests in helping others create successful products through his writing, speaking, advising and coaching, Marty served as an executive responsible for defining and building products for some of the most successful companies in the world, including HP Labs, Netscape Communications, and eBay. As part of his work with SVPG, Marty is an invited speaker at major conferences and top companies across the globe. Marty is also the author of the books INSPIRED: How to Create Tech Products Customers Love and EMPOWERED: Ordinary People, Extraordinary Products, and the new TRANSFORMED: Moving to the Product Operating Model.

Speaker 2
Martin Eriksson - Founder of ProductTank & Executive Chairman of MindtheProduct

Martin Eriksson is an entrepreneur and product leader with nearly 30 years experience building businesses, products, and teams in multiple markets and industries. He is an internationally renowned author, advisor, and speaker on product and strategy, and is an influential thinker in the space.

He has worked at The Financial Times, Monster, Huddle, Covestor, and Cazoo, and literally wrote the book on Product Leadership. Most recently, Martin has served as the Product Partner at EQT, the world’s third largest private investor with over $225 billion AUM.

As the Founder of ProductTank and Co-Founder and Executive Chairman of Mind the Product, Martin has helped define the industry and shaped the practices of a generation of product managers.

Your host and moderator:
@CoachJamesGunaca - Founder, Product Sphere & Product Management Career Coach

As always we will close our meet-up with a candid discussion and Q&A.

This event is hosted in collaboration with Trainline.

Key takeaways: 
— The role of the product manager is not going away — but the focus is shifting away from purely delivery or process management and towards strategic impact, problem definition, and solution discovery.
— Artificial intelligence (especially generative AI) is a game‑changer, but it’s not simply about faster delivery: building “probabilistic products” (i.e., AI‑driven, learning systems) is harder, slower, requires new skillsets and team models.
— Delivery (engineering, building) remains important — but the constraint is shifting: teams must be clearer on what they are building and why (problem/solution) rather than just how fast.
— Team composition is evolving: fewer engineers per product team, greater scope per team, but higher expectations on each team for end‑to‑end responsibility. This raises the value of product managers who can bring business, user and technology lenses together.
— Beware of blindly copying operating models (e.g., calling squads/tribes like another company): successful models rest on underlying principles, not labels or rituals.
— Roles like “product owner” (delivery process focus) and “product ops” (process/enablement) are increasingly vulnerable to automation or being squeezed unless they shift towards strategic craft.
— Talent development matters: organisations need to create pathways for juniors, not just hire seniors; individual product professionals should cultivate agency, curiosity and craft mastery.
— A positive lens: the volume and speed of product creation will continue to increase, but this makes the craft of good product more important than ever. Those who focus on meaningful outcomes and high‑quality solutions will stand out.

Chapters
00:00 – Welcome, community intro, and sponsor remarks
04:00 – Fireside chat opens: The future of product management and AI’s role
09:00 – AI tools vs AI product: Impacts on speed, complexity and discovery
15:00 – Product team structures: Shrinking dev ratios, expanding scope
22:00 – What makes product hard: Impact, not process
30:00 – Agile, fake agile, and why process is not the solution
38:00 – Product ops, product owners, and vulnerable roles
46:00 – Why copying Spotify (or any model) usually fails
52:00 – Ambition, agency, and the future of the product craft
60:00 – Audience Q&A
84:00 – Final thoughts: career growth, global differences, and product optimism