B (3:05)

So in order to win doubters over to your side is to show them that this new way of working is creating value. And that means that they need to understand what's in it for them, the intrinsic aspect. And if a doubter is from sales and marketing, you need to show them that you're going to increase sales, sales, and it's going to be easier to market the product in this new way of working. So it needs to fit into their reality, into their sphere. And if you forget about these stakeholders and if you do a transformation in a bubble, which is a common trap, one of the traps in the book, the transformation is going to fail because you need to win the hearts and minds of the organization that this new way of working is here to stay because it's better than it used to be. Transformation, as a word, is about transforming from one place, the status quo, into a new place. And that is a better place. And what does that mean for your organization? That means quicker time to value, happier teams, better business results, innovation, things that you're lacking currently in your product organization and an organization as a whole and connected to that. If you are serious about moving to the product model, you need to define the big why. Why are you transforming the purpose, the objectives, the vision of what that place is like, that we talked about? What's better than the status quo? What is that like? Because at the end of the day, you alluded to this earlier, Christian, why should I care? Why should I invest my time and energy moving to the product operating model? Because it's about energy. And you can sense that in some transformations where there's lack of energy, people don't want to move. They don't want to do things differently. And as a coach or as a CPO or CTO driving this change, you need to increase that energy. That means changing many things, because that's another trap, like, all right, we are just going to use okrs. That's the way we're going to move to the product operating model. We're just going to use okrs. That naivete of just like we're going to use a new tool, new technique, and that's going to drive all the changes. No, because you can't use okrs in isolation. You need to think about the entire ecosystem on how you create products.

A (5:34)

Let's go deep into this because you've, you've hit on some points that I think are important. One, I think it's the biggest misconceptions leaders have when they start this journey. They actually don't understand the true nature of transformation or they are not painting a picture of why we are making this change or what we're going to get by making this change. And many companies have transformation fatigue or change fatigue. Oh, my goodness, here goes another effort to try to promise us a better promised land. You know, if we hang on long enough, this one will come and go, this fad will pass, this leader's tenure will pass away, or they might get promoted to another department and I don't have to deal with it. You know, I want to start to go deep into some of these aspects here. Let's, let's start with one of the first anti patterns, which is giving teams the autonomy. Too soon. Many leaders here empower teams and they think the answer is, let's just step back and leave them into this. You know, that's what you want. You want to feel empowered? Fine, go be empowered. Maybe tell me why this often leads to chaos.

B (6:43)

Yes. And that quote, maybe a team says, yes, we're empowered, we can do whatever we want. What happens? Christian chaos. Right? You're empowered. You're given problems to solve rather than solutions to build. So that's a big thing. You're accountable to achieve outcomes. That's a big thing. That's new. Right. But what if you don't have the competency to solve those problems? You are not equipped, you don't have the skill sets to solve those problems. You need to be coached.

A (7:11)

You need to.

B (7:11)

You need to be mentored. You need to have the opportunity to solve those problems. And in some transformations, I see that you're just going all in. Or you're saying to the teams you're empowered now and you forget about the consequences. One of the key elements in the book is a loop called the loop of transformation failure. And it starts like this. The first step of the loop. Let's give teams the opportunity to innovate. Step one. Step two. Patience is a virtue. Right? And then the third step. Are we there yet? Step four. Houston, we have a problem. No results. And then the last step. Abort mission. Back to micromanagement. And then, yeah, the final step. Oh, crap. Micromanagement stifles innovation. And I've seen this loop manifest itself multiple times, and it's awkward to see what the root Cause is relating to the loop is that the coaches have failed. They failed to teach the teams about the new capabilities they need in order to succeed in solving problems. Leaders, they've stepped too far away from the teams. And then thirdly, the teams have failed. They haven't been transparent with what they're working on and the results of their actions. So to conclude, relating to the question, in order for you to create successful context for the teams, the new teams, the pilot teams that you've been talking about a lot in the podcast, for them to succeed in the product model, you need to ensure that they have the right coaching, the right mentoring, the right training in order to solve problems. And leaders, they need to give problems to solve to the teams that are not too big and not too small.

A (9:03)

