A (2:36)

It is such an interesting component. And, you know, I love that you called out the vote, because I have always found that if you truly want to identify a stakeholder, it's not by the voice. Everybody should have a voice. I love that every. I want everybody to care, but who truly has a vote? And in case it's not clear what the vote looks like, I always say, who can veto? Who can say, no, we're not going to do this, and we all stop. If not, they kind of have a voice. It could be a loud voice, a screaming voice, a crying voice. There are different kinds of voices in a company, but the reality is, like, if you don't have a vote, you have a voice. And I don't want to diminish voices, but I kind of want to help people understand that the true idea of vested interest is the veto power is the ability to say no, and your product doesn't go out the door. Now, the reason I care about this is because one of the most biggest frustrations of product people is, like, if everybody thinks there's a stakeholder, you are literally managing a whole company. The bigger the company, the more people that you have to keep happy and think you're selling ice cream to. You know, I have to have 5,000 different flavors for everybody. But if you start to go with the vote, then you kind of realize in most of the things we do, not everybody has a vote. And so I always say the first goal is to be able to differentiate, to your point, the vote from the voices, and that will hopefully start to calm you down a little bit. Like, this is not ice cream selling. I'm not here for everybody, but I want to hear their voice in here. Now, Leah, you know, maybe to help people in context, tell me something you've worked on and give me the lay of the land, of the stakeholders that you had to engage with in that. I want to kind of visualize what they look like and how they affected your product and maybe some of the challenges in working with them.

B (4:28)

Well, one example is, and this was a while ago when I obviously was in an operational role, there was a gap in our product portfolio. And we decided the way to fill that gap in our product portfolio was to Acquire a company and the acquisition of that company could help us in a variety of different ways. It would bring technology into the portfolio, but it would also bring talent into the portfolio. And one of the things that this company had, which we were really excited about, was it had the ability for a customer to actually quickly build an online storefront. Right. So very much similar to Shopify functionality, et cetera. And so when we were acquiring this company, there were a lot of key stakeholders in any kind of M and A business. So as a product manager, as I was putting forth the case to acquire, I had to work with the finance team, right? I needed to make sure that I had a path to profitability for this company and it needed to be accretive to the business. Second key stakeholder was legal. Because we were trying to help customers build storefronts. There's certain compliance and regulations that you have to go through. It's PCI compliance, making sure that if we store credit cards, no one has access to that credit card data, which is a really important thing with any kind of E Commerce product. So legal was another one of the stakeholders executive committee. Any acquisition that we had to, that we wanted to propose had to go through the CEO of the company. So the CEO was a key stakeholder and also had, by the way, veto power. And then we also needed to make sure that the other product teams were on board with our product strategy that we, in fact, were going to bring on E Commerce. And there wasn't anywhere else in the organization that was building this from the ground up. So this is a good example of a voice, not a vote. Right. So those other product teams had influence over our ability to move forward with this, but they didn't necessarily have a vote. Right. So if we found the right solution, they could influence, but they couldn't veto what we were talking about. So again, that distinction that you were talking about earlier, voice versus vote, is important to call out. Now, the example that I want to hone in on was that thing that I called out on PCI compliance. So we knew that as a large public company, if you are not PCI compliant, you incur fines. There's a lot of risk if you're not PCI compliant. And the legal team said this startup that we were trying to acquire was not PCI compliant. The legal team said, absolutely not. This is a stopper for this acquisition. We cannot move forward. So we thought it was a stop sign. But when we did further diligence and further investigation, we actually found that we had two years to bring this startup functionality up to PCI compliance before we incurred any kind of fines or any kind of risk. So something that actually first looked like a stop sign was actually a yield sign so we could move forward. And so again, like, understanding. And it's a nuance. It's not black or white. It's not hard and fast. Rule part of the job of a product manager is to one, identify those stakeholders identified. Who has a veto, who has a voice. Understand what's a pure stop sign versus a yield sign. Like, it's a little bit of the art and science of stakeholder engagement. Note that I did not say management because stakeholders are not people to manage, they're actually people to partner with.

A (7:51)

That's right.

B (7:52)

It's lots of learnings in that. But it's really important as a product manager, as a product leader, to understand the landscape. And as a product leader, it's kind of your job to help your product managers and your product teams navigate who they need to partner with throughout the organization so that they can move the ball forward.

