Combining business & product mindsets - with Rich Mironov @Product Management Consultant & Author

Welcome to the Product Bakery Podcast. Another episode today with my co-host Alex, I'm Christian and our today's guest, Rich Mironov. Hi, Rich. Hi, great to let me join you. Before we start, just a small social media shout out. Feel free to follow us and share the podcast in case you like it and you see some value for other people. And as well, you can join us on our new website, product-bakery.com, where we have episode pages. Meanwhile, with additional information and you can also drop a couple of comments in case you have feedback or questions. Amazing. So in order to get started, I want to take the time to quickly introduce our guest Rich, where we can see already his cat on the table behind him. Lovely to have him here also on the podcast. So Rich Mironov, he is definitely around for quite some time in the product space. I think it's also fair to say that he is a product management guru. And it's since the last 20 years that you, Rich, started consulting different companies. And I think in these 20 years, you've obviously seen a lot coaching different product managers, even taking the role of interim VP of product for different companies. And not to forget, you also wrote a successful book, which is called The Art of Product Management Lessons from a Silicon Valley Innovator. Obviously, a book that we recommend to everyone out there to have a look at. And we will also make sure to link it in the description for more information. But Rich, maybe before we get into the trickier questions, maybe you can just tell us a little bit more about your journey and how you actually got into product management. Sure. And it goes way back. So I actually have almost 35 years of enterprise B2B product management. So we're back in the 1980s. Just out of university, I actually was a developer. I wrote COBOL back in the days before FHIR was discovered. It goes way back. Good old COBOL times. Yeah, that was okay. It actually wasn't as exciting and interesting as I hoped it was. So I dropped out, did an MBA and then came back to tech. Briefly had a job in corporate strategy, also didn't float my boat, and then was given the chance to move into product management, which I had no idea what it was and nobody could tell me, just as it is today. Yes. So my first product management job, 1988. So doing that for a long time. Some name brand companies, Hewlett Packard, Tandem Computers, Sybase in the early days of the database wars, that's the early 90s. And then I dropped out to do a series of startups and I hung my shingle out in late 2001, coming off a startup that wasn't working out and I didn't have another plan. By the way, the definition of a consultant is somebody who has a mortgage on an expensive house in Silicon Valley and a child who wants to go to an expensive American university and no income. That's pretty much the definition of a consultant. So when I found myself in that situation, I discovered that I was going to be an independent consultant and that's been now 20 years. So I look back, I think I've had 150 different clients over those 20 years, plus two or three stops out of that to go back to found or joined startups. So a lot of enterprise startup blood in me. And these days, the things I'm doing most, I coach heads of product. So I think this month there's probably eight or nine VPs of product, chief product officers who I try to spend an hour a week with, team psychiatrist and coach. I do some designing of product organizations. So come in and assess how the product management team's working and how they're interfacing with the other key groups and how do we rearrange or rehire or change jobs or align against engineering, whatever, to make the product team better. And then, as you mentioned, occasionally I drop into a company as the interim head of product if they didn't have one and then try to replace myself as quickly as possible because every company deserves a full-time permanent head of product, not a borrowed or interim or temporary one. Wow. I mean, that's 20 years. And it sounds like there is definitely a lot of stories in these 20 years of really having a lot of different insights into different areas of product management, different companies, and taking on different heads as well. Maybe one thing that's definitely very interesting to us is to hear a little bit more of where you generally see the biggest challenges also for companies and especially also product leaders, as only last week we talked about product leadership in the episode with Luca. Sure. And to the extent that product management is sort of loosely defined and we end up owning the problem of making a product successful, even though almost all the inputs and all the staff and all the resources are not in our control. So we have all the responsibility, none of the authority. And so to some extent, a lot of what I see is organizational breakage or misalignment where classically the sales team is being incented to sell something that's different from what the engineering and product teams are building. And we know that salespeople do what you pay them to do, not what you want them to do. And so if the comp plan, if the way we reward and promote salespeople is misaligned, then nothing else that the company is going to go well. The other sort of core things I see a lot of is I see product teams where the folks they're working for don't actually understand the distinction between product and program or project management. So to the extent that we give people a label, what we really want them to do is make sure we ship stuff on time and to stand over the development team with a whip or, you know, pizza or whatever it is that's going to make them work faster. Yeah. Right. So, you know, it's, it's the wrong job. Now that's a critical job. It's an essential job. Someone should be doing it, but the product role is really all about making sure that we're sequencing the work in a way that delivers the most value and motivating our development teams as best as we can. So we get good work out of them, but the, the leverage we have, the advantage we have, the value we deliver is that we're doing the more important things first, because if we do the less important things first, we still get a lot of work done. It just doesn't matter. And then the third thing I see a lot is I see product teams that are dramatically understaffed versus their engineering counterparts. So almost all these, you know, assignments or consulting gigs, I'll get an org chart and I'll count the people. And for me, there's, there's a broad category I call makers. So that's developers, designers, dev ops or cloud ops, tech writers, test automation engineers, all the folks who actually do work to create the thing that we're going to call the technology pieces of the product. When I count them up and I get a ratio from them to the product team, product managers, when that's above, let's say nine or 10, let's, let's imagine it's 30, which means we have one product manager matched against three whole development teams, right? I know the product managers are failing no matter how good they are. So, you know, I can't pull, you know, an entire car behind me. I'm not strong enough and big enough. If we have four product managers and 60 people on the developer and the maker side, I know they're not serving well, no matter how experienced or smart they are. So, so often this is trying to figure out what's missing, right? Since I was an engineer, I can remind us that every system has a bottleneck. And when we fix that bottleneck, the system has a new bottleneck, right? Because every system has a bottleneck. When product management is the bottleneck, when there's not enough product managers, then everybody else is scrambling to figure out what's important. Everybody else is scrambling to do their own segmentation and pricing and packaging, to have developers on their own going out to figure out what users want, to have designers not clear on what the goal of the interface is, when, when I see that ratio of makers to product managers exceed nine or 10, I know that everyone else is having to do their own bits of product work and they're not trained for it. They're not expert at it. And it's not why they hired them. When we look at the three topics that you just mentioned out of the three key problems, what do you think, where does it start? What is the biggest issue you usually tackle when you get started as a coaching consultant? Oh, one of the big ones. The CEO is also the founder and is pretty sure that he or she knows all the answers and is not interested in any feedback from the market. market. It's a good one. And on top of that, he used to play the CPO for quite some time. That's right. And it may have worked when it was 8 people or 12 people and the thing that's really difficult about that is there's this survivorship bias, selection bias, which is the 96% of the companies that utterly failed because their founder, CPO didn't have a clue aren't in this situation. They're the ones where they got it right enough, but we really want to have more expertise, more tools, more analysis, more thought, more strategy. And it's really hard to go back to a founder, a founder, CEO and say, you need help in these areas. You're busy. You have a lot of other jobs. You're not doing it that well. We could make more money if you would relax some of your control. That's a very hard sell. And notice it actually has nothing to do with an individual product manager on the team. If I were the head of product or the VP of product and I had nine folks on my team, all nine of them are failing for the same reason. And none of those nine can convince the CEO to back off. So that's an executive level, a leadership level challenge for whoever's running the product team to find some thoughtful, humane, polite, acceptable way to help the CEO founder redirect energy without getting fired and without upsetting everybody. Notice that's as much about people skills and EQ and understanding your audience and Myers Briggs, whatever, as it is about, you know, knowing how to write a user story. But it's to me also connected to, how can I say, I think one of the issues that I see here is that such fundamental personal issues that founders, CEOs can bring with their attitude or with their way of managing the company is something that can be either tackled or educated by an external person like you. But on the other hand, I also believe that's part of the product leadership, right? To communicate exactly in that direction. Absolutely. The best outcome. You're exactly right, Christian. So the best outcome here is that there is a product leader, not always true, and that that product leader deeply understands that this is a core issue and that they have a lot of good tools and skills because generally the first one or two or three things you try may not work, right? So there's persistence and there's a real depth here. So I think of, so in a lot of ways, product managers are anthropologists. They're students of human behavior, right? So we have to really understand how the different parts of the company are motivated, how they're rewarded, what they care about. And that's about looking, you know, deeply into the people as opposed to thinking that showing a spreadsheet with 11 columns and weightings is going to prove that my strategy is better than your strategy. That actually works on the engineering side. It doesn't at all work in the executive suite or on the marketing sales side. If you're a product leader, and a lot of my coaching is around this, you as a product leader have to, you know, psychoanalyze. You have to really understand what's driving the different players in the company and you have to package up the right answer in a way that they can hear, that they can accept, that's not threatening. There's a lot of coalition building. So, you know, sometimes I can get sales on my side if marketing's not quite there. And sometimes I can get marketing on my side if, you know, the professional services team isn't getting me to the right place. It's way better. I'm happier when in the weekly executive staff meeting, I don't make the proposal that I wanted to make, but somebody else on the executive staff, maybe three people on that staff, bring forward the idea that's the right one. I don't care who sells it. It's not about me and my ego. So often there's a lot of shuttle diplomacy here where I pitch or sell or convince or discuss with every single member of the executive team one-on-one so that when we get to the big meeting, there's no drama and everybody is there. In some ways, you know, those are selling skills rather than product skills. But I don't think you can be a product leader if you're not out-thinking the rest of the executive team so we can get to the best answer. You need definitely to be a very aggressive salesman. Yes, right. Although aggressive in a way that's less obvious. Yeah. More proactive. That's right. Proactive. Exactly right. So some executive teams run on facts and some of them run on recency bias and some of them run on whatever the CEO said this morning or thought of in the shower. And as the product leader, in fact, going further, I'd say the head of product, the product leader is product managing the executive team in the same way that the individual product managers are managing products. I have to figure out my audience. I have to figure out my message. I have to figure out how we're going to get to the place where we ship more stuff and make more money and have happier customers. And it's not important whose idea it was, even if it was mine. It's important that we as an executive team get to a good answer and make our customers love us more. One thing that I find super curious about this is it's generally also about leadership and diplomacy. I worked mainly or mostly with designers also in the past. I mean, usually they are also often facing similar challenges when it comes to how to manage stakeholders and how to also like kind of steer through different opinions. And I think design is definitely something that has even more opinions in the field. And then you might even have to manage a product manager to some respect. But I think one thing that I find quite interesting is that these roles that are like pretty wide all require you to fully understand and empathize with the different stakeholders. And maybe this is just an observation or also a question towards you. Some other stakeholders can or are much more stubborn in some cases, because I think as product manager or product person, you're always kind of in between trying to find the sweet spot that makes everyone happy. Yes. Yes. Spot on. And I think product management is probably 10 years ahead of design on this. A lot of design teams are still in a place where the executives think of them as folks who color in buttons instead of folks who design great experiences that make customers love us and give us money. And so I think often I see both myself and other product leaders needing to be the champions for design, whether the design team works for product or works for engineering or works on whatever. Designers often don't have a seat at the executive table. They don't have good understanding. And if we're going to have a great product, we better have a great design and great experience. So that means part of the product leader agenda is to try to get more respect, more clout, more, you know, whatever for the designers or we ship crappy stuff. But at the same time, I think, and it comes down to the point of like the way you also mentioned that product managers are anthropologists, I do think and I've heard this topic of having a seat at the table as designers quite often and a lot of especially more junior designers when interviewing them, they are like, okay, where do you sit in the company? Are you in the executive meetings? But I think it's a little bit like also this where designers tend to see themselves in the company. But when you manage to individually, like is it your cross-functional team? Is it your stakeholders and so on to build the right relationships? Then you can have massive impact even as an individual contributor without going into the leadership. And it also needs like the whole, like a whole design team to really work with stakeholders and so on and step out of this area where they are just coloring and because they don't manage to build the right relationships in the company. It's often a little bit like a two-sided sport, right? And where I wouldn't always blame the organizations, right? I think it's often also designers who don't like really try. Yes, we hire designers, right? We hire them especially because they have great design skills in the same way that when we hire system architects, software system architects, we hire them because they're great system architects. On average, they're not great communicators and they're not great negotiators and they're not great organizational strategists. If we were only going to hire system architects and designers who had all those skills, all those jobs would be empty, right? So to the extent that product is in a collaborative role, we're trying to pull the pieces together. We're trying to make the right things happen. Often the product team is the visible face or the coach or the, you know, I often bring designers into meetings and I'll do much of the talking. But most of the talking is about how great they are as designers and how they've done a good job on this design and why it leads to happy customers. Basically, I'm there. I'm their public relations arm. They're doing the hard, interesting work, but they may not necessarily have all of the organizational skills or time. So if that's necessary, often I see the product folks be the champions and the promoters for the folks on their extended team who do great work, but don't do that for themselves or thought there before I let it go. So something I love to do, think of this as like every third or fourth week. So when I have a team, which I don't right now, but if I have three, four, five, six product managers working for me, let's say once a month in our weekly meeting, I'll go around the room and ask for each product manager to name for me one person in their extended team who's doing a really, really good job, but doesn't get much thanks or attention or appreciation and then, and they'll tell me who it is. And I will actually send a thank you note, not to them, but to their boss saying, thanks. We're really glad that so-and-so who's a designer or a tech writer is doing a great job. We love her. We want her on our team next time. Please thank her for the good work she does. And that's a way to generate visibility for folks who are doing a really good job, but aren't self-promoters. Again. So, so, you know, when I think about what product managers do, it's more than just writing user stories and accepting work. It's, it's understanding the, the emotional makeup of our teams and how we're going to get the best out of them by rewards and promotions and, you know, back pre COVID, we would all take a trip to an escape room or some geeky outing, right. You know, how do we, how do we get our, how do we get our team emotionally connected to our end users by inviting them in on our interview calls? So they, they hear real users talk and they get excited and they want to solve real problems for real users. I don't think product managers only need to look at the emotional part or the whole communication part. One thing that I see that is very important is the whole topic around negotiation. And I would be also curious to hear how do you see the whole role of communicating and negotiating with stakeholders to handle all those customer requests and also internal requests that, for example, are coming from sales teams or marketing teams who are regularly trying to push their agendas, which definitely happens to stay really focused on the product and the main thing and delivering value to customers. Good. I mean, I'm actually going to wind back for a minute and then answer that because I don't want to give the impression that the product management job is just strictly an emotional job, right? The first 60 or 70% is making products happen that customers are going to pay for that, that sell well in the market, that are technically correct and buildable, right? So, so if you're not doing the core product management work, then you don't need to worry about the emotional stuff because you're going to fail anyway, right? So the emotional work is the last 20%, right? But back to your question, Christian, so we know, at least I know, that there's an infinite appetite within every company for more features and more capabilities and more stuff, right? And even if we just did everything that sales wanted us to do, we would never get to the bottom of sales's list, right? I'm a B2B enterprise guy, and I know that every enterprise sale has just maybe two little special things they want. By the way, they're not little, you know, and, and the sales team, right? The sales team may only be closing two deals this quarter. And so if they lose this deal, because I said that that feature request is one we're not going to honor, then they will, first of all, they're not, they're going to get fired instead of paid. They're immediately going to escalate up through the sales channel to the CEO, right? And when I look at that request, and yes, it's always small and big in quotes here, but my joke is they promised a customer by Friday, we can add teleportation to the product because how hard could that be? I bet it's only 10 lines of code. We can knock it out, no problem, right? So we wrote it into the contract without telling anybody on the product or engineering side. And I have experienced that a couple of times when I was working in B2B enterprise, it was literally every time selling more and stuff that was never agreed on, never on the roadmap. It's absolutely real shit. It is. It is. That is exactly what happens. And if you're in an enterprise software company, and you're surprised when that happens, then you're not very observant because it's what happens every day. But back to the stakeholders. So there's a construct I use sometimes that I think is good, where if we imagine all of engineering's or development's resources, bandwidth, story points, person weeks, whatever it is, right? If we imagine it as a pie chart, and pie charts have this very cool feature that if you make one slice of the pie bigger, you have to make another slice of the pie smaller, which is going to be really important in a minute. And then I try, or we try to negotiate at the very highest level, at the executive level, some blend or mix. And we might say, we're going to spend half of our units, whatever it is, story points, engineer weeks, something, on outward facing features that are customer requests that we're going to trade off against each other based on how much money they're going to make or how happy they make our customers. And we're going to spend, let's say, a third of all of our points or engineer weeks on infrastructure and security and tech debt and fixing bugs, right? And that's really, really important because if we don't have some overall allocation or strategy or budget, what happens in enterprise companies is that each sales team consumes just a little more than the last sales team. And at the end of the quarter, we are surprised to discover, every quarter, that while we intended to spend a third or 40% on keeping our systems running and secure and scalable and fixed, we accidentally gave that away one slice at a time. And at the end of the quarter, we discover we spent 100% on individual features that didn't move the product ahead, that don't open up the market, and that our technology is a steaming heap of broken things, broken toys, right? And so having an allocation lets me then set up a sort of, think of it as a competition, right? Because now there's going to be a competition for the half of the pie that's outward-facing features based on customer requests. And in that half, I actually can measure revenue impact and customer satisfaction impact in kind of similar units. So I can then go back to the sales team and say, there are no specials for any deal that's under 600,000 euros a year, right? Unless it's something that product has chosen because we know a lot of people need it. So if you're on a sales team and you're the only one wanting this and it's a 100,000 euro deal, don't expect much because the bigger deals are going to get ahead of you and consume the portion of the pie that gets that thing, right? Notice when I unitize it in revenue, now the sales team can fight among itself and the head of sales, the VP of sales, or the chief revenue officer, who by the way is paid. How are they paid? They're paid by total revenue for the company, right? They get commissioned on how much we sell. And so the head of revenue, the VP of sales has now the right incentive to escalate the deals that we can really win and make some trade-offs between a few easy fixes that might help three deals close and a hard fix that only one deal will close. Because we've now moved the incentive model and the decision-making to someone who's more likely to have the good answer for the company, not just for the one customer. Likewise, the support team and everywhere, right? So your customer support or customer success team has an infinite list of bugs they want us to fix and small enhancements, and we could spend the whole 100% on them and still not be done. But if I go back to that team and say, you know, we're going to allocate 150 story points a quarter, whatever, for things that are at the top of your list that are going to reduce tickets and make your life better and improve customer happiness. Now we can have a negotiation in as equals about which of the 690,000 things they want, which six of them, which four of them are really important and are going to make their lives better. And the trade-off lives partly with them, because if they ask for a bunch of tickets that don't help them and don't cut support calls down and don't get people off the phone faster and don't bring customer joy, then it's partly their failure, not just mine. I'm trying to share the problem, not just share the solution. So you're saying by giving clear budgets and numbers to the sales team, you automatically lead them in a way to better prioritize for the best of the company? One tries to, yes. Sometimes this works, sometimes it doesn't. It obviously also depends a little bit on the stakeholders and how much they can also relate and understand what it means, like prioritizing in product or even estimating some topics. But so I think one thing that I also wanted to ask. curious when it comes to stakeholders or even executives in the company that have little to no product experience, like how do you recommend a product leader or even a single product manager to interact with those kind of people? Yeah, and it happens a lot everywhere. My first observation is those people aren't actually extremely interested in learning the details and the minutiae of product management, right? So if we think our job is to teach them all about what we do, make them respect us and like us, I'm not sure that's the goal. I think instead, I think we want to present what we do in ways that are meaningful and useful to them. So one of the things I often recommend is that every product manager, and this is pre-COVID and post-COVID, because it'll sound silly in the remote world, but to at all times have a printed copy of your roadmap in your notebook or your pocket or your backpack or wherever you carry things. So that when someone comes up to you as they do 41 times a day and say, there's this thing I need, I have a really good idea, can't we just, whatever, rather than saying, that's a stupid idea, go away, don't bother me again. First of all, we want to have some generosity in our hearts because they're approaching us because they think it's important and they want to share and they want to be smart about this, right? So rather than shooting them down, what I want to do is I want to take out the roadmap and I want to say, here are the three most important things we're doing this quarter. We're dramatically increasing back system headroom because we're going to double customer count, and we can't have the systems fall over. And we're opening up a new market by adding this new set of features and capabilities is going to make us a hundred million more dollars in the banking sector, right? And if I show them what we're doing, because of course they've either forgotten or don't know, now we're going to have a much more productive discussion, which is I can ask them where their idea would rank versus the things that are currently at the top of the backlog where we're in production. If we are six weeks away from shipping version six of some product that fixes a whole bunch of horrible issues and our 10,000 customers are going to stop calling us and start loving us because we got version six out the door, and that's going to put $80 million on the bottom line next year. If I name that thing and describe why it's important, then the person I'm talking to can often come to the conclusion that their thing is not as important. And then we can now talk about where in the backlog it goes or other ways to do it or other solutions, right? I didn't insult them by telling them it was a dumb idea. What I did was I compared it to the ones we chose at the top. And to most people, it's obvious that the things we're actually doing are pretty darn important and are probably much more important than whatever they brought forward. What about a product manager who is working with a, let's say, VP product who does not have the product background, which happened to me a couple of times, which is quite challenging. How would you deal with that as a, let's say, senior PM? Yeah, and this is hard. This is really hard. I think probably the number one reason why folks leave product management jobs, why senior folks quit and go to another company is because they're working for somebody who doesn't understand what they do, doesn't appreciate their thinking, can't see the inputs, outputs, and outcomes. By the way, this is just the same for designers. If you're a designer and you're working for somebody who doesn't understand design and thinks it's about coloring, you can't go somewhere else. If you're a senior engineer and you're working for somebody who thinks what you do is easy and is clueless, that's the number one. Here in the US, we call it turnover. Of course, in parts of Europe where turnover means revenue, we'd say employee churn or something else, but really hard. I think both for product managers and designers, my answer is to make sure you're setting up the problem before you show the solution. Problem we're having a lot of churn in our low-end customers, in our small to medium business market. I've done a bunch of analysis. I see that the top three reasons from all the surveys and interviews are poor onboarding and whatever the other things are. That's why I'm here with a plan to improve onboarding for our small to medium customers because connect the dots. If we can reduce the churn rate for small customers by 20% or 30%, that improves customer satisfaction and puts another $50 million on the top line. Notice what I've done instead of saying, we need to fix the user interface and the wizard. I've started with, what's the problem? Why is it important? Can I quantify the outcome if we do it right? Can I walk you through my thinking and logic? A good manager, even if they're not really strong on product, will eventually figure this out and start to see the pattern. Basically, I'm teaching them how to fish along the way. What about product VPs who come up with their own agenda and their own roadmap? There are these people who believe in their strong business goals and try to push things down. Sure. Again, let's take it apart. Sometimes they're right. Fair point. Right. I've been the VP of product with a team of product managers who are brand new and don't have good answers yet. If that's the case, I'm going to push much harder to get to the answers myself or to guide their thinking or to give them their goals. It's not always bad, but if you really are a strong individual contributor and you really do know how to do this and you've got good stuff, then this is a problem. You can't overrule the person who is your direct boss, but I think you owe them and yourself three or four tries to convince or sell or negotiate or explain before you give up. I think it's interesting because it's now also closing a little bit again the loop to what we said at the very beginning about CEOs and founders and how to deal with them. I think in the case of an executive product's role, is it the VP product of a company? You're dealing with the CEO and the CEO probably doesn't have the product experience. So I think all these examples are true for both the product manager who might have a challenging VP products as well as like the VP product who might be working with the CEO. Exactly right. So it's really a scope question there. I see really good individual contributor product managers having a lot of the same skills and talent as the product leader, but their scope down to one team, one product, one set of issues. It's a smaller scope. On the other hand, again, having been that VP more than a dozen times, I'm desperate to have a team working for me that can get many of the right answers themselves and tell me what they are because I can't possibly solve everyone's problem for them. And if I have a great team, which I hope every time I do, not always true, but often my job is much more traffic management and problem resolution and negotiating, assuming that my team is bringing me really good answers. Now sometimes I've done a thing previously, which means I have special knowledge or I've seen the pattern before. So it's not necessarily true that I'm going to take everyone's answers directly, but there I'm much more of a coach or a mentor because I'm trying to get everyone on my team to the place where they can come to the best answers and decisions they and their teams without me and I'm just keeping the traffic going. You also mentioned when we had our initial preparation call that after leaving these one-on-ones with the people you are coaching and mentoring, you have immediately content to talk or write about. So what are stories these days that are keeping you awake or busy? It's actually a joy for me. So I've been blogging since early 2002. If you count on your fingers, that's almost 20 years and it's really the dawn of blogs. I was doing some other formats before that. What's critical about that from my coaching, it is really the source of most of my writing. It's important that I anonymize it. So I will never put a real customer name in. I always change the segment. I always reposition it so that nobody can find the fingerprints of my clients on there. But I just put a piece up over the weekend called, it's about how product management can make development go faster and how product management can't make development go faster. Because something comes up, not every call, but certainly two-thirds of my coaching clients have this discussion with their CEOs and I have it all the time with CEOs where they say product management should make development more efficient. efficient. Development should be getting more done. And so product managers, you have to go make them do more work, right? Which is fundamentally wrong, but comes up all the time. And so we have to twist that around. We have to change it into how do we get the most value customer value, revenue value, whatever out of the work that the team has or can, can complete. So that's about sequencing and prioritization and smaller projects and not wasting time on things that don't matter. The other part of it though, is that I know that happier teams that are more motivated and better plugged into real end users work harder because they've internalized, they've, they've, they've started to love the end users and they work weekends and they work smarter because they are directly understanding the issues and the problems rather than letting me tell them what's broken. So I, I, and my team spent a lot of time, my product management, I spent a lot of time trying to get our development teams and designers connected directly to real end users so that we're all experiencing it. We're all doing better, right? So again, back to your question, the writing for me comes right out of the coaching sessions. How do, how do we get sales to sell the right thing? You know, how do we organize engineering teams so they're not tripping over each other? But also in addition, what you said, I believe it's per se very hard or the wrong way to start focusing on improving the work that others are doing. If you want to make your engineering team more efficient as a product manager, I think the best way you can do is by doing your job as good as possible and as good as you can. Because once you start making clear what the problems are and what kind of business goals you have and what the users are and you regularly talk to them, you will automatically dissolve 80% of the problems that common engineering team have, right? Because you have clear priority, you have a clear alignment, you have a clear goal and everyone can pull the rope into the right direction instead of, you know, going everywhere. I agree 196%. Damn, 4% missing. That's exactly right. And you know, that's about recognizing how we add value. What's our job? Deeply understanding customers, not just needs, but also their economics. So a fair number of product managers don't think about pricing and value in, in those terms, but our sales team has to go out and explain why a product's worth 50,000 euros, right? Whatever. And they better be doing that by showing the customer that the customer is going to save 300,000 euros, right? Otherwise they're not going to buy it. So, so we as product folks have to understand end user value and, and, you know, economic value. We have to pull our teams in to understand that. We have to do ruthless prioritization every single day. We have to frame up problems. I'm not sure that we always have to describe solutions. In a lot of cases, our, our maker teams are way smarter than we are. At least when I asked them, they told me that. And so sometimes I don't actually have the solution in mind. I bring the problem to the team and we get a better answer than I was going to come up with. And we have more buy-in and a better design. So, you know, those are the places where we as product folks add value. The other place we add a lot of value that's maybe not so obvious is ICS slowing down the rate of interrupts. So every single person in your company wants a thing, they want it done today. And if you don't say yes, they're going to go around you and go to the engineering team and demand it themselves. And almost none of those are important. Almost none of those are really high priority, but everyone believes their one item is important. So to the extent that I, as a product manager can hold back the chaos, if I can slow down the 75 requests this morning, that didn't matter, then my team can keep working on what's important. That doesn't make me popular by the way, but it's an essential ingredient to getting anything done. The Agilists have known for, even before we called them Agilists, we go all the way back to the 1970s, right? We know that the more we load on the team, the less we get done. And the more number one priorities we have, the less we'll complete. And so product managers have to hold back the stream of interrupts all day long so that their teams can finish something. Would you say that product managers are generally not very popular or in their nature, let's say? Yes. So it's easy to be a very negative point of view. What I'd say is good product managers are actually respected throughout the company as people who can get things done, as people who are clear and good communicators who know what the strategy is and are able to get things with the exception. So again, enterprise for me, I've never found an enterprise sales team that had a lot of great things to say and a lot of fan mail for the product management team. It's just in the nature of the incentive structure. We're often, you know, we're at cross purposes sometimes. So I see that the sales executives will appreciate and respect product managers. It's harder as you go down the org chart because those sales people are trying to do a thing that as a product manager, I'm actually not helping them with, which is to close some medium sized account that needs some crazy special thing. On the other hand, we can also say a sales team that is not very happy with product can be also a sign that the product team is doing a good job. Yeah. Hard to tell. Right. So, useful to know the only two States of the world for sales, right? We're ahead of our number. We're beating quota. We're going to get a big bonus this quarter. And we, by the way, we attribute that always as salespeople to the fact that we are great salespeople. Okay. So if things are going well, sales will generally accept the credit for themselves. And if things are not going well, it's either a product problem, a pricing problem, or a quality problem. Right? So it is. And, and, and, you know, I, I don't, I'm not jealous of the salespeople, even though they make twice what I make, because they're doing their job and it's not a job I'm good at. It's not the one I want to do. But I think if I contrast that for a moment with a B2C company, if I were selling, if I needed to sell 10 million Fitbits this quarter at $72 a piece, no one buyer of Fitbit is so important to me that I actually care whether we close one more unit or not, right? It's channels, it's volume. It's very numerically driven. We're going to be a numbers driven organization where we do a hundred million lead gens and close 10 million of those, whatever, right? In a B2C company, you don't really have this sort of push pull with sales because the sales folks are dealing in volume, which is the same way the product folks think. It's when we get to the, the lumpy large, you know, we're hunting whales or elephants, depending on your land versus sea preference here. You know, when, when a team is only going to close two deals this quarter and we might fire them if they don't close it, we should expect them to do every possible thing to convince the company that their deal is the one. Absolutely. Cool. Then Rich to slowly wrap up the conversation. One of our classic questions, if you have some key tips that you would have to give to a new product leader, let's say three main tips that everyone should keep in their mind, what would those tips be? I'd probably start with a really clear customer segmentation, right? So it's, it's easy for companies to chase deals or customers that aren't the ones we want. And that creates tremendous downstream confusion. And so to the extent that the new product leader is really clear about the groups that we sell to the segments, we sell to why it's important, you know, what they say, what we say and why they give us money. That's really, really important. And then to attach to that, because most of the folks in the company forget that, right? That's not what they think about. The second thing right behind that is when there's some major piece of work or an initiative or a new thing that's come up, we want to do the thumbnail business case. And that sounds fancy, but it's a two or three line spreadsheet with multiples, right? If this is an upgrade opportunity, look, we have 20,000 customers. We think 10% are going to upgrade and the, and the upgrade price is a thousand dollars. We can multiply and get to one digit. Forget the trailing digits. Is this a thousand dollar idea? Is this a hundred thousand dollar idea? Is this a $10 million idea? Because most of the things that come across aren't important enough to spend time on, but rather than telling people their ideas bad, I want to point out that it's not going to move the, the corporate metrics very much. And then, um, I guess I get one more here, right? Yep. I think I see a lot of organizations where the engineering or development team is not lined up against product management. So you have, you know, a resource pool and you just, you form up a new team every time you have a project. project or the there's a front end team and a back end team. And so nothing can be done without scheduling work in the front end team and the back end team, cause everything requires both. Maybe there's a separate data science team when I, when, or the product managers are cross hatched so that every product manager is lobbying the front end team for what they need. And now there's no way to have prioritization or, or order because the product managers are fighting against each other to get to the front of the line. So, so I, I, I really encourage new product leaders to look at how they've lined their product managers against the development teams and how the development teams are assigned. So we have long running value-based teams where we can have outcomes and OKRs. Great. Awesome. Makes a lot of sense. Well, that said, Rich, I think it was a pleasure for us to, to have you in the call, it was great to hear a lot of different stories and I think there was also some great advice also in it. I really love also that it was all very, let's say you get real numbers by talking to you, that makes it very helpful to understand. So thanks a lot for joining the show. It's my pleasure. Thanks for letting me join in and have some fun. Thank you very much, Rich. All right. Welcome back to our traditional debrief. This time, Christian, I'm happy to ask you about your highlights of the session. Well, one highlight was definitely talking to someone who has so much experience and worked with so many companies. You know what I loved the most about his experience? Tell me. Have you seen on the shelf in his background, he had like one of the very first like IMAX, I don't even know. No, I haven't seen that. Beautiful piece of, of wind dash computing, but anyway. What I really like is the way back to the fact that product management and sales do have some, some issues sometimes. And I actually really liked that he just highlighted that the pushiness from the sales team, the escalation to the C-level and also the ambitious goal setting and the aggressive selling that they're doing is something that is in B2B enterprise, a natural thing. And instead of always complaining about it, you just need to understand it's part of the game and based on that, changing your behavior and actions. That's one of the key takeaways for me. Looking back at my time at Newstore, I was also seeing and confronted with that many times, but back then I was too young to understand the pattern behind it. But I think it's also a good observation to acknowledge the way sales people think, and to understand, okay, I mean, when it comes to being popular in a company, it can be popular among everyone who actually benefits from the impact that your work has, and this might not always be the salesperson in this case. I think it's just like also cool to accept it and be like, okay, I know they work towards other targets. I might, they might not like the decisions that I have to take for the product overall, but in the end, that's my job. So. And Alex, you also need to bear in mind if you're able to buy every month a new Rolex, and then at some point you can't anymore for sure that pisses you off. Yeah, of course. So we're all doing our jobs. I think maybe a good closing for today. And as always, just one highlight, feel free to follow us on social media, as well as popping by to our new website, product-bakery.com. I just want to highlight again, our episode pages where we add a table of content, meeting minutes, and also enable you to interact with us and the speakers by adding comments, so we'd appreciate seeing you there as well. Awesome. Then everyone enjoy the day, the night and see you next week. Bye.