A (2:57)

So let's go a little deeper on that point. Many organizations will argue, especially long, large enterprises that have been in existence for a long time, on the surface, the results could be doing well. Stock price could be performing well. They're making revenue. You know, of course, every company wants more revenue and more profit.

B (3:13)

So.

A (3:13)

But in terms of understanding that there's a problem from an internal product technology organization, they may see opportunities to get better. But let's play me as a business leader. Say I'm, I don't know, head of operations, head of sales. I'm like, you know, my numbers are good, my bonus is looking good. Maybe explain to me why I should change or how you help me understand what really is the problem.

B (3:38)

Uncovering some of the core challenges in the organization. There are a lot of blind spots. Most organizations have a lot of blind spots. And just having a look at the patterns that we recognize and exposing those patterns to the executives, I think is something that's really helpful. You know, I even look at my own operational experience, and before I was going through a major transformation in one of the companies that I worked with. You know, revenue seemed to be doing just fine, right? Leaders were meeting their margin targets. But the problem that we were suffering from was we weren't actually able to drive the level of innovation that we could in the past. And that was really hurting us from a competitive perspective. And while our earnings seemed fine in the current quarter, or they were probably going to be okay for the year, we knew that if we couldn't drive that type of innovation in the organization consistently, it wasn't going to be a very good path forward for us. And so we needed to reskill and retool the organization so that we could future proof ourselves. And as an existing leader, you know, at the, at the time I was. Had the role, I was a vice president of product. Going in and helping those vice presidents or those executives understand that, hey, what worked for you in the past might actually not work for you in the future is a really scary thing to do because most people have reached that level in the organization because they have a few successes under their Belts, and they're used to doing things a certain way and telling them that the game's changed a little bit and you might need to think of a different approach for the future. That's scary, I think, for those individuals who are in those operational roles to hear that.

A (5:20)

Yeah, I mean, I want to role play with you soon because I want to play. One of the most common questions I get from either an individual contributor or a head of product is how do I convince my business leaders that we should transform? And. And, you know, you're kind of saying, hey, I was ahead of product, and I'm bringing this scary thing to my leaders to say, what got us here will not get us there. Maybe just role play from that lens. Pitch me as the, I don't know, head of sales, head of business unit, kind of, how would you sell this to me? Because I think it's just important to kind of hear it out in practice, recognizing what you've called out, the change, the fear. Maybe let's role play that a little bit.

B (6:01)

Yeah, I mean, one of the first questions I always ask a leader is, have you released a capability, a new feature, new product? Have you released it to the market and it didn't achieve the results that you expected? And pretty much universally, if you've been doing product a while, most people have experienced what that feels like, right. You came up with this great idea, you invested all of this money, you created this capability, you rolled it out, you got into the hands of customers, and it just kind of fell flat. Either you didn't get the level of adoption that you wanted, you might have sold a lot of it, but when it came to using it, the users, you know, maybe you're not getting the renewals or the level of usage that you want to see isn't actually happening. That is a reality in product. And then the follow on to that, I would say to you, Christian, is what if I could give you a formula that would help you mitigate that scenario? What if you could actually, before you roll a capability into the hands of customers, you could actually mitigate the risk in rolling out that capability? Would you be interested in hearing more about that? And I think it's, you know, once you pose it as, it's not a slight of the individual or the leader in place, but it's actually, there's a formula that great companies use to actually consistently deliver value for the customer and the business, it becomes a little bit more palatable for them to actually be open to hearing about that approach.

A (7:32)

We both do a Lot of work with large enterprises that are very frustrated, often with their investments in technology. Like, wow, we've got a hundred engineers. A small company with five engineers. Build something faster. I often see leadership teams when I talk about how painful, how long the opportunity cost of how they walk and how it reflects in their impatience. You know, I'm like, every way you've grown in the last 10 years has come from you buying a company. You know, every time you want something fast, you have to outsource it, you have to go outside the company or you create an innovation lab. I mean, all of these are indications for you that the way your engine is working today is not giving you the results you want. Maybe not as fast as you want, or maybe not the outcomes you want. So I can kind of see, I love that framing a whole lot of like, you know, how many things have we built that have not gotten you what you want? It's. I think every leader can kind of be like, yeah, but you mean we can prevent that in some ways. So when people ask you, leah, okay, I am, I am with you, but what am I transforming to? What do you tell them?