A (8:12)

Oh, I love that story a lot. You know, we kind of see the job of the team is to solve problems for customers in a way that works for our business. And many people see constraints as blockers. You know, and I always tell people, look, I think you've missed the point on why put up work is hard. For me, it has never been hard to do the first part, make customers happy. Like, you know, making customers. Customers are humans. You know, I've always told any company I work with, you know, buy me a private jet or a plane, I'll be happy as a customer. Like, yeah, I mean, that's a.

B (8:42)

He's.

A (8:43)

But he's like, why can't we do that? He's like, well, we will be. We wouldn't have money. We will make profit. It's actually the constraint, the box in which we have to solve the problem. And I always tell people like you call out a great example of a constraint, we need to be PCI compliant. In some ways, people can just automatically say that, oh, they said, no, you know, legal has blocked us. They don't want what's best for our customer, you know, some ways. But your job is not to say, oh, we have a. Is to solve the problem within that constraint. It's like that we still need to solve the problem and we need something that is PCI compliant. That is the. You. You kind of call that out. Again, I say, man, you've got to think like, winning is not checking a box. It's not, you know, is it pci? Sometimes you might actually have to build the PCI compliance in that sense to get something that is legal. Winning is something that is legal, that we can market, that works for our business in that way. I had a similar story when I was in the HR tech. I always like to bring my stakeholders early. And we were launching a product in a market in China, and I found this stuff about we can't launch it in China for some regulation that the government had around the partnership you needed to have with the product. I went to the head of legal feeling very proud of myself, like, I have identified an issue that might make it difficult to launch it. And she's like, will the product work in China? I said, the product works as a global product. But, you know, in my research, I found this Chinese issue that will make it difficult for us to launch in China. And she's like, oh, okay, I think I'm going to sue the Chinese government. I'm like, whoa, I didn't ask you to do all that. She's like, you know, because that means we'll be the first company with a product in that market if we actually win the lawsuit. It actually started to change my mindset of stakeholders in some ways because she cared about the outcome, not looking for ways to prevent us from some ways. But, you know, I was very humbled by that interaction. Funny enough, the lawsuits became very popular or public in Southeast Asia. Our market share in Singapore, in other markets close to China picked up dramatically because everybody's like, what's this about? Oh, why is he not in here? I always used to be afraid of stakeholders looking for a way to stop me from doing things. And it was my first career experience early on to see a stakeholder look for ways to enable an outcome.

B (11:01)

Well, so, Christian, you said something that is very, very important, which is you were proactive with your stakeholders. And I think this is one of the most common mistakes that we see with product managers and product teams in general. They fear their stakeholders, and they. So they hold everything close to the vest. And they're not proactive with your stakeholders. Your stakeholders are your partners. Right. Again, there's that vested interest. They want the outcome that you're trying to drive in the organization. So if you're proactive with them and you actually ask them for help in solving that problem, that's a completely different dynamic in the organization. And that's what makes really effective product managers. If they're proactive with those stakeholders early and often, is what I usually say to product Managers, you have to be early and often always be proactive. Never have a stakeholder or try to chase you down for information. If that's the case, you've already lost. So you need to be really proactive. I'm so glad you called that out.

A (12:01)

And you're calling out. You know how to be proactive. I tell people, you take a prototype. You know, it's kind of like if I came to you and I said, you know, I'm thinking of building a house, what do you think should be in the house? You're going to live in the house, you know, what do you think about this design for the house? That's great, but if it comes to you, I'll be like, I built a house, you know, do you think it's going to work for you? Freaked out about that. You know, it's kind of like people worry, like, in this, discovering the testing that we do, you know, most stakeholders are not afraid of, like, we tested with three customers or five customers or 10 customers. But you see B2C companies with millions of customers. I am about to launch this tomorrow. Like, how? How? I don't know what this is. You know, the secret I tell people is like, the best way to know if something is legal in your company is if legal built it with you. The best way to know if you can market something is if marketing built it. The best way to know if it's, you know, if you can sell it, if it sells, built it, you by default. When people partner and work with you on something, they look out for their best interest. You know, if. If the legal team is working with you on something, they are going to be thinking with a legal lens. Like, you know, because they are the ones that have to wake up in the middle of the night if you get a lawsuit. If marketing is working with you, they're going to be thinking, can I really market this? How is this going to disrupt my world? So I love that early and often people always kind of say, I did a PowerPoint presentation for my stakeholders. Or, you know, I kind of briefed them. I send them a product brief document to read. I can't believe that they did not read it and understand what I was trying to do. You know, have you ever seen that? And maybe tell me why you. That doesn't work.