When I coach teams around empowerment, I, I always talk about the true test of empowerment. And I say, look, first you have to have people with the right level of skills and the necessary range of skills. You know, you're, if you're choosing to play a sport, I don't know, basketball, you know, I like, I need shooters, defenders, like, I have the types of skills and the range of skills to play the sport. Two is I have to give them problems to solve, not features to build, you know, And I said three, it's up to them to come up with the best way to solve the problem. But more importantly, you measure them on solving the problem. They are accountable to results. When I try to explain to team empowerment doesn't mean that a team works on anything they can work on because I get people all the time. You told us we're empowered. Why are you telling us to work on revenue? I said, is this your company? Who do you work for? You work for a company. Empowerment means leaders are giving you the problem. Empowerment means they are leaving it up to you to solve the problem. Autonomy means you have as much as possible in terms of the things and the clarity of context and direction and the tools and to actually solve the problem. And you actually call out what high alignment and high autonomy actually look like in practice. What does that look like for you?

B (10:22)

So high alignment and high autonomy in practice, connected to what you just said is that leaders in the organization give good strategic context. So they have a product vision to have product strategy and then they have distilled that product strategy into objectives that could be okrs or metrics to move for the teams that connect to the bigger picture. And something I talk about in the book is the concept of the air sandwich. Picture this, you have a sandwich filled with air. So at the top you have clear vision and direction from the leadership and then at the bottom you have clear clarity on what we do day to day, what's in our backlog, what we're going to focus on for the next couple of weeks or next Sprint or so. But in the middle there might be a big question mark. That's the air. And the product model is a way to connect the dots between the bigger picture and the smaller picture. And in order for you to succeed in the product model, empowering teams, they need to understand their piece within the bigger picture and how that problem to solve that you've given them in the form of a team objective, connect to something bigger and greater. And revenue is relating to the financial impact of the organization. So companies are really good at talking about impact. Right. We're going to grow our revenue 10% this year or 30% or 50%. But the question is, okay, but how are we going to get there? What problems are we solving that strategy and then what are the trade offs we're making? So we're not going to do this. We're going to focus on this customer segment or this type of problem. So leadership is so important in the product model and that leaders have a way to articulate a clear strategic context that's simple to understand. That's storytelling. That's also winning the hearts and the minds of the teams to understand why they're solving a particular problem and then connected to that, the teams need to have the capabilities to solve those problems. And if you have those two parts of the equation, you're going to succeed.

A (12:30)

We used to call strategy the missing link. You kind of call it the air sandwich in some ways. You know, I always joke with companies all the time. You see a CEO comes out and says, these are my top three priorities this year. And then you look at backlog and you're like, why do I have 200 things? I thought the company only wants these three things. And you're like, how do I fit in to the bigger picture? Or what is important now and what is important next? Or what are we not doing ever?

B (12:56)

You need to create that connective tissue, that linkage. And also you alluded to this. It needs to be simple. I heard from one organization that they had 17 north stars. How can you make a decision of what's most important when you have 17 north stars?

A (13:11)

It is not a north star at that point, you know.

B (13:13)

Yeah. I mean looking at the sky, I can't only see one. Right. So this is an anti pattern as well. Right. The lack of clarity.

A (13:22)

You know, one of the other anti patterns you call out is quite common when people treat this transformation or this effort or in a bubble where they are focusing on the product organization alone, but not the whole system. You know, why is it so tempting for product and engineering leaders to just try and let's fix products without bringing the rest of the organization along?

B (13:43)

Yeah, because product is everything. It's what you sell, what you market, what you service. And if you forget about what's surrounding product and tech, then you're going to fail because ultimately everyone needs to be on board of this transformation. So I heard about this company. They did a transformation. It was within product and tech. They trained so many teams and created new strategic context and so on. But who wasn't part of the equation? The business, sales, marketing, customer service, they were like, what's going on over there in product and tech? They're not doing the stuff that's in the roadmap anymore. And then it creates this snowball effect over time. And in six months or maybe less than that, the, the transformation is going to explode. So you need to bring everybody on board and to say like, we're going to try this product model because we think it's going to be better for us as an organization. We're going to try it with some pilot teams to test and learn and to see how this fits within our culture and our organizational context. We're not going to go all in at the same time. We're going to decrease the risk of doing the wrong transformation. But we want to bring you in and to understand the purpose, the objectives and the transformation vision. And perhaps we want to co create some of these aspects together with you. So we have buy in that this is something that we're doing together. Because you hear product, operating model, the word product, you think, oh, it's just within product. No, it's, it's, it's going to cause the transformation to fail. If you just work in a bubble,