B (8:38)

That's when we introduce the product operating model, right? And so, like, as you know, there's three dimensions to the product operating model that are critical for a company. It's how you build software, right? This notion of doing small, frequent releases so that we can incrementally improve things. How you structure the engineering organization, that's one element of it. The other element is, you know, how you discover the right solution to the problem, right? And that, of course, is through product discovery. And we talk about that dimension a lot, especially when we're working with product teams and product creators, right? Doing the right level of experimentation and testing to make sure something's valuable, usable, feasible and viable. Of course we know that. And then the final area is choosing the right problem to solve and how we go about choosing the right problem to solve. When we're working with leaders or when I'm working with leaders, that tends to be the most important unlock for them because they, a lot of times are taking capabilities or ideas from key stakeholders in the organization and they're taking them at face value. And they're saying, okay, well, the go to market team or the sales team, you know, or the customer success team thinks that this is going to solve a particular problem. We'll just build that because the customer says that that's the capability that they want. And when we think of it in that term, and we don't do the right level of strategy and insight development and understanding what the problem is. And is this a problem that's scalable? Is this a problem that the majority of our customer base or a certain target market is facing? If we don't do that level of strategic work, will probably pick the wrong problem. And so working with that senior leader or that stakeholder and making sure that we're placing our bets appropriately is critical work. So I do a lot of work with companies on what I call strategy jump starts, because it's just a great way of getting, especially for those organizations where you have someone who owns a business that's separate from the product team, getting people in the same room to make those hard decisions and determine what's that prioritized list of problems to solve for this year is absolutely foundational and critical. And if you don't do that, you're going to generate a lot of waste. And you will probably be in that position where you're releasing capabilities to customers that no one really is using.

A (11:01)

Oh, I can't wait to go deep on that one. And I love kind of that framing of what you're trying to shift them to. You know, I typically will tell companies, well, we're going to shift from managing output to managing outcomes, from funding projects to funding people to solve problems, or, you know, from directing solutions to, you know, to empowering people to solve problems. And for, for me, a whole lot of it started to resonate with some of my enterprise companies because you always talk about we are big and at scale, you know, and I always say, well, you cannot scale control. That is very hard. You, you have to scale judgment. You know, how we decide what to do, how we solve the problems, and, you know, how we deliver those solutions. And I'm like, the product model is going to help you scale judgment. It's going to help you all the wisdom in your head as a smart leader, like, you know, how do you ensure that that gets into the products that we build? I like how you say there's a formula that these companies have used to figure it out. Have you seen any shift in your work, particularly now with AI and the trends in the market or industry that may accelerate a company's need to transform to the product model or create some kind of. As a catalyst or accelerant?

B (12:12)

Yeah, I mean, we're seeing that a lot of companies who have already adopted this way of working, adopting the product model, doing discovery, having a culture of experimentation where we try a lot of things, they are better equipped to actually take advantage of some of the capabilities that AI brings to the table. Right. They're able to experiment and test things more appropriately. They, they can get to a better solution faster. And that's both from a product creator perspective, but also from a product leader perspective. Like being able to partner with some of the AI tools to be able to come up and validate that these are the right problems to solve. I mean, you and I talk about this a lot. Like, I wish I had this. You know, it almost makes me want to get back into an operational role because things that used to take me weeks, if not months to do, I mean, we're doing in hours, if not minutes. So like again, aligning the organization with those insights and then being able to share those insights and then allowing the teams to actually query those insights is game changing. I mean, I think it just exponentially helps align the organization on a focused strategy more effectively.

A (13:26)