B (13:39)

I think collaborating over artifacts is missing the point. So a lot of teams will do exactly that.

A (13:45)

They'll.

B (13:46)

And I love written narratives. I love, you know, any kind of framing document. But the purpose of those documents is to capture the Conversation, not be the conversation. Right? And so this goes back to when we last talked about trust, right? You can't build trust over a document. You build trust by actually walking someone through the why behind you're doing something. And so that one on one time with stakeholders, yes, it's an investment, but that investment is bringing them in early and often. And I'm not talking about hour long PowerPoint presentations for your stakeholders. I'm talking about 15 minute whiteboard. Let me just walk you through what we're thinking about. Here's how we're going to test it, here's our hypothesis. Having that conversation pays off exponentially later on, right? Even with sales. Like I worked in B2B software organizations where the sooner you can bring sales in, the better off you're going to be. Now, a lot of people are scared of that because they're like, you're committing to sales that you're going to build this feature. I'm like, I'm not committing to sales and I'm going to build that feature. I'm trying to get their input. Hey, I'm thinking about this. You know, can I run this by a couple customers with you? You know, that's a very different conversation than committing to sales. So, you know, trust your stakeholders to understand the process. If they don't understand the process of discovery, teach it to them. Explain to them what you're trying to accomplish. There's nothing, you know, there's nothing scary about that. And you'll find the more you do that and you actually have a great case study in terms of the work that you've done in terms of building trust with sales that I absolutely love. I talk about it all the time. You know, that is so critically important. But don't shy away from it, embrace it. Lean forward into that kind of conversation with sales. They're your advocate, they're your partner in bringing something to market.

A (15:38)

You've called out a couple of important dynamics. You know, avoid the artifacts. They are not the discussion that you're having. I always say you've got to. People need to see stuff because they make assumptions. You know, you do a PowerPoint, you're like, I'm assuming it's going to have the brand colors, you know, and then the second you launch it, they're like, this doesn't have the brand colors. How did you miss this? You know, in some ways, and you know, whiteboarding is kind of collaboration, means solving a problem together. You know, what you're doing with them is they start to feel like they Are participating in solving the problem rather than you presenting to them kind of what you're doing or giving them an update. And you called out another piece of the one on one. Many people always stumble, Christian. That doesn't seem effective. You know, I need to update finance and legal and marketing and sales. I just pull them all into one glorious room and I'm just going to tell them what we're doing and get all their concerns on the table. That looks very effective. You know, I say, my goodness, you know, you got to avoid group meetings. There are so many interesting dynamics there. I mean, we could probably spend a whole episode talking about it. But I'm like, what about like the hippo effect? You know, you're in a meeting, the CEO is there, and the CEO says, that is a stupid idea. Who is the next person to speak up in that meeting? And if they speak up, what do they say? Yes, I agree with you, CEO. That is a stupid idea. Everybody just agrees with that. Or, you know, the. The smartest person in the room or the person that is trying to impress their boss. You know, let me ask a smart question so that they can think that I'm paying attention in this meeting. You know what, the star wars effect, I always call that one, you know, where maybe a finance person will ask a legal question. And then legal is like, how dare you ask a question about my department. I'm now going to ask a finance question. And in your meeting just looks like people are shooting each other. Like, you called out a very important technique. I can't even stress that to people. I say, look, what you do is a one on one. You know, you go, you kind of describe it. A product walkthrough. You kind of say, hey, Lear, you know, we're trying to build. You're the head of legal. Do you see anything that concerns you from a legal standpoint? I know it sounds crazy, people, but I have not seen any more effective way to collaborate with a stakeholder than a one on one. Because I mean, all your trust dynamics comes out there, Your relationship building comes out there, you know, And I think the last point you called out was sales, man, sales. You know, that's always a fun one for people because I think people fail to understand the role of sales. Because, you know, most product people, we create value. Your job is to sell, go sell. In some ways, why are you up in my business? And I have to think to people like, you know, do you know how salespeople get paid? Their whole family depends on something called commission or something. If they don't sell, they don't eat. Like, you know, And I tell people we have a misalignment of goals if you're missing the point, with what the importance of sales in that world. And understandably, great products make sales easy if you do great products. But in B2B environment, there are so many nuances because a salesperson brings or extends their relationships, the trust that somebody has given them to the company and to your product. And I always tell people, you know, we lose sight of the importance of collaborating with sales in the work we do because our products are experienced in the totality of it. Meaning, like the experience somebody has with a salesperson can actually affect what your product is. Like, I have a perfect product, nobody buys it. People are not even selling what you thought you built. In some ways. And it is actually your job as a product team to solve for how people experience the value you've created. And so collaborating with sales is not an option. You know, you have to solve for the constraints of how do we sell this, how do we talk about this, what do customers say into this? And you have to do the same mindset. You kind of call that teach them discovery. It builds trust because you're like, oh, you're trying to learn, you're trying to understand the best way to do this. You're trying to make my job easier to sell. Not that you have the perfect answer and you're trying to force it down my throat. So I love that. Okay. Now, one of the ways we experience stakeholders Lear is through stakeholder driven roadmaps. You know, somehow the only way we heard about marketing is from a list of projects and features that they have found their way to get into a list that comes to our table. And that is often our first experience. Like, who wants this? Well, marketing says we should do this. And you know, sales, it came from sales. How do you manage that? In some ways, because all of a sudden it's not a relationship, it's not a collaboration. It kind of feels outside, in, top down, you know, how do you go about navigating an environment? I have stakeholder driven roadmaps. My stakeholders, the only collaboration I have with them is they told me what to do on a piece of paper.