A (15:22)

people don't understand the impact on the whole business and what an organization has to change. You're changing how you make decisions, you're changing how you work or how you solve problems. I see teams so much. We've read the books. We don't do roadmaps anymore. We read the books. We're going to drive and just jump into customer solutions. We're going to restructure the team and then, you know, sales and marketing, they'll wake up one day or where's my roadmap? You know, what happened to my future? What happened to my stock? And you are making a change in an organization in terms of how you work without realizing the impact on many parts of your organization. It's why I often talk with CEOs about the company is going to care about what you care about, but it's important that you're championing this because we're going to change how we hire. We're looking for different skills and competencies now, so HR might be involved. We're going to sell how we create value, drive value, negotiate. The magic here is you're moving from a traditional subservient relationship to a collaborative one. And that's a big change. Now I want to ask this question, Mar what advice would you give leaders to build trust across the organization when shifting to this model? How do they go about bringing people along but also allowing them to trust them in this journey?

B (16:37)

Trust is about empathy. Trust is about understanding their perspective. So what's important for sales right now, what's important for marketing, what's important for customer service? And not to deny them a seat at the table, but to bring them in. It's as simple as having lunch or being in meetings with these folks because in big organizations you're quite siloed and you meet in leadership meetings and they could be really awkward. You're not comfortable speaking up, but with your peers in the business. So it's really about building relationships on the sidelines and to understand their needs and to co create and collaborate like we talked about.

A (17:16)

You know, one of the other insights I really liked about your writing and we kind of talk about the nature of building products, but is misunderstanding the work product teams actually do, you know, and you describe those three buckets of work creating new value or innovation in that way, improving an existing value or optimization. And this kind of keep the lights on work, business as usual, protecting the revenue. Why do many organizations underestimate this third category, which is, you know, keep the lights on business as usual, protect our revenue. Some people make it the ugly work of compliance requirements, mandatory work, regulatory work, operations work. You know, maybe talk about why people underestimate that and how leaders should balance these buckets.

B (18:07)

Realistically, it's about transparency and it's about collaborating between leaders and teams and to understand what's hindering them from creating value. And one thing that's happening in many organizations or in every organization, there's a lot of tech debt and dependencies and work that needs to be done to keep the lights on, as you said, and that work is Sometimes not transparent that it's underlying underneath the surface. And in order for you to be successful in the product model, you need to showcase the work. What are teams working on and do they have the opportunity to innovate? We talked about the three buckets. So the first bucket is new value. So tackling a new customer segment and a new problem to solve existing value is to work with the existing feature set and to improve that. And then the third bucket is protect value. So we need to focus on that in order to create value in the future. And that is compliance aspects, tech debt, bugs, operational things. And just connected to what we talked about earlier relating to pilot team. So if you're embarking on the product model, for transformation to the product model, you want to give the pilot teams the opportunity to create new value or improving existing value. And if they're swamped with protect value work that's not above the surface, you will have a dissonance and mismatch and expectation. So you need to set up these pilot teams for success. But connected to that in your product organization, in your roadmaps, you also need to surface the protect value work so sales, marketing, customer service and other stakeholders can understand why you need to do certain things in order to protect value so we can create new value in the future. And sometimes we don't connect the dots between that. So you need to quantify your tech debt. What's the cost of your tech debt? If the tech debt is affecting your time to market or time to value, show a number, show a figure on how that is hindering you from creating value.

A (20:15)