I have found for in many large enterprises, the AI conversation has actually brought a lot of technology leaders to the exact executive table. Companies that have always looked at technology as an expense, a cost center. Oh, we have another IT project. You know, for the first time, what tends to happen with AI is those business leaders are saying, well, there's this whole AI trend, AI things going on. Like, we're not really sure, how is it going to help us, where do we use it, what should we do? So they invite all the tech leaders, hey, come and tell us what is our AI strategy or our plan? Are we gonna make money or save things? And often many leaders go in and they try to answer the questions. And I'm always trying to coach many senior IT leaders or CTOs. I'm like, look, this is the common pattern. It will always happen with emerging technology. The fact that you had to be invited to the table, you know, is a demonstration of what needs to transform. You're kind of telling the leaders like, we need to be well equipped to leverage any emerging technology to solve our problem. This is why technology should always be at this table. It's an enabler. It's ha. We solve problems. And you know, and I always look at that trend and I always try to say, look, you know, AI is accelerating the invitation to important conversations for tech leaders. The difference is how do you ensure that you stay at that table and you're not just invited because it's something many people don't understand or are not using. I mean, and I'm sure the Internet did the same thing for many analog companies when they were like, what do we do? How do we Right. And now it's so normal place. So I really love that now. Leo, one of the questions many leaders quickly ask is around ROI or like, how do I know this is working? Or, you know, what am I really going to get if I do it this way? Maybe kind of tell us, you know, how you respond when they ask, you know, what's the return on changing?

B (15:22)

I mean, whenever we do that shift from output to outcomes, one of the most critical things that we need to do is we need to identify what success looks like and have a very clear picture of what success looks like. And for a leader who's pivoting from output to outcomes, that means making them understand that delivering something, releasing a capability is not successful. Right. Releasing a capability as a means to an end. And so really focusing those leaders on, define and more importantly, quantify what success looks like. All of a sudden they're like, what do you mean quantify? Like, okay, well, if. If at the end of the day you're going to be measured on revenue or margin or, you know, any kind of business metric, what are the predictive indicators of that business metric that you can tie directly back to the product team? So those predictive indicators now all of a sudden become the thing that aligns leadership and the product teams on, so that the team is focused on delivering those results, and it gives them the flexibility to try a lot of different things to actually achieve those results. But I feel like one of the biggest pivots is reframing that definition of success and then holding the leader accountable to defining and quantifying what that definition of success is. And the cool thing about that is now, instead of, you know, especially when we're doing annual planning and we're working with finance, working with the finance team, to basically map the business model to that quantified definition of success, it's actually better than just funding a feature or a capability. And it's a huge pivot, and it's a better way of aligning the organization to operate in the. In the product model.

A (17:14)

I like that a lot. And even back to your kind of original framing, you know, it's. Maybe the better question is, what's the cost of continuing to ship the wrong thing? What is the cost of launching a whole lot of features over time that don't actually do what you want it to do? And maybe, you know, the ROI is not faster delivery. The ROI is fewer wasted quarters. It's fewer political escalations and less burnout and better clarity on what we're doing. And maybe there's a risk of not changing because of how they started the conversation. I have been doing a lot for years and not getting a good return. So I really love that.

B (17:54)

Yeah. And I think it's even important for the product team, like most product teams, specifically the engineers on the teams, they want to know how they're contributing to the business and how they're contributing to customer success. It's not fun for people to build features and capabilities and not have anyone use them. Right. Like, part of the fun of product is you're actually creating something. And, like, once you create it, you put it into the hands of users and customers, and they use it. Like, that is why a lot of us get into product. And so if you can tie the work or the code that an engineer is writing back to the results for the user or the. Or the company, like, that's where the magic is. And that's going to create the type of product culture where people are focused on the impact and the results that they're trying to achieve, not just on the, you know, releasing capabilities.

A (18:48)

