Coaching Stakeholders

Welcome back to Product Therapy. In this episode, we go beyond coaching product teams and look at the other half of the equation, coaching stakeholders. I'm joined today by my good friend and SVPG partner, Chris Jones, to explore how you bring the business into a true product operating model. We're talking how do you engage stakeholders like your executives, finance, sales, operations, compliance in the work we're doing? Because we know that without your buying and understanding, and power teams will still get blocked. Chris, as always, welcome back to Product Therapy. Good to see you, Christian. Thank you. Feels like it's been a little while since we've done this, so looking forward to this one. And what a fantastic topic to really start the year on, talking about stakeholders. And, you know, I have often struggled for people to kind of understand the importance of stakeholders in their work, who are stakeholders, why they matter in the work we do of building products or solving problems. Why don't we start there? Why do stakeholders matter? How would you define them? And why is it critical to the product model that we would have this conversation? Yeah, great. Good place to start. So, broadly speaking, when we at SVPG, as you know, and we engage with companies, there's really kind of two big universes. There is the broader product organization. So that's all the, you know, the product managers, the engineers, the designers, maybe some other roles might fit into that broader product organization. Those are the ones who we've traditionally thought about as doing the actual product creation, the actual building. And then there's kind of everybody else, right? And, you know, particularly the more senior people within the organization who, you know, have historically expected things from the product organization. So, you know, to tighten up the definition, you're a stakeholder if you're not directly in that product organization, but still very reliant on that group to create technology solutions that might, you know, support your business needs. So it might be some operating unit, you know, within the business where you actually have P&L or operational responsibilities. It might be some, you know, kind of support function. Maybe there's a field support team, I guess, you know, that kind of fits into that first category as well. There might be some, you know, sort of general administration group that has, you know, its own set of constraints and concerns, you know, things like finance or legal or things like that. But, you know, all the people that I've mentioned can be very, very concerned with what happens in the product organization, but they're not actually directly a part of that product organization. I think you're framing an important point that product teams don't exist in isolation. You know, they live within an environment, an ecosystem, and, you know, salespeople have quarters, they have legal constraints, they have customer commitments, they have brand risk, revenue targets. And intentionally or not, solving a problem of building a product within a company kind of requires all these pieces coming together. Chris, there's this undertone in many environments about stakeholders feeling like the enemy in some ways. Give me a sense of why this is a common pulse of people. Almost, they say, the relationships, oh, stakeholders, I've got to bring my stakeholders along. I have to work with stakeholders. There's never this excitement that sounds, yay, stakeholders. Where do you think that's coming from? You know, I think, you know, obviously we talk a lot about the product model and all the principles within the product model. And then there's kind of how you've been operating. And typically, I think they're, you know, in those prior models, in those more waterfall-ish models or feature team oriented models or project team, you know, project models, however you just, you know, want to describe it. So there is a bit of an animosity, and it comes from the fact that the product organization is there to serve the business. You know, the business and the stakeholders have their needs, they have their requirements, and they expect them to be fulfilled. So there is a natural, you know, sort of status that's implied by that. There's a frustration because they need all these impossible things from us, but they're not being clear on what they need. And then they're angry at us because we don't deliver, you know, something that they said that they needed. This is all a direct byproduct of just, you know, kind of how those prior models are set up. In the product model, obviously, it's a very different sort of relationship. And it's because the teams are empowered. Those teams are, you know, it's their responsibility to actually figure out the solutions. And when that happens, they necessarily need to actually look to the stakeholders more as partners here. because whatever solutions these teams come up with, they actually have to work for the business. So, you know, I'm always about bringing, when I talk about operating models, I really try and bring it around to incentives. You know, what sorts of incentives are created by an operating model? And there is not an incentive in the project model for deep partnership between the product organization and the business. In the product model, there is a very, very strong incentive for that. So, you know, it's a lot easier to not look at them as the enemy. I love how you're framing this and I want to break it down kind of clearly in how you define what's going on here and what's driving that animosity because on one end, the dynamic in the project model is this subservient relationship model where this team of people, project teams or delivery teams or future teams exist to serve the business. So, you know, when companies start to probably make the shift where you say, well, we exist to serve our customers in ways that work for the business, maybe some of that animosity is coming because, you know, you're feeling this conflict internally between who is my master and who am I taking direction for or why do I exist? And so it feels like your stakeholders are getting in the way of you serving your customers because you are probably still making project demands, future demands, business requests. So maybe some of this is driven by how a company works and, you know, the old thinking of why does a product team exist in an organization? I think you're calling out the important definition of they exist to serve customers in ways that work for your business. You know, maybe I kind of want to understand before we kind of break down better ways of doing this, what does healthy look like? Like when a stakeholder relationship is healthy, how do you know when it's working? Maybe start by doing some anchoring of this is what good looks like in an environment. And I want to kind of understand the dynamics behind that. Yeah, I mean, fundamentally, in the product model, as you said, you know, the empowered teams are there to serve the customers in ways that work for the business. So, you know, the business and the stakeholders are absolutely tied to what it means for a solution to be viable. So what this means is that the stakeholders fundamentally are very comfortable working in a currency or a canvas of outcomes. They are able to communicate to teams the work they need done more around outcomes and a lot less around solutions. And that more than anything is going to facilitate the sort of collaboration that we're talking about. So, you know, I'd say that is kind of the most important thing if you were to dial it back to just a single thing. But some other things that would really help identify it as being healthy is they are, you know, the stakeholders are very free with sharing the context. They really want to ensure that the teams genuinely understand what the business constraints are, what the needs of the business are actually going to be. So they're comfortable with that. They understand that the teams need that. They're very good about sharing those sorts of things. The other really big piece is this realization that for the empowered teams to truly do their job, they are ultimately going to need direct access to the source, right? And that source might be the customers or users who are ultimately being served. You know, in traditional models, that's hard. You know, the stakeholders see that as solely their responsibility and they don't actually want the teams to, you know, to have access. They don't trust the teams to have that sort of access. In healthy, you know, when it's looking really good, the stakeholders are really facilitating that sort of direct access. And similarly, the data, right, any sort of data that stakeholders are using to, you know, to manage their own business, things work a lot better when there is, you know, unencumbered, you know, intermediated access, you know, direct access to the data is very, very useful. Now, everything that I just described, those three things, right? Communicating in outcomes, sharing business context, and providing access to data and customers. That is what great looks like. Of course, transformations can't flip that stuff on. There's a lot of stuff that needs to happen in order to enable that. But that is the vision of where we're trying to get in terms of our relationship with stakeholders. I want to go deep into this. I wanted to kind of start with what the world looks like in a good place, because you're describing an environment where everyone is aligned on outcomes, not outputs. Stakeholders are giving you problems to solve. You're designing, they are sharing context and constraints, not just their requests. They're getting access to customers, access to data. They are getting out of your way. You know, I used to tell my teammates like, hey, you know, they're telling you what destination matters for them, but they're not teaching you how to drive. And they're kind of trusting you to drive. But Chris, I mean, this is not how it looks in many companies. I mean, many people think their stakeholders are unreasonable. But truly, many stakeholders also feel like they've been borrowed in the past. So they fall back to several patterns in here. Maybe tell me now that we kind of know what a healthy dynamic looks like, what do stakeholders actually need from their product teams? You know, what do they, what things do they want from us to keep this healthy dynamic? You, you know, Christian, have been all about helping teams realize that, you know, trust is a big part of all of this happening. And especially at the start of a transformation. You know, if we if we have historically been a product organization that just takes requests and serves those requests, there is very little reason for the stakeholders to trust that we can actually come up with better solutions. We've never been asked to. We've never demonstrated that we can. And, you know, our stakeholders have not seen that from us. So it is a very tall ask to say, OK, from here on out, stop communicating in solutions and start communicating in problems and give us direct access to customers. I mean, that's crazy, right? You know, if I were a stakeholder and I'd never seen any evidence that the team can actually make those sorts of decisions and actually treat those relationships with responsibility, I'm not going to trust them. So, you know, the first order of business for the product organization is to get its own house in order. You know, it does need to raise, you know, it needs to level up. And in some cases, that might involve training. In some cases, it may involve new people right there. You know, some people may in the existing product organization may not actually have the capacity to operate this way. So the first thing that has to happen is building trust with those stakeholders. And they are not just going to get that by saying, hey, look, they've been trained and they've been up. Like they're going to have to, you know, the product organization is going to actually have to demonstrate that they can get those sorts of results. So, you know, that's really first and foremost why this is a hard thing. And really, you know, if you are somebody who is currently in the product organization and you want to work this way and you're frustrated with your stakeholders, you have to realize that the first step needs to be taken by the product organization. And it's a big step, right? We have to actually earn that trust. It's such an important point. I was talking to a CEO and I asked the CEO, I said, okay, what's the most important thing you're working on or project or tax you want to get done? And he called out his initiative. And I said, who do you go to first to go get this done? You know, and he called my senior vice president of operations. She's fantastic at this. And I said, why? He said, why? I said, why did you go to her? And he said, well, she understands the business. She knows how to get things done. She knows how to move the pieces. She has all the relationships with the right person. I just know if I give this to her, she will get this done. And I said to him, well, that's a product manager. He said, no, that's my SVP of operations. I said, well, imagine if you had somebody like that on every team. You are trusting that person with the context of your problem and trusting them to figure out a solution better than them. And there are many people in the company that have demonstrated they can do something with the problem and get better results. But you're calling out, I think, a very important point. It's like, in many cases, teams have just not earned the trust, you know, because they haven't demonstrated that they can come up with a solution even better than the stakeholder. You know, now, Chris, you've written a lot about stakeholders needing to share business context, share constraints, share go-to market requirements, share what they are thinking and all of the things in the bit. Maybe say a little about why you think that is critical and what is the best way a stakeholder can actually share that with the product team? Yeah, well, so why it's critical, you know, it goes back again to the point of teams being empowered. You know, when they're empowered, they are the ones who are responsible for actually conceiving of the solutions. In the prior model, they've never really been asked to come up with those solutions or, you know, only on the margins might they actually be, you know, figuring that sort of thing out. And what that means is the things they're being asked to build, the teams are not responsible for ensuring that it's viable for the business. That responsibility is held by whoever it is who's asking them to build something, right? The business asked us to build this. It must be viable We don have to think about that right That essentially what going on In the product model that is entirely inverted because you given the team a problem to solve The team is coming up with the solution. They now have to assume responsibility for this actually working for the business. And the only way they can get the information about what that means is to be engaging deeply with the stakeholders. The stakeholders hold all that context. This is what I need for my business. This is what I need in order to be compliant with regulations. This is what we need to be consistent with the contractual partnership obligations that we have. If the teams don't have this information, they are, you know, bound or doomed to be thinking up solutions that may not actually ever work for the business. So that's the first, that's kind of why this is so important and why, you know, stakeholders play a huge role on this. But, you know, in terms of how that gets done, mileage is going to vary, you know, on that. It's going to depend on the particular product managers or product leaders. It's going to depend on the particular stakeholders. In some cases, it may be conversations where they sit down and share this sort of thing. In most cases, you know, the product teams, there's a lot available to them before they go and bug a stakeholder. You know, they can be consulting the, let's say it's a particular regulatory situation. You know, I may be working on a product and, you know, I've got a, it's in a very tricky regulated environment. And I know I need to consider the constraints of a particular stakeholder, say, in the legal or compliance organization who really is, you know, understands this. Like, I should read those regulations or at least have ChatGPT summarize them for me. So I should ask it, you know, what types of things are my, you know, is my general counsel going to be really concerned with as far as the product is, you know. you can get foundational information now easier than you ever have been able to. And then ultimately you have those conversations with the people, you know, around the edges of the things that you weren't able to figure out. Chris, I want to talk through two dynamics here and I want to hear your thoughts on them. The first is stakeholders assuming you know, you know, in the idea like, I'm going to tell you to do this and I'm going to assume, I mean, you've been here, you know, three years, I'm going to assume you have the same context I do, and I'm not going to do the work, or it's too much work to take the time to pass on everything I know to you. You should know this too. Or are we not in the same company? You should have the same lens. Or I spoke to a customer, I can't believe you don't know this. Maybe tell me how you coach a stakeholder through that thinking. And also the other side of that dynamic is a product person as kind of being vulnerable to kind of say, I need this context, may make me appear like I didn't do my homework or I don't understand stuff or, you know, this feels to be this interesting dynamic where there's silence and nothing is shared, you know? You're in a meeting, you didn't ask a question, I told you about something, I'm assuming because you wanted to appear smart, you know it, or you are, you know, you feel like it's unsafe to say things like, I'm not sure, I don't know, can I get clarity? Can you tell me more? Talk a little about this. I mean, that's a very specific case. And, you know, generally speaking on those, I usually treat those case by case. But let's go through some of the foundational things here. This could be happening because the stakeholder has reason not to trust this particular, you know, maybe there's a history. Maybe there's just sort of a demonstrated pattern of not doing homework. And, you know, as in that particular case, you know, that the responsibility is really going to fall on the person in the product organization. That, look, there is a lot more in terms of homework, in terms of background that you could be bringing to these conversations in order to be building trust with this particular stakeholder. So let's assume that's not the case. Let's assume that it really is a stakeholder who is kind of digging in. And, you know, one reason that this might be happening is that stakeholder has a little bit of, you know, animosity, hostility toward the product model because they see it as a threat, right? They see this product manager as a threat. This person may be coming in to take my job away. Or, you know, if they're doing all this and they're going to be the acknowledged expert on the customer, you know, who am I? So, you know, in those cases, really, this is, you know, some conversations with the stakeholder to help them realize that they are going to be far better off by having a real partner here on the technology organization. And the main reason is that the technology organization is going to know things that are possible that the stakeholder will never know, you know, just what the technology is capable of. understanding that the product model is not about them. You know, it's not about inverting the power relationship. It is about actually having genuine collaboration and having a real partner here. Selling that stakeholder on the benefits of having somebody who's on the hook with them for generating a particular outcome. So there are a lot of benefits here to the stakeholders. It's not just that they are not losing. They are actually gaining from this. Also, you know, I mean, so just tactically, you know, I'm talking sort of the theory and kind of, you know, what the benefits are here. Typically, when I'm really, you know, coaching these people, it's easy to look at 10 examples of how the current working relationship is failing. and specifically it's failing in terms of what's getting built or what's not getting built and continually pointing to those and saying, look, you see this? This failed here. Let's say everybody was sure that this feature was the most important thing and we saw customers asking for it and all of this. So we spent two months and we put this out there and nobody's actually adopting it. What happened, right? You know, and that is a perfect example of a failure of an operating model. And then talking to that stakeholder about, look, this is how it could be. This is how it really should be in terms of how this stuff operates. So, yeah, just bringing in some examples are often helpful in this, you know, in this type of coaching relationship. To the extent that you're coaching a stakeholder not to assume the teams have all the context to make a good decision or even a better decision than they would. You know, I always teach my teams the framing of, I want to make sure we succeed at doing this. Like that is how you introduce yourself to the stakeholders. I want to make sure we do a good job at this. I want to make sure I can give my team as much clarity about what good looks like. So I need, you know, kind of more for you about the context, the constraints, the aspects in there. You know, I think that's, you know, an interesting part around this dynamic. I do want to call out one other common thing we hear from stakeholders, or at least product teams bring up, that stakeholders do. And hear your thoughts around this. This is the because I said so type of response, you know? Because, you know, oh, we need to understand the why. And then a product manager says, so why should we do this? You know, and because I said so can come in the form of it's my budget. It's what my business wants. It's what my leaders want. But, you know, in some ways, I've always thought it's very hard for stakeholders or leaders to give to their teams what they don't have. Sometimes because I said so, maybe I don't know the context myself or it was handed down to me. Maybe tell me how you respond if I'm a product person and I said, hey, why are we doing this? So I'm seeking for context. And that was the response I got. So I kind of think there are three reasons why you might get this because I said so. you know, sort of answer. And we've sort of talked around a couple of them. You know, one of them is they don't trust the team and they just can't be bothered, you know. And as I said before, there's a lot of work to be done on the, you know, the product organizational side. The second is that they are threatened by this model and, you know, they don't want to go to this particular place. And we just talked about that one, you know, a bit, you know, what it really means here and helping them understand, you know, the value of the product model. The third one is that they don't know, right? That they genuinely are not doing their own job and they really don't know. One way to come at all of this is to ask questions that are a little bit less lofty, right? You know, help me understand the business context. It's really kind of hard to bite in there, right? That's a very abstract sort of question. I mean, it's very similar too. It's like, OK, I hear the solution. Tell me the problem. I mean, that just sounds kind of stop it. Right. I can imagine a stakeholder getting annoyed by by things like that. It sounds a little too pure and perfect and not practical. but you know i think some some much more practical ways to meet a stakeholder where they are are to just to ask the questions like okay i hear you you want this thing you know we need this feature how do we know that we've actually solved the problem you know beyond shipping this on a particular like what what's something we can look at to say that good has happened as a result of this uh another way is to is to sort of do the counterfactual like if we don't build this feature What problem kind of still exists out there? What is actually still going to be true? And those are a lot less threatening, I think, as questions. And I think what they do is they signal to the stakeholder that you're meeting them where they are. You are accepting what it is they're asking you to do. You're just looking for a little bit of clarification. And this may be a route into getting the context that we need. What you're communicating to them at this point is, yeah, I get it. I'm on board. We're going to do this. We want to ensure, though, that what we do is actually going to be effective in the way that you need it to be effective. So that's a way, it's a less generic way of kind of vectoring into getting that context. You're calling out the importance of context in doing a job, all the dynamics that are blockers to this, but tactically how a product person can go get context even when a stakeholder is not forthcoming and a very practical technique in doing that. You kind of gave great examples in doing this. You're calling out the lack of understanding of the model could be a big piece. I want to kind of understand how we educate stakeholders on the model. Because for many, this is a change. And when there's a change, you're asking the questions, what's in it for me? What's going to happen to me? You know, I think the dynamics I have personally seen that you can kind of call them out are, if I give the team the freedom, I'm going to lose control. How do I know I'm going to get what I want? You know, if I'm not in the weeds of this stuff, if I'm not specific about what we want it to not get done. And maybe the accountability question, well, what happens if it does get us gone, it's still my business, you know? So talk to me about how do you educate your stakeholders on the model and what's changing, what's not changing and why we need that trust. I'll kind of take two, there's sort of two big factors. You know, the first one is, personally, I think the word empowerment, it's a great word, but it also does us a disservice because it's so big and feel good and warm. And I think it's very easy both for product teams and for stakeholders to overhear what empowerment actually means. I think there's this false understanding that empowerment means teams get to do what they want. And there are real limits to empowerment. And in particular, stakeholders are not giving up what problems need to be solved, right? That is something that is still going to be very much in their domain. Now, there's a lot of nuance behind that as well, you know, when we get into how we decide what problems to work on. But, you know, at least at the early stages of this, they still own the problems, right? Teams don't get to solve the problems that they want to solve. So there's not really a giving up total control there. And that's the first thing. But more tangibly, like when teams are working through solutions, what needs to happen, teams need to understand this as well, is that they don't go off and sequester themselves for two quarters and then kind of work up this and then come and present it to a stakeholder. I think that's what people are often used to. What's happening is they are trying lots and lots of ideas very, very quickly, and they are prototyping these ideas. There's stuff to look at. There's stuff to react to. and especially in cases where, you know, it requires deep partnership with the stakeholder, that stakeholder should be seeing these things, you know, on a regular basis. You know, it depends on the stakeholder. It depends on the, you know, the specific thing that's being worked out, but there should be really regular, lightweight check-ins on what the team is actually going through. And these should be moments where a stakeholder can weigh in and say, hey, okay, I see what you're trying to do here. interesting idea, but you're kind of running up against something that we really haven't communicated to you in terms of the business context. And this is why we can't go here. So yeah, those two things, you're not giving up entire control. You still have a lot to say about the problems that are being solved, but you're also not giving up entire control on the solutions either because there's going to be a lot of intermediate things that you can react to. kind of writing out in my head on one end, you're making clear you still own the problems. That is your role in this kind of stuff. And you're also calling out that empowerment equals accountability in some ways. You're actually going to be able to hold people accountable because if you gave them a roadmap or a future and it didn't work, you are accountable. But if you gave them the problem, you're kind of holding, they are becoming accountable to the outcomes. You actually even calling out better outcomes happen this way because we have more prototypes, more ideas. You know, when I try to talk to executives about flipping the model around, I'm saying in many companies, just the leaders are doing all the thinking. We have a problem. Okay, do this, my idea. And, you know, if you have a thousand leaders, great, maybe a thousand great ideas. But, you know, what you're flipping around is saying our job is to be very clear about the problem And imagine if we had a 5 person company thinking about solving the problem and our job is to provide context clarity space for testing and experimentation But you also call out the speed of innovation starts to accelerate when you do it. So I love this. I'm educating them on the model by one, taking away that mental threat of you're losing control, telling them the benefits of what they will get with accountability, space of innovation. I think this is really fantastic framing. Now, Chris, does this differ when you're coaching the most senior executives in a company? Do they need something different? And when you think about hierarchy of stakeholders, what are those big shifts? Because you hear teams say, oh, we are trying to work in the product model or we feel empowered, but the CFO still requested a roadmap or compliance sent us a future request. Like what are some of these dynamics that may need to change at the highest level to kind of help this model work? So different types of stakeholders definitely, you know, will kind of have different challenges for sure. You know, the main thing, and this is actually something we haven't really spoken about yet in this, but the main thing I find with the executives, you know, when you're engaging with executives on this, is it actually has to do with focus. You know, how many things can we actually be doing simultaneously? And is there enough of a strategy here that is actually limiting and focusing these teams? So that's probably the thing I come in contact with most when we're talking about those executives. You know, in terms of, you know, sort of like the business operations folks, you know, most of the coaching there really has to do with getting to root problems versus a parade of solutions and, you know, all of that. It's really, you know, kind of getting that, you know, that orientation, you know, that orientation there. With finance, it's so often around something else that we haven't really spoken about. And that's like, how is work funded? You know, how do we actually account for it? And, you know, the finance people are typically, you know, oriented around project funding and, you know, kind of how do we get them oriented around the product and team funding? Okay, Chris, let's play on that one because that's probably one of the most common ones is we still fund projects, we still fund roadmaps, we still fund deliverables, even if they're saying our way of working has changed. Help us in this shift. How do you educate a finance department, a CFO? How do they shift models? What are they shifting to? What is the alternative to funding a project in that way? You know, this is a recurring theme on this podcast, but, you know, when you are transforming, really getting away from the idea that we're doing everything everywhere all at once. So we've got lots of projects that are funded via projects and organized around all of that. Don't try and do a wholesale change of the model and everything that is currently in flight and all of that. You know, we've got to do it in a few pilot areas first so that you can see, you know, the benefits of doing this. And what we are changing to is usually some combination of funding a set of teams and, you know, giving those teams outcomes. So what the finance person, you know, it's like, what do I get for what I'm spending? You know, what you're getting are these outcomes. You know, we are going to be investing in a way that allows us to deliver X, Y, Z that should be very, very significant for you in finance. This is what we'd like you to get behind. And as opposed to, you know, holding us accountable for these specific project deliverables. Instead, we need you to hold us accountable for delivering a particular outcome. So that's really what it is. you switch it from output to outcome and you start small. And, you know, you basically then have the ability to allow them to compare and contrast, you know, to effectively A, B test. And, you know, at the end of the day, you got to make it work, right? If you can't make it work, then there is no justification for all of this. But this is so intuitively good, right? I mean, A finance person should understand that buying an outcome is way, way better than buying output that has no guaranteed outcome. So paying for things that way should feel intuitively obvious. We've just got to demonstrate that it works. What does the paperwork look like? I'm a finance person. What am I writing in? I'm funding a 20% increase in revenue. You know, and is that kind of how what am I presenting to my board about where I'm spending my money? I was funding the Project X before. I mean, it's precisely that, right? I mean, it sounds big and scary because it's so different, but it really is that simple, you know, and revenue, you know, revenue is obviously a tricky one. There's a lot that goes into revenue. And, you know, maybe you are going to fund, you know, a particular revenue lift. Maybe there's something else, though, that is still, you know, very directly related to the business. Maybe it's growth within a certain segment, you know, things like that. There might be some key metric that, you know, your business is trying to shift, for example, value delivery from one more physical channel to one more digital channel. And, you know, we are going to sign up for moving that a certain number of percentage points. And this is what we need in order to do it. And, you know, that's that is exactly that is exactly what it looks like. You know, I think there are two dynamics I've found to work very well. I remember my last operational job when the CFO, you know, I had to have a meeting with him and, you know, they were funding projects. And I asked him, I said, what do you get when you fund a project? He's like, well, I get my project. I said, well, is that what always happens? He said, well, sometimes it comes in late, comes in over budget, other project fails. But, you know, it's like, you know, what's the alternative? And I said, well, let's do a test. I want you to fund some people to solve a problem. and let me see how many projects I can give you at the end of the year. You know, it's like same budget, you know, for Project X and same budget for people to solve the problem you want. And, you know, it took us a year for him to count. He's like, I got eight projects from that. Like they tried eight things in that year. More importantly, though, I got eight things that worked, right? Because in the past, you know, I might've gotten eight projects or six projects or whatever it is, but, you know, half of them or more than half of them really didn't deliver, you know, on the thing that I needed. So that is the fundamental difference. It's a big, big shift. You know, you've called out finance. I think it's a big piece. I want to call out another type of stakeholder dynamic and hear your thoughts around this. These ones you tend to see in either regulated or large enterprise companies, you know, whether it's compliance or legal or those mandated things where someone says to you, I mean, Chris, they're just things we have to do. You know, the regulator, oh, got this, we got a fine for this. Our customer, you know, our biggest customer requested this and it's then, you know, half of our revenue. We have to do this. Why do I need to give you, you know, anything besides go do this right now? And this is a project or a task. It's because there are often more than one way to get something done. And, you know, the particular way that you're asking the product organization to do this may not be the best. It may not be the most effective. What you're actually looking to do may not actually solve the problem that you think you have. What we need is for you to bring us into your universe enough so that we're accountable for the actual problem that you're trying to solve so that we can ensure that the solution actually is going to work. At the end of the day, all those things that you described are context. And let's also be really clear, like there are a certain universe of things that just need to be done, right? And, you know, we do, the product model does allow for, you know, we call it keep the lights on work. You know, these are just the it's the regular stuff that is just going to have to happen. You know, some critical fix or, you know, some, you know, adjusting to deal with changes in a regulation or just kind of the details of compliance. You know, it's just sort of the day to day stuff that that, you know, obviously we do need to get done. We don't have to frame that all up as problems. Right. We don't have to do a bunch. or in some cases, even any discovery on that, right? That constant buzz is always going to be there. And teams, we trust them to have the judgment to know what that stuff is and to make sure that it's getting dealt with. Now, of course, you have to be careful on that. I mean, if you do find that most of your teams are drowning in keep the lights on work, then there's probably some intervention that needs to happen. Are we defining keep the lights on work the right way? Are we actually adequately funding these teams so that we can make the true advances that we need to make? But that sort of stuff is still a part of the picture. Chris, you said something that I think is very important for many people to understand because we use that word context. and many people think it's templatized. There's some direct definition of what goes into context and how context must be laid out for it to be context. But to the extent that you're calling out context is passing on everything you know or everything that you believe is needed for a team to make the right decision about what they need. I remember talking with the team, I must do this as a security audit. They must get this done. And I said, are you suggesting to me that if you showed your team the security audit report, and they saw all of these reds, that they will not be like, you know what, let's not work on that. Let's work on something else. Or I was dealing with a big media company, and there was a client that was going to pull like $8 million from their platform if they didn't fix something. And the leader is like, I don't need to tell them that. They just need to fix it. I said, just imagine you told them, hey, we are at risk of losing an $8 million client on this platform. Are you suggesting they will not say this is something important we should do? And now we understand why we should do it. So I really love that you call that out. I do think you did the back to the dynamic of trust you kind of highlighted. Is it a people thing? Do I trust you? Do I trust your judgment? You're bringing up something else that I think is equally important here, and it's that the teams have a pride of ownership. You know, whatever the teams are actually responsible for, if they're not feeling deep pain and embarrassment and frustration about these sorts of things that the stakeholders are also feeling, then those teams are mercenaries, right? They're just doing what the stakeholder is. You haven't, as a product organization, you have not adequately transformed. So I think the way you put it is exactly right to the stakeholder. It's like, look, if you care about this stakeholder and your team doesn't, then yeah, I don't blame you for not trusting them. That's not good. You know, the product organization hasn't done its job in creating, you know, genuine areas of ownership and staffing teams with people who care deeply about the success of their respect, you know, their particular products. So when it's working well, stakeholder, you have a partner in this, right? They are probably more concerned about it than you are. We started a conversation earlier where you talked about what healthy looks like. You know, healthy means we're sharing context, sharing constraints. There's access to customers, access to data. Everybody's aligned on outcomes. We are truly collaborating. I want to make sure we highlight what unhealthy looks like. Like what happens when your stakeholders are not aligned on the product model, when stakeholders are not coached? What do you tend to see in an environment that calls out to you very clearly? There is a broken stakeholder misalignment, poor understanding of the product model in a company. You know, one of the things you see is, you know, they might pay lip service to outcomes, but they're still feeding these teams roadmaps. That's probably the most common thing. And by the way, I don't want to treat them as fully malicious on that. It's kind of what they know, right? And it's, you know, and they're feeling these things really deeply. So there is usually a period where that's all happening. And it's incumbent on everybody to, you know, to continue to ask those sorts of questions. You know, it's like, what happens if we don't do this? What, you know, if we do do it, how are we going to know that it's actually been successful? So ensuring that you're bringing this stuff in. But that is one of the main ways that, and probably the most significant way, is that you see lip service to problems, but you still see them bringing in a lot of solutions. If I see a product team confused, if I see them overcommitted or reactive to everything, sometimes it's really a team problem. It's probably a stakeholder alignment problem when that happens. But one of the big things I was writing down that I, I don't know if you've heard that term of like a shadow roadmap. You've seen companies or these back channel commitments and, you know. They keep these private lists of features that they're expecting, you know, regardless of any pre-agreed upon OKRs or objectives. They do a nice lip service like you got this other thing we're working about, but they are handing teams this shadow roadmap. maybe we can end just kind of making sure there are not examples here of stakeholder pushback or objections that you think are important to this, you know, and maybe in one word or few words, just kind of tell me how you respond. You've kind of, we've already talked about some already, but like, we can't do this model. What do you say? Someone is like, this is, we're too big for something like this. This is not an Amazon and Google thing or something. I got a couple I can give you that we haven't really spoken about. One is we need predictability, right? You're telling me this, you know, I don't see dates in here. Roadmaps made me really comfortable because we would have that predictability that we could then, you know, express to customers or express to vendors or express to partners and ensure that we get everything together. So that very real right I mean that is of course the business does need predictability in order to operate But I give you a couple of different approaches on this One is do you need predictable output or do you need predictable outcomes And putting predictability around the outcomes versus pretending that we can predict which features are actually going to work, that's the predictability that we want to sign up for. Now, all that said, some things need a date, right? And this is another thing that the product model does account for. You know, these are what we call them high integrity commitments. You know, in the case of a roadmap, everything gets a date and everything gets a date very early. And what the product model says is that sometimes we need dates and we will actually carve out, you know, those things that do need dates. We're going to use that judiciously and really, you know, preserve it for the cases where we really need an output tied to a date. But we're also going to ensure that we do enough product discovery before we make that commitment so that we can actually be very confident that, you know, not only will we be able to ship it at this date, but it's actually going to deliver. We've validated that it's going to do the things that it needs to do. So that's how it kind of answered that objection. You know, predictability, we want predictability in outcomes. And also, yes, things can get dates. We just have to be careful not to put everything through that, right? You know, roadmaps try to create the optics of, you know, everything having a date. So that's one common objection. Another common objection is, this just sounds slower, right? You know, you're telling me about all this product discovery and what I'm imagining is this big phase where we're doing all this experimentation. Where do we plug that in? I see how the teams are already strapped. And so, you know, it's a very obvious kind of objection to have. Unfortunately, the whole frame of it is wrong. You know, the frame of that objection is basically, you know, somebody who is standing in a project model and trying to layer product discovery in, you know, sort of add product discovery to what is fundamentally the project model. So really what you have to realize in the product model is that this is not zero sum, right? What happens with discovery is it allows us to decide how to best apply our limited resources. We actually build more things that work, but we build, you know, ideally fewer total things, you know, so we are actually getting a lot more signal early on. And it's not just binary. It's like, OK, we're not going to build that because of discovery. What's really happening is we're doing all of our iteration of what the solution needs to be within a canvas that's a lot faster and a lot cheaper. So what happens is things become much, much faster. We're able to actually get the stuff that works figured out a lot more quickly and aim our very expensive, limited delivery resources toward things that we know are going to work. I love this. Okay, wait. I was writing down all the very pointed responses you've given today to some of those objections because I said so, you know, it's I need a date. I need predictability. Have we talked about size? like, you know, we are too big for and too complex or for an organization for something like this? You know, how do you respond to that one? There are just some proof points out there. I mean, there are a couple of companies out there that are, you know, sort of traditional, traditional tech companies that are much larger than most of the companies out there. So I usually come at that one empirically and just say, hey, look, are you bigger than Amazon? Are you bigger, you know, than, you know, Google? But, I mean, you still have to acknowledge that bigger companies are complex and there are, you know, complexities in terms of relationships of teams and how the leadership, you know, organization is structured. So, you know, I don't want to dismiss it and, you know, and just throw it away. It is harder, you know, for there's no question about it. And really bringing that one back to pilot teams is the way to start to digest that. You know, people do get very wrapped around the axle when they hear this model. and they imagine a wholesale shift within an entire company, an entire enterprise, or even an entire business unit, that's not going to succeed. You can't do that. But what you can do is carve out a small piece and begin working there and then build on that success into more and more of the organization. All right, let's pick on two more examples because, I mean, you've given a lot here. We've talked about control and the trust dynamic. Like maybe a little more on planning because I've heard that one. Like we need to lock in features for planning or, you know, I need to, how do I know what to prepare if it's all this discovery, like forever? And, you know, what do I plan for? I'll go back to that argument about predictability because planning and predictability are very similar, right? There is, you know, planning for outcomes and then there are the specific things, you know, the specific solutions that you do need to have predictability on. And that's where we have those high integrity commitments. So I also think that it is helpful. This is just a tactic. When teams try and get very pure and say, OK, we're only going to be talking about outcomes and we're going to do discovery and leave us alone until we think like that's not going to work. Right. That is that's not a way to partner with stakeholders. That's not a way to build trust. And, you know, we are trying lots of things so that people can see that there are real tangible solutions that are being tried. And, you know, this is this is just a small tactic as well. When I'm communicating, say, you know, the outcomes that we're going to be committing to, you know, sometimes it makes sense to just include some candidate ideas, you know, that just call them candidates. don't say here's a roadmap and here are the features, but here's some things that are under consideration. Just so you know, I'm going to communicate to you, stakeholder, we're not just in this kumbaya outcome space. We actually have some real ideas, some things that we think might work, but we have not validated them yet. We have not done adequate discovery around them. So more to come on this. We're going to be showing you prototypes. We're going to be giving you the insights that we get from product discovery. So, you know, I think just to kind of circle back to that whole objection, you know, planning, I need to know what to plan for. What is going to create that objection is a product organization that says, leave us alone while we figure this out, right? That is not the way to do it. You know, they need to be very public about the things that they're trying, you know, and they need to do it in a way that doesn't give up empowerment. But you are signaling a lot about what could be coming, you know, when you're having those regular touches with the stakeholders. And you're calling out something that addresses that black hole that many stakeholders talk about. Oh, the product team is just like a black hole. Ideas go to die there. I don't know the status of anything or when things are coming. If you are in the product organization and you are finding yourself wanting to say, leave us alone, give us a month, you are creating that black hole. And that is going to hamper your ability to be trusted by the stakeholders and to develop a genuine partnership with those stakeholders. I mean, visibility and transparency are very interesting. And people are always concerned about how much of a degree of transparency I might tell in the stakeholder. What if this doesn't work? Are they really going to give us space for discovery? You know, am I oversharing? You know, is there kind of a healthy, what does a healthy level of visibility and transparency look like with your stakeholder or communication? I think that's going to vary. I think teams will have to use judgment, you know, on where that sort of communication needs to happen. You know, for example, if it's, say, you know, an operational stakeholder and the real product work that's going on directly impacts their business and what they need for their business to be successful, you're going to have a pretty high level of collaboration with a stakeholder like that. But you can imagine another stakeholder who might be specifically oriented around compliance and there's a solution that might be running up against something. I mean, I can imagine periods where we might need to be checking in with that stakeholder pretty frequently, but I can also imagine periods where it's going to be a lot less frequent. So, you know, there is a lot of judgment, and I think it depends on the particular team, what the team is working on, and the respective stakeholders. All right. Last objection, the accountability question. You know, Chris, you're asking me to give up a lot of control. You're asking me to trust a lot. You're asking me to give space a lot, asking me to give a lot of contact, asking me for all of this. Who do I hold accountable if this doesn't work? How do I hold people accountable? How do I, you know, ensure that something happens because, you know, I've given the space, I can go a whole year and nothing happens. Teams in the product model are signing up for outcomes. That means they are accountable for those outcomes. You know, whatever, whatever, you know, within the parameters that we're setting, Those teams are assuming that. So we are actually placing accountability onto specific teams. Now, what that means in practice, what does it mean to hold a whole team accountable? I mean, that can get a little messy. usually from the point of view of a stakeholder, it does mean product managers and the leaders of those product managers. So, you know, if something is failing, it does, it is going to land on those individuals pretty squarely. And as we said before, you know, if we've done our job right in the product organization, those people feel this accountability, right? They are measuring themselves for this. It's not just this on the side sort of thing. Hey, you've got to worry about my business. Like this should be as top of mind for those product people as it is for the stakeholders. So who is at fault, Chris, if I said the outcome is get more customers and we don't get more customers. Is it my fault? Is it your fault? As is the case with so many of these things, it really is a case by case and you do have to look at the situation. So, you know, this is Typically, when something like that happens, there is some measure of postmortem, right? The people both on the business side and the people within the product organization are going to get together. And, you know, the goal of this is not necessarily to like find blame, but it is to identify what actually happened so that we can see, you know, how to deal with this in the future. And there's a whole constellation of things that could have been at fault, right? It could have been that the team just really wasn't executing properly. You know, they weren't doing adequate discovery. Maybe they weren't up to the task. You know, maybe there's just sort of the wrong people there. Could have been that. it could have fallen very much on the stakeholder side as well, you know, that the adequate context wasn't given to these teams. And therefore, they ended up kind of chasing down a blind alley that could have been avoided. Generally speaking, you know, to keep, so this is sort of that after the fact, you know, like you said, but, you know, hopefully there have been enough touch points, you know, throughout that would keep us from falling into this. But if we do end up in a situation where we do fall into it, you got to get together. And, you know, people need to own what happened, what didn't happen, and ensure that, you know, we do better next time. The postmodern, you know, is kind of treated like an outage. What happens if your site goes down? You know, you bring people together, you understand, and you put things in place to tackle that. And that's the right mindset for building a sustainable culture of empowerment in the product model. Because it's very, very easy for people to defer back to their always when things go wrong, when things break. You know, it's like, we're going to go back to process, control, telling people what to, at least if I told people what to do, whether it's good or bad, something got done. You know, that doing this. All right, rapid fire to end of the day. You know, you're talking to somebody, one thing you think they should do today to coach their product, their stakeholders on the product model, or to improve their relationships with their stakeholders working this way? What would you advise them? So, I mean, if there's one thing and only one thing that I can tell the stakeholders, it's we are trying to bring the product organization in as a partner to figure out the best solution. How can you help them deeply understand the problem that you need solved and communicating to them that way? And, you know, the inverse of that, if you're coaching, you know, somebody, you know, who is on, you know, the product team, asking them when, you know, when they are asked to build something, to get to the thing behind the thing, how do we know for you that this solution is actually working? You know, what can we actually look at to know that this is actually going to be a successful solution? I love this, Chris. I'm sure we could talk about this for days, but this is such an important conversation, probably at the crux of the dynamic shift in so many companies transforming and why it often doesn't work or it fails. And I've often seen for many leaders, they've just never walked in a model like this. So when I have to tell teams, stakeholders are not the enemy, but they need coaching. And it's because they are good. Many of them have gotten promoted in the project model. They've gotten careers built around being able to tell people what to do, not tell them problems to solve. And now you want them to behave differently and the patience that it takes. This was truly insightful, very tactical. I absolutely appreciate the gift of your time today, Chris, and I look forward to having you on another episode. Thanks for being here. Thanks so much. Very kind. Want to learn more until next time? Please check out svpg.com. Sign up for our newsletter that Maddie 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. 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.