I often coach my teams. I say, look, my first rule of tech debt is that we talk about tech debt. You know, it's one of the unfortunate things in so many companies. They kind of hide their constraints, the challenges of their infrastructure, their architecture. You know, I always have to explain to leaders, you have to remember, whatever you build, you have to maintain. But more importantly, there's a cost of running a business. And to be very clear, the reason we coach a lot of value creation is because value protection is very easy for a business to do. When they grow, they lose out on the muscle of like, we had a vision, we went out and we created a cool product and now we're selling it. Now we're selling so well, we have to protect our revenue, protect our customers, protect our brand and our reputation. But I explain to teams all the time, it's, it's not a competition. We kind of get it wrong when we think there is some magical trade off. Of like, if I do the tech debt, I cannot innovate. Or if I innovate, it cannot do tech debt. And I tell people, okay, let's think about your household budget. How do you make a decision on should we watch Netflix or should we pay our power bill? Nobody argues in their house. Like, so, did we use all this power? What. What are we not going to do? You kind of understand the cost of living in your house, and you have this discretionary spend of, like, should we watch Netflix? Should we eat out today? What restaurant can we spend on? Or what can we do? And we want to. We exist in that bubble in our households of doing both of those things. You know, more discretionary spend, more the cost of the utilities. We are keeping the lights on. We are protecting what we have, making our home safe. We are paying our water bill. So it's a very good call out about the real. Having that understanding of the reality of what product teams do. They do all of these things, and it's a fantastic example. You called out dependencies and the impact on speed, and this feels brutal in practice, you know, being a hidden constraint. You know, you described this oh, crap moment when team hits, we want to build something, and they're like, oh, I need these 10 other teams. And I get it in many ways. People will tell me, but we are such a complex organization. Just to get anything out, I have to coordinate and work with 20 teams. You know, maybe tell me why dependencies can be damaging to product teams and maybe the common types of dependencies, you see?

B (22:38)

Yeah, I mean, dependencies is the root of all evil when it comes to slowness in product development. I've seen it firsthand so many times. So a team is all excited about this new prototype they put together in discovery. They tested it on customers. They feel like, wow, we're onto something here. And then they go into delivery and start coding, and then they're like, oh, crap. We're dependent on this system and this team and this and this and that. So it causes slowness, like tar in the product development way of working. And that is so damaging to a transformation to the product model because you want to show results. So it doesn't matter if you're really good at discovery, if you can't bring it to life. You need to tackle all three themes within transforming. So changing how you build, changing how you solve problems, and changing which problems you solve. And delivery, changing the way you build is fundamental, right? And dependencies and tech debt is so important to create the conditions for teams to work Successfully within delivery. You had a great analogy about household budget. Let me add another analogy. So you have a car, you want to reach a destination. That could be a vision. We want to go there, we want to go to LA from New York. And then you have a car and you have a steering wheel in that car, so you're going to steer that car to la. But if you have an engine that's not set up for you to reach the destination, it's not going to matter if you have that vision of going to la, because you're not going to have the vehicle to get there. And I think that connects well to what you just discussed, that if you have tech debt and you have a lot of dependencies, you don't have a visualization of what's happening underneath the surface, how your engine is operating, you're not going to reach that product vision or enable teams to work well with product discovery. Because here's an idea. So you work with product discovery, you're all excited and then things get slow. But what's step two and three and four from that? That's gonna decrease the trust and it's going to decrease the momentum and the transformation and it's going to lead to all kinds of bad stuff. So the doubters will start to move out of the dark and start to talk about, I'm not seeing anything happening here. We should focus on this thing in my roadmap instead. You know the stories.

A (24:58)

It's a question to ask leaders. Do you have the vehicle to accomplish your vision? And I think many people take that for granted. And to be clear, the vehicle is not. Just. It's actually, we call out a team topology issue. You know, it's like, are you optimized for the distance, for the drive, for all the friction for the road? You know, it's kind of, do you have the tires? Do you have the stuff together? It plays out because I often have to coach companies that you're currently optimized for your historical context than your strategic context, meaning, you know, you're kind of. Your whole setup, you know, is to optimize what you have kind of survival. But it's not designed to get you where you want to go. You've picked a spot on the past. Now going to thinking of setup and organizations. You call out this idea of when the head of product or the most senior product leader and the most senior engineering leader are misaligned. All have different agendas. I want to kind of talk about this one because it's a. It's a Big anti pattern and probably even just not only in product and engineering. But why is the relationship between a head of product and a head of engineering so pivotal for a transformation? And what signals do you look for to say this is healthy or this is not?

B (26:12)