When I talk to executive teams, I always kind of tell them, it's like, I know a problem you're going to have every year, all the time. They're like, what do you mean? I said, I think you're going to want to grow revenue. They're like, you know, is there ever a year in your history you never want to grow revenue? Of course I'm like, I say, so who wakes up in your company every day to grow revenue? And they are thinking to themselves, you know, sales. They're like, well, sales just captures what we sell, the marketing markets, you know, like, who actually wakes up and says, my job is to grow revenue? And I say, if you think about it, growing revenue is not a project. Because after you've grown revenue this year, guess what you want to do next year? Grow revenue. And I say, so, like, the best companies have figured out that there are problems, sometimes persistent, that will always exist, like revenue or problems that their leaders deem important right now. And they have a group of people that wake up every day to discover new ways to solve that problem. You know, we call them fancy names, we call them product people. But, like, that is the whole essence of what you're trying to do. Because when you really think about the problems you have, there's a lot of waste. Because you think, I want to grow revenue. As a leader, you think of all the ideas in your head to grow revenue. And then you tell people what to do, and I tell them, like, you think you're big. What are you doing with your thousands of people? I say, just imagine if you could flip that around. You really want to grow revenue. You tell your thousands of people to discover ways to grow revenue. And your job now is to create the space for them to learn and experiment and test this out. And that for me is always clicking for leaders. I'm like, look, this model is just saying whatever you deem important. Have somebody wake up every day to solve that. And I want to help you understand what it means to create that environment. So I really love this, this conversation. Now let's shift our attention to companies that are actually doing this. The messy drama and politics that goes on in trying to transform. Maybe start by talking about where you see this falling apart. Where do they often just stall or fail or break when companies actually try to do this?

B (20:51)

Yeah, I mean, there's a lot of anti patterns to be sure for companies that are going through this. The biggest is we talk about it as product management theater, right? Where, you know, somehow when we're thinking about the product model, we think about certain creators, certain roles within the product model, and we get super excited. And, and I think product manager is probably where we've seen the most theater, where people are like, oh, well, the problem is we have product owners and what we need are product managers. So we'll go through and we'll change all the titles to product management and we'll be like, we're, we're good. You know, we've checked that box. I had this great product leader who talked to me about this, and he said, you know, that's a problem of installation, not adoption. He's like, what we're trying to drive in the organization is adoption. Right? Installation is a good example of just changing the title. But like, we have to grow the skills and develop the skills and coach the skills and make sure that we're not just changing titles, but we're actually developing that product sense with those product creators. So. So that's one pattern that is unfortunately, I think, quite common. I think the other thing is it's a cultural shift for a lot of organizations. And changing culture is hard, right? And that's where, when you talk about the messy middle, I think that's one of the hardest things to change. And it starts at the top, right? It starts about being declarative about what kind of product culture we want to create in the organization and what kind of product culture do we want to nurture in the organization and being really declarative about what we hold true from a values perspective. So that means giving the organization time to actually do experimentation and discovery. Right? So instead of handing features for teams to build or outputs, it's actually allowing the people, right? We spend a lot of time and money hiring the right people. Let's empower them to actually come up with the right solution to the problem. And that's, I think, especially hard for larger organizations where we've had people who have never seen what great looks like. That's messy, right? It's messy because, you know, if I've grown up through an. In an organization and I've never operated this way, and now all of a sudden I'm being put in a position where I have to not only operate this way, but I have to help the rest of the organization operate that way. That's. That's scary and there's a threat to that. So that's messy.

A (23:19)

You've probably seen this. I just had this recently from a ce, an executive. They're like, I want to walk this way. You know, this is my whole team. I've told them they want to work this way. And then you meet the individual contributors, the product teams. They're like, of course you want to work this way. And then the leaders is like, so why is it falling apart? I am the CEO and the leaders up here, we say we want this, the team wants it, so why is it not happening? You know, maybe say more about what you see happening between the intention and the desire of people to want to work this way and the reality of what it takes.

B (23:52)