B (20:29)

So I fundamentally believe that ideas can come from anywhere inside or outside the organization. So with that mindset, that means that stakeholders are always going to have input and have ideas in terms of what we should build. However, just because they have ideas doesn't mean that it's the right thing to build or even the right problem to solve, but it's a great input of ideas. And so you still, as a product team, you need to test those ideas that come in. You cannot take them at face value. You still have to go through some discovery process. So we all know that when we're mitigating risk as part of discovery, we think about value. Will they use it, Will they buy it? Usability risk, can they use it? Business viability, will it work for the business? And technical feasibility, can we build it? And a stakeholder typically doesn't think that way. Right. They think more. And this is overgeneralization. But if I'm a sales rep, I met with a customer, the customer said they want X, I'm going to go back to the product team and say, give me X. Because the customer won't buy unless you deliver X. Right. That is a pure definition of a stakeholder driven roadmap. I need to sell the product. I can't sell it unless I have that capability. That assumes that there are more than one. There's more than one customer who needs that capability to solve their particular problem. You still have to test that. And I think the more you can work with your stakeholders to help them understand, you know, you are trying to build products that work for customers and work for the business based on evidence that you have from a value perspective and a viability perspective, that's a very different conversation than just taking that feature idea, implementing it, and doing it at face value. I actually worked with this one organization that they had a roadmap, and at the end of the year, they delivered absolutely everything that was on that roadmap. So from a development perspective or a team perspective, check the box on all the things they committed to delivering. They delivered everything. However, none of the things that they delivered moved the needle on the business whatsoever. Because from a product leadership perspective, no one tied the work to be done back to the results that they were trying to achieve for the business. Huge disconnect. Were the stakeholders happy that they delivered everything on the roadmap? I would guess not. Because, you know, the business did not accomplish anything that it was trying to accomplish. And that's the danger of state driven roadmaps. The team views success as delivering the feature, not achieving the results that we're trying to achieve. So that shared definition of success is really, really important. So aligning on that shared definition of success with the stakeholders, let the stakeholders know your objective. What is the problem that the team is tasked to solve? That's why I'm a big fan of not just feature roadmaps, but objective based roadmaps because that is aligning again on the definition of success, which is articulated in our objectives and our key results, which is critical. Share that with the stakeholders.

A (23:36)