It's so pivotal because connected to what we just talked about, it's regarding the steering wheel, the product vision, the product strategy and the engine and the vehicle. So that's the technology. So these two folks are responsible for connecting, to reach the destination together. And sometimes you have an elephant in the room or many elephants in the room regarding the driving forces behind why they want to move to the product model. So maybe underneath the surface, the CTO just wants to tackle tech debt, but doesn't really care about the product vision or strategy, just cares about engineering. And then the CPO has a vision and a strategy, but just wants to still work with their previous kind of or existing leadership principles relating to. I'm just going to give the teams things to build that I think are great. So you're cosplaying the product model. You're using the product model as a vehicle to drive your own agenda. What I've experienced coaching CPOs and CTOs or senior product leaders and senior tech leaders, is that there's misalignment. They're not talking about the fundamental driving forces, why they want to transform. They picked up a book or they watched a YouTube video or something like that, they're all excited and then they just want to shoehorn that into what they want their own agenda.

A (27:38)

This is an interesting one. I can almost talk about the dynamic of the relationship between a head of product and a head of engineering being foundational for how teams work together because they model the collaboration. But I love how you're calling out the alignment. You know, you might have a vision, we want to go to la, we might have a strategy, we know the routes we're going to take, but if the vehicle is not set up well, we run into problems. We might have a good vehicle that can go 500 miles an hour, but it is directionless, it is rudderless, it doesn't work well. But the, the underarching point I always try to coach many of these teams is there is nothing like a product management goal and there is nothing like an engineering goal. There's only a product team's goal. We don't have separate agendas. The vehicle does not just wake up and decide like we are going to accomplish anything by ourselves that are meaningful and so does the vision without the vehicle. And to the extent that I try to get them to understand an engineering goal is a product team goal. A business goal is a product team goal is an engineering goal. We plan together, we present together, we measure together. We are all accountable for outcomes. You know, the tech debt thing you have, I always say, if my product manager cannot pitch tech debt like a strong business initiative with, like an engineer, we've missed the mark because they don't have an understanding of the vehicle they are trying to use to get to the destination. And also, if an engineer is so disconnected from what the business wants, what the customer wants, we are also losing sight of, of why we created the vehicle in the first place. You know, you started by talking about one of the biggest things you see is the trap of losing momentum through a transformation and that dynamic between the believers and the doubters. You know, what should leaders do when they sense they are going into this valley of despair phase that you call it? You know, like, oh, my goodness, it's been going on for so long, and what should they do?

B (29:37)

Yeah, so the value of despair comes from the Dunning Kruger effect. You can see a visual if you Google it. So it's a connection between competence and confidence. So in the beginning of a transformation, there's high confidence we're going to do this, it's going to be great. And then it slumps over time. And then you come to a moment like, can we really do this? As soon as you press the button in the transformation, the clock starts ticking and the doubters will be in the background lurking, watching. They want to see, okay, is this creating value or not? I'm not believing, and we talked about this in the beginning of the podcast, that the number one thing you can do in a transformation to win doubters over is to show results. Right. It's not just about financial results, but it's about results that the teams are working in a new way. They're experimenting, they're using data, they're talking differently, they're engaging with stakeholders differently. So it doesn't need to be just black and white results or no results. There are a lot of facets into the word results. And at the end of the day, the doubters need to connect what's happening to their context, that they're selling better or they're servicing better or they're marketing better, or the leadership team has higher trust in the product organization. The currency is trust in a transformation.

A (31:03)