Yeah, well, I think one of the key things in reality is what is the role of product leadership? And you know, when we talk about product leadership, we're not just talking about the leaders of product management, but we're talking about engineering leaders, product management leaders, design leaders, data leaders, even business leaders in the organization, they're called leaders for a specific reason and not managers. They have to have a point of view in terms of what the overall vision is, what the strategy is, how we structure the organization. And the biggest anti pattern that I see there is, it's being played more as a management role where it's bottoms up, right? So the anti pattern that I see as a product leader will say to all of the different teams, tell me everything that you're working on. And they'll take an inventory and they'll bring a list of all of the things that the teams are working on, and then they'll try to wrap a story around all of the work that's going to be taking place in the next year. And they'll create a product vis which is bottoms up. So it's basically just a list and an inventory of all the things that the teams are doing and they'll call it a day. And that's not what we're talking about at all. Being a strong product leader means gathering all of those insights, having a declarative view about where you want the future to be from your customer's perspective, making those hard calls in terms of priorities and really focusing in on the biggest, most important problems to solve and then communicating that out to the organization, structuring the organization so that you, I love what you said earlier. You're actually assigning those hard problems to people to drive that accountability. And you have a point of view of what success looks like if you, if you've achieved it. That's a very different role than just managing an organization and, you know, almost project managing it. So I think that pivot, if you don't have leaders who have operated that way or who have the core capabilities and willingness to step up and actually, you know, make a decision, leverage those insights, declare where we're going, it's going to be hard. It's going to be difficult for you to operate that way.

A (26:07)

Well, Leah, you're describing this product leadership muscle, and we've been on this for a long time. And I want to be empathetic to the reality of many leaders. You know, I'm an executive. I grew up in the in, and I've been in this company for 25 years. You know, I started here. I'm now the head of the business. I have been successful in the project model. I have been very good. You know, my former boss, you should tell me what to do. And I got promoted doing it. You know, I now tell people what to do, and my business has grown and has been successful. You are asking me to lead differently. Not with control, but with context. Not with fire and forget, but actively jumping in to, to coach, to provide clarity. These are muscles I have never practiced before. And I'm saying this because this is the reality of very many leaders. And you can imagine they will all have intention because if you ask them, do you believe in empowerment?

B (27:05)

Of course.

A (27:06)

Do you think that people solve problems? Of course you need to talk to customers, but they don't even know how their behaviors, words or actions may be hurt in this. So. So maybe explain to me how you might coach that. What alternatives exist? If this is my reality in an organization, to actually help any other leader Learn it or how do you address this?

B (27:28)

The two ways that I address it, at least with my clients, I do a lot of. And I know you do this as well as do the other partners, we do a lot of product leadership coaching, and it's more around helping the product leader understand one, why, why they need to develop these skills. Well, first admitting that they don't necessarily have them and they need to develop them, then helping them understand why they need to develop these skills, and then helping them. Part of the reason why I started doing the strategy jumpstarts that I was referencing earlier was it was a great way to actually coach the leader in real time so that we could actually model the behavior that we were trying to forward. And what was helpful about that was even being in the room with the product leader and asking the questions that we want them to ask was very helpful. For some of my product leaders to actually see not only what questions do we need to ask, but also how the team responds to those questions is almost more impactful because usually when we're not asking the right questions, we're not going to get the right information back. And so by mirroring that behavior, or at least modeling that behavior is what I'm trying to say, it's very, very helpful to get not only the leaders to understand the right questions to ask, but also have the teams understand this is what the interaction model looks like and this is what we're trying to replicate in the organization.

A (28:58)

I can't wait to go deeper on this strategy. Jumpshad, you're kind of giving me a really important topic that I think I want to break down more. I want to move a little from leaders to the creators and the people walking. Because one of the muscles we're trying to build in the product model is the discovery muscle. And I want us to be clear about the politics around this that we hear with companies like, okay, so you're telling me, okay, we want to do this discovery thing, but I still have commitments of things I need to deliver. I have mandatory regulatory things and compliance related things and business as usual things. How do you explain the balance between discovery and delivery, the role of discovery, the importance of it to a, to a leader?