Oh, I love that. You know, you're calling out, in some ways, evidence beats opinions and most of the ideas that you might see are just an opinion of what somebody thinks will solve the problem. You know, it's kind of like a customer thinks, if I have this, it should do this. If you build this, you know, salespeople are believing, if you build this for my customer, they will give me back money in return, which will help me get my commission and feed my children. And I want people to understand like that's the heart of what they are trying to communicate to you now. You have to ask them what they really want is to win a deal by solving a problem for a customer and to get their commission. These are the outcomes in the eye. That's what good results look like. You just describe the situation. They built all these things, they probably didn't win the deal, didn't grow their business, and then they're going to add more things. Maybe you didn't build it the right way. I need more things in here. So you're calling out this particular technique of you need to understand the problem they are really trying to solve. You know, it's a great idea, makes people have great ideas. You know, and so you kind of say, why do we really want to do this? Oh, you, you're struggling to close a deal. Why customer is missing. What's the customer trying to accomplish? Is there a better way? So you have to test, you have to gather evidence that if I do this, it will actually get us the results we want. And I, and I think that is a very important thing to do. You know, people say, well, Krishna, you know, no matter how you try that, you haven't met our CEO or leader. They do the super boop, you know, where they just come in and they just dump it on us and then they just walk away. I don't even tell executives now. You know, one of my favorite techniques is actually to take them out on discovery with me or a salesperson on discovery. You know, if a salesperson is like, this is what we want, I say, you know what? I want to make sure we succeed when we do it. You know, let's go talk to that customer now. You know, sometimes I might even know that customer doesn't really even want something. You know, I might find that I need to show them how we go, learn how we test. Because then they need to trust that the things we do come from some evidence, come from some experimentation, but they don't know what we're going to do. They just expect. I tell you you're going to do it, right? But I'm saying I want to do it well, so I'm going to validate and test it. I take my executives all the time to meet customers, and I go with them because they start to see the process or the way we work to come up with evidence. And so when somebody says no, they see us kind of we are prototyping like we're right, we're testing like we're wrong. We're like, no, no, no, tell me why you really want this. Tell me what you. And so what he does is he starts to increase the trust of, like, these people use data, they use evidence to make their decisions. So, you know, maybe I should just kind of feed them. I think some customers have some, then tell them what to do. Most people have no clue. And I think the last point is many people don't know how valuable, or maybe not so valuable their ideas may be. Meaning, I've never met an executive or a stakeholder that says, oh, I have an idea that will make us $1 million. And you tell them, my team is working on something that will make us $10 million, and you say, no, do my $1 million first. You know, most people don't know that there's something more important, something that could be more valuable. And so I think good stakeholder collaboration requires us to. Not just to collaborate, but to get good at communicating where things are, you know, what problems we're solving, what we think. Because if they can see, like, oh, you know what, I have a great idea. But what they are working on, my goodness, if they deliver that, we are going to. They have some great evidence of results. This is just an idea. And I tell people, please don't get it wrong. If you don't have an idea that is probably better than your stakeholders, you should probably go test that one. I mean, what are you trying to prove? It didn't come from me, so we're not going to do it.

B (27:14)

Well, you call out a really important thing, which is it's a really dangerous thing for the product team or the product manager to think that they are the only source of ideas. So I always tell my product managers that when a stakeholder comes to them with an idea, employ the rule of improv. And the rule of improv, as everyone knows, is yes. End so Christian, if you come with to me with a great idea or even a mediocre idea, even a bad idea, and you say I think we should build X, I'm going to say, oh yes, tell me more about that. Tell me more. Yes. And I would like to know why do you think we need to build that? So it's kind of like a mashup between the five whys and the Rule of improv. But use it as an opportunity to have a quick conversation with the stakeholder. If nothing else, you're going to learn why they think it's such a great idea and you might even choose to do discovery on it and to find out more and to actually test it with customers. But who cares where the idea comes from? If it's something that's worthy of pursuing, that's great.

A (28:18)

I love that technique a lot. Kind of the Rule of Improv and the five Whys. This has always been fun. Like I love these conversations. I think we can do them for hours as usual. I am so grateful for the gift of your time today and for really spending time talking about these topics and going deep on them. I look forward to more conversations and more episodes on good topics. Thank you again Leah for another wonderful episode.

B (28:44)

Always a pleasure spending time with you.

A (28:46)

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. 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.