That's right. That is well put. The currency is trust. And, you know, whether it's a full bank of trust an empty bank of trust. The idea is that you're winning hearts and minds. But I've always found, even in the transformations that I have led, that you're just earning enough trust, meaning you're putting enough in the bank to be able to withdraw the trust for the next thing you're doing. And we say the most important thing you can do for a transformation is to deliver results or outcomes. And I think many people underestimate what this is about. And I often, often try to remind companies because I try to dispel that they are transforming to a thing they've never done before. And I kind of remind companies like, look, every time you've actually done something meaningful, innovated, solved a problem, delighted a customer, a lot of the transformational principles were at play. You know, there was clarity, there was focus, there was ownership. People work together. A lot of the principles were at play. But it was something that happened in a peak, you know, under pressure, sometime in a bubble somewhere. And what you're really transforming to is making this a muscle or a behavior or a principle that happens in most places, in most times, in most situations. And once you start to understand this, you're like, remember that time we did a great win, you know, three years ago, four years ago. I want to prove that we can do that consistently and I want to be able to tell us how we did it. I tell people, move away from the theory. This is not an exercise in like, let me prototype, let me test what it could look like and stuff. You need to figure out how to prove that. Empowering people with people to solve, with problems to solve, giving them context, clarity, coaching, guidance, having them discover a solution that customers love and works for your business is actually good for you. No, not say it. It sounds good on paper. We talk the talk, you know, but the demonstrating, proving it out in your company is what creates that momentum. Because once I see it, I'm like, that happened here. Maybe I can do it. I am a believer. The best transformation stories are not the ones from outside. They're the ones from your company. We've seen your constraints.

B (33:13)

That is the most powerful thing. The inside stories, the case studies, teams showing data, talking to customers, engaging differently. And that spreads like wildfire. And that's why I'm such a big proponent of what I call discovery demos. So before, you might have had a lot of delivery demos showcasing the work that's done, the plans, the executional aspect. But when moving to the product model, showcase the discovery work, have demos for discovery, because that's Going to win doubters over, because that's going to show results, that you're doing things differently, it's leading to happier customers, is leading to more experiments, and so on. But I wanted to talk about another thing relating to losing momentum. And you have this gravitational force in a transformation. So you have the project model of focusing on output plans, predictability, and so on. And then you have the product model focusing on outcomes, strategic context, discovery, and so on. And in a transformation, you always have this gravitational force going back to the previous way of working, the project model. And that gravitational force is connected to stress. So when you're stressed, you go back to the old way of working, and stress connects to lack of control, lack of understanding. And if you as a product leader listening to this conversation, what you can do in order to address this gravitational force is to paint a picture, share the stories, what's being different, and to create more control, make them more confident that this new way of working is beneficial. So think about the gravitational force, and

A (34:53)

it's probably one of the most important things you call out. And probably the last point you had called out about leadership behavior. Many leaders will talk about empowerment, but to your point, when they are stressed, when pressure hits, they revert back to control. And I often have to coach people. I'm like, look, this is a muscle. You've seen people In a company 20 years, 30 years, you grew up in the project model. You know how to run an organization with requirements, with specifics, with delivery. You know how to whip projects into shape and optimize for cost and budget and scope. And now you're saying, I do what? Am I losing control? Am I giving up that? What do I do instead? And many leaders, they demand certainty. They want predictability. You know, they might even say they trust their teams. But. But they're like, no, I'm still gonna tell you what to do, because at least I know I will get something. You know, maybe as we end here, just think about, how do leaders make that shift from directing their teams to coaching their teams? How do they make that shift from I care about the date and a roadmap and an output to I'm gonna work with you to get an outcome and remove obstacles in your way.

B (36:01)

So leaders need to lead differently, like you say. I mean, and they need to get out of the comfort zone. They need to lead in a different way. And what that means is that they need to lead with context rather than control. They need to paint the picture, tell the story about where we're going as a company. And as a product. And they need to win the hearts and minds that we talked about that this is the way. And please, these are some problems to solve. Dear teams, can you help us solve these problems and to coach them relating to their competency to solve those problems. Because they might not be accustomed to product discovery. So be close to them, teach them some discovery techniques. If they don't have access to data, give them data. If they don't have access to customers, give them access to customers. Open doors, be that coach on the sidelines. You're not on the playing field anymore, you're on the sidelines. So you need to nudge them in the right direction. That's what leadership in the product model is about. And it's easier said than done because. Because like you said, we've been accustomed to lead in a certain way for 20 years or 30 years and now we're going to discard that. No, keep that build on top of that. You have good product sense, you've talked to thousands of customers, you've been in this business for a long time. But distill that into something that you can coach so you can share what you know and to spread that knowledge to the teams. Because in the product model, you. You're unleashing the brain power in the organization from a few brains coming up with solutions to build to many brains and also AIs coming up with solutions. Right. And you have this magnificent, marvelous ecosystem of ideas and innovation if you just unlock that. But in order for teams to run in the right direction and to drive in the direction that you want, you need to nudge them, you need to stay close to them, you need to see what they're working on and then to be there on the sidelines to coach them, to tell them, oh, you need to run faster, you need to run slower, whatever it is. Right. If, if you're using this coaching analogy.