B (29:42)

There was this great quote, like, discovery is all about making sure that you're building the right thing. It's not about building the product right. It's about making sure that we're, you're building the right product. And, you know, when you break that down for leaders to understand that, you know, the idea is only a small fraction of what we're working on. It's just helpful for them to understand. And again, I always bring it back to that first question that we were talking about, you know, when we first started talking today, which is, how many times have you released a capability that wasn't used to the extent or wasn't successful? You know, if you want to keep doing that, you can keep doing and working the way that you're working today. But if you actually want to drive value for the business and value for the customer, you're going to have to experiment, you're going to have to try some things out, because you probably don't know the answer in terms of what's the most effective way to solve that problem. And that's just the reality of what we're working with.

A (30:42)

I think when leaders ask me, you know, does discovery slow down delivery? I often say, well, discovery prevents you, to your point, from delivering the wrong thing. Skipping discovery doesn't save you time, it compounds waste. I often have to coach so many teams. Like, discovery is not like a phase in that way. It's the job. It's kind of it's your day job. Just like you don't say engineers in the coding phase of their work. You know, I want product managers and designers to see discovery as their work. You know, if you only have time to build, you, you will never compete. I like this new framing we're using on building to learn versus building to earn. This is a nice, safe place for you to learn, and that requires experimentation and testing. And then there's the place for operational excellence and for you to ensure that whatever you build works the way it works and it's performant and stable. So it's an interesting trade off in here. Now, one of the other areas kind of around this shift to empower teams is this idea of, I need to stop telling people what to go do or what to build, and I need to give them problems to solve. On the other end, you see the reality from many individual contributors talking about, I still get told what to do, I'm an order taker, maybe explain two aspects of it. On one end, you're trying to convince a leader that they are better served telling a team a problem to solve. On the other end, you're trying to coach an individual contributor on how to build trust so that somebody can give them a problem to solve and not tell them what to do. Explain how you manage those two dynamics.

B (32:18)

Yeah, I mean, on the creator side, it's going to go back to being inquisitive. And asking the right questions, right? So even when a stakeholder comes to a individual or a product team and tells them, I need you to build X asking the right questions, you know, and we joke around about, oh, the five whys. There's lots of, you know, you need to get to the what are we trying to accomplish and if we accomplish it, what does success look like? As a team member, you should be able to ask those questions. And this goes back to culture. Hopefully we're creating a culture where asking questions is permitted and encouraged in the organization. And you and I both know some organizations are better at that than others. But making sure that we understand the why behind everything, I think is really, really important. Now there are situations where we have to just do work, right? And you brought up regulatory reasons, compliance reasons. Those high integrity commitments are important for the organization. But what we need to do is we need to balance that work. You know, we have to balance the high integrity commitments with the keep the lights on work with any kind of technical debt that we're trying to alleviate with working on those problems. So it's not a, you know, one versus the other. It's an and situation where there's lots of different types of product work that we're doing before the things where we're really trying to focus on solving the problem. That's where we're empowering the teams to really come up with the best possible solution.

A (33:48)

We often argue the most important thing and product team can do for transformation is to deliver good outcomes. I've seen constantly, it's become easy to blame the leaders and we always talk about the role of leadership in it. But you can imagine I'm a P and L owner. I've got targets, I've got a number. You're asked to kind of give up control and trust. These people will help me get my outcome. And I think many people minimize the kind of exposure leaders have and risks they are taking in trying to extend trust, especially if it's unproven.

B (34:23)

The dynamic is different, right? Like in the project model, the way that you develop trust is, you know, you make a commitment to deliver something by a certain date and if the team delivers that thing by a certain, certain date, trust is established. I think in the product model it's a little bit different where the interaction between the product leader and the product team is, you know, are you doing the cheapest, fastest test possible to prove out an idea is worthy of building? What kind of experiment are you running? What's your measurement of success? Like the questions and the interaction model are different. In fact, there's more interaction and the conversations are less focused on did you do X? And more focused on how you did X, which is a little bit different. And so that also means that the product leader needs to be aligned on that definition of success. What the problem is to solve, what kind of discovery work is being done, what was tested with a particular user, what were the results? What was that next action? And so one of the ways that I coach product leaders on that is, you know, have those product reviews, have those design reviews, where you're really focused on building the team's skills around discovery versus measuring their status reports. Right. Like, who cares about status reports? Let's focus on making sure that the team it's. It goes back to like, coaching that judgment that you were talking about earlier. Make sure that you're scaling judgment in the organization. The only way you can do that is, is to help the teams understand how to do experimentation and testing and ask the right questions. It's a very different model than just taking a status report.

A (36:06)

There are many shifts, and I think many people also try to change everything at once. One of the big areas I hear concerns and I want to hear your thoughts on are like funding. Our funding is what drives a lot of our behavior. We fund a project, we fund an output, we fund the future, we fund that. If that doesn't change, we cannot transform. How do you respond to that?

B (36:29)

Yeah, I mean, I'm. I'm a big fan of funding the team and funding the outcome, so funding the team. So I love this idea of durability with the teams. But then fund the outcome. If you have a team and you have a finance partner that can track the outcomes back to what we're trying to achieve for the P and L, that's where those predictive indicators come in. It's incredibly helpful to change the funding model. I actually think it's an easier way to account for the work that's being done by the product team. Because even if you deliver a feature or you deliver on a particular project, there's no guarantee that that project is going to achieve any of the results that you think it will. But if you fund those predictive indicators and you fund the outcome, you have a better line of sight into what's actually happening in the organization, and you'll have more confidence that you're going achieve those success measures.

A (37:24)

It's kind of hard for many leaders mentally to say, okay, so how do I do that tactically? Like, what do you mean, what am I Funding what's on my P and L. Like, you know, am I funding revenue growth? Am I funding customer satisfaction? It sounds good, but is that really what you're asking me to do?

B (37:41)

Yeah, quite frankly. And I spend a lot of time, you know, when I'm working with leadership teams, finance, a lot of the time are in these sessions that we have. Most of the people that I speak to in finance, they get it. They're like, okay, this is actually fairly clean. Now for those large scale organizations who have been doing their accounting in a certain way for years and years and years, that's going to take more than one meeting with a finance team. You know, it's a lot of interaction and a lot of change, but it's a different way of thinking about the outcomes that we're trying to achieve in the organization.

A (38:15)

Okay, so Lee, you've done a lot of this. I kind of want to get a sense of a question, to get a sense of where you double down or where you gamble or place bets. I'm a big enterprise company. Your assessment tells me I have all the challenges, all of the issues you've talked about. I have two questions. One, what are one or two things that I should really focus on right now until I, you know, and address like immediately and where should I start?

B (38:44)

I'm a big fan and we promote this. A lot of using the product model to prove the product model. So setting up a pilot team, one or two pilot teams, you know, eight's probably not a good idea. But start small, right? Stack the deck in your favor. Make sure that you have the right people on the team who have skills, ideally someone who has operated this way before, it's incredibly helpful. And partner them with a leader in the organization who is going to support them in the way that they need support. They're going to be asking the right questions. They're going to be, you know, helping them develop that product sense. They're going to be, you know, really working with the teams to support them and give them space to discover the right solution to the problem that we're being tasked to solve. Start small and then let the results speak for themselves. They will come up with different ways of solving the problem that they weren't thinking about before and then allow them to operate that way. And then it's like running an AB test in the organization to prove out the model.

A (39:47)

Which battles should I not fight right now because it feels like everything is broken. You know, I don't have product managers, good designers, I'm not aligned. But like which ones, for political reasons should I ignore right now while focusing on this pilot?

B (40:02)