A (38:07)

Do you know, Marcus, one of the things I appreciated when I was reading your book was that you don't try to romanticize transformation. You, you kind of show that the journey is messy, it's full of tension, it's full of doubt, it's full of learning. When you were thinking about all of these anti patterns, was there anyone that scared you the most? Like, you know which one stood out to you? Like, man, if this goes unchecked, could cause the most damage to a company.

B (38:32)

Yeah, I mean, the most damage is embarking on a transformation to the product model without having a purpose of that transformation. Meaning that there's no alignment on the big why on the outcomes, on the transformation vision. Because then you're going to have dissonance. Nobody's going to understand why this matters, and that's going to trickle down and to affect the entire transformation. I think a good analogy when relating to a transformation could be to think about startups. So Christian or I, we have a great startup idea and we come up with an idea in the shower. The idea is 1% of the work. The 99% of the work is the hard stuff. The prototyping, talking to customers, testing, learning, raising money, building an organization, hiring. Transformation is the same. The idea of a transformation, that's the easy part. But you need to make sure that you're willing to do the work of setting up teams for success, aligning with stakeholders that they need to lead differently, you need to talk about strategy differently, you need to work with strategy differently, and so on. So Marty talks about the word serious. Are you serious? Quite a few companies I've helped over the course of my career have been serious when moving to the product model. They've understood that it's a hard path to take, it's not an easy path. But unfortunately, the transformations that haven't reached success have been the ones that haven't been serious, that have thought of this being an easy path.

A (40:11)

Yeah, the transmission theater, the, the commitment, the absence of a vision, the lack of understanding of your. Why? Because there's nothing for you to reach back in to revive that energy if you don't have the vision. Like, why were we doing this in the first place? Whether that's the fear of competitive threats, the frustration with how things have been, the opportunity with AI, the opportunity to get better results. I always tell companies you're either going to inspire a movement or incite a riot in your environment if you're not serious about it, you know, and you call out this perseverance around it. You know, Marcus, this has been a fantastic conversation. I'm sure we could spend hours on this topic, you know, and I love that we want to good at it. This is not just about adopting new practices. You know, you really kind of call out how to avoid the traps that actually derail real change in a company. And it's important that people recognize that this is a real change in culture, a real change in mindset. We frame it as in how you build, test and measure, in how you make decisions or how you solve problems. But all of these are still changes. And, you know, the, the, the reality about it is that these things affect humans. And at the core of it. There are many things in our human behavior, in our resistance to change, in our politics, in our company, in our organizations that we need to be cognizant about. And you know, you've really done an amazing job of trying to capture some of those.

B (41:36)

Thank you. Thank you. And what I fundamentally believe and why I wake up in the morning and help my companies or the clients is because I believe. I believe, and I've seen firsthand companies moving through the product model and that the teams become happier, the organization increases innovation, it creates business results, it creates better outcomes for the company. So yeah, love chatting with you, Christian.

A (42:00)

People ask me all the time, why are you so passionate about product and product management and the product model? And I said, you know, good products come from great product teams that come from great product people working together, ordinary people. If I can get you working in a product model which is an empowered, problem solving way, you know what comes out of it. A good product, A good product solves a problem in the world and something that creates meaning, creates meaning, creates value and purpose. So absolutely. I love your passion, your energy for this subject. Thank you for being a guest today and I look forward to another conversation soon. Thanks Marcus.

B (42:37)

Thank you Christian.

A (42:38)

Want to learn more? Until next time, Please check out svpg.com, sign up for our newsletter that Mary Kagan puts out. Join us for one of our workshops near you and get access to all of the articles and content we put out. And thank you to everyone for joining us. Until next time, have a good day.

C (43:00)

A Quick Disclaimer While this podcast is named Product Therapy, it is not hosted by licensed therapists or mental health professionals and it is in no way a substitute for professional mental health services. We recognize the importance of mental well being and encourage anyone facing personal difficulties to seek support from qualified professionals. See www.findahelpline.com.