The reason why I like the pilot is because going to an organization, and especially that messy middle that you're talking about, going to an organization saying this is the new way that we're all going to be working, when you have not proven the model out and you don't have a success to go point to is really difficult. And that's a pattern that I've seen a lot of organizations, they believe in the product model and they want to move forward and they haven't proven it out in the organization and then the antibodies start to attack. I mean, how many times have you worked with an organization where the middle managers are like, this too shall pass. We did X last year, Y the year before, and all I have to do is just wait long and this too shall pass. Right. And they're kind of not wrong. Right. So if you have a pilot team and you actually prove it out and you have to have people who opt in. Right. I had one organization that where they set up a pilot team and the person that they identified as the product manager never done product management before. And they're like, I don't want to do this. You will not be successful. If you have people who don't want to work this way, stack the deck in your favor with people who are like so excited. And you know this, you know, usually there's two schools, there's people who love to work this way, and people are like, just tell me what to build. And you know, you should probably take the people who really want to work this way and who are excited and who have operated this way. Because if you've worked this way before, it's really hard for you to go back to the project model and be told what to do all the time and what to build.

A (41:45)

I love this a lot. All right, to wrap up this, I kind of want to hear just some quick fire thoughts on some of the objections I hear in people doing transformation or maybe the nuances. And if they have. If you see any one size at scale, you know, you kind of hear, Leah, would this work for a big company? How do you respond to that? Is that a yes, no, or why?

B (42:06)

Absolutely. It'll work for a big company as long as you invest the time in the product leaders, the strategic context, all of the things that you need to align the organization. But start small. So either you start with teams within a division, prove it out, and then you can replicate it further once you've proven out success and You've done the level of investment internally, right? I'm not saying outsourcing it to an external agency. You've done the work internally to actually make it successful and you have the right people in place.

A (42:41)

Okay, Leah, would this work in a regulated industry with compliance and mandates and stuff like that?

B (42:48)

Yeah, absolutely. I mean, I have seen it work in regulated industries with compliance. In fact, you're de risking everything prior to rolling it out. So it actually works better in those kinds of industries because you understand what the business viability is before you even get started. So you understand those constraints.

A (43:08)

I always actually say that's an argument for more discovery, not less. You know, you kind of think it is like you're actually advocating for more product management because you just can't do anything. You have to do things within your constraints. Leah, any difference between B2B versus B2C?

B (43:24)

No, I don't think there's any difference, really. I mean, the discovery techniques will be a little bit different. Whether you're B2B, B2C, B2B2C. It's going to be a little bit in terms of how you do discovery. Same holds true with platform products. It's going to be a little bit different, but the basic constructs are still the same. One objection that I hear a lot, especially for internal tools, is they have to use it. So it doesn't really matter, you know, if they're usable or not, because it's mandated that they use it. It's my biggest pet peeve because I, like you, should care even more because these are your colleagues who are using these products. Why should they have a subpar experience? If you make them more effective, the company's gonna thrive and you're gonna thrive.

A (44:05)

You know, it's why you have five tools doing the exact same thing in a company, because nobody actually solves the problem or solve for value. You know, it's like everybody went with what was the cheapest, another executive. It doesn't work for me. I want mine. And you see that in that way. All right, last question. Will this work if my CEO is not bought in?

B (44:24)

Well, this is where things break down. So usually, you know, and we know this, the company cares about what the leaders care about. And if the leader is delegating this, especially the CEO, is not bought in to this way of working, it's going to be hard because they are setting the culture for the organization and they're the one that everyone is going to look to. So it definitely helps when the CEO cares about it and wants to actually create an organization that thrives.

A (44:53)

I love that. Leah. This has been a lot of fun. I'm sure we could read for hours on all of this. I I do want to get you back to talk about these strategy jump stats, which you've kind of described as a way of getting some of that practice and modeling of the behaviors for leaders. But I cannot thank you enough for the gift of your time and the attention to this. What a fantastic episode. Thank you for being with us on Product Therapy.

B (45:15)

Always love spending time with you, Christian.

A (45:17)

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 (45:39)

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.