The Intentional Product Manager Podcast

Success With Stakeholders

• Shobhit Chugh • Season 1 • Episode 5

Share episode

Join Shobhit Chugh from Intentional Product Manager with special guests Bruce McCarthy and Melissa Appel, co-authors of Aligned: Stakeholder Management for Product Leaders. This episode offers actionable insights to help you manage stakeholders, build trust, and navigate decision-making cultures. Plus, discover the surprising benefits of "mining for conflict."

Key Takeaways

  • 00:00 Meet the authors: Bruce McCarthy and Melissa Appel
  • 00:44 The Story Behind the Book: How Aligned was born
  • 01:08 Challenges in stakeholder management: When to say “yes” and “no”
  • 03:28 Building rapport: Why understanding stakeholders is as crucial as understanding customers
  • 05:04 The importance of organizational fit: Identifying hidden roadblocks to career growth
  • 08:15 Communicating effectively: Strengthening relationships between product and sales
  • 11:00 Positioning yourself for promotions and identifying influential "power players"
  • 13:13 Learning from others: Gaining diverse perspectives to craft well-rounded strategies
  • 15:00 Building comfortable, meaningful relationships
  • 15:58 Practicing empathy: Reflecting stakeholder language for clarity and connection
  • 17:00 Turning difficult relationships around: Finding common ground and bridging divides
  • 19:45 Earning a seat at the executive table: Building and maintaining executive relationships
  • 21:00 Mastering “the meeting before the meeting”: Setting up for success
  • 22:48 Decision-making cultures: Identifying decision-makers and distinguishing alignment vs. agreement
  • 26:30 Mining for conflict: Using strategic disagreement to foster psychological safety and alignment
  • 33:37 Trends in product leadership: Balancing empathy with founder-driven dynamics
  • 35:12 Hiring insights: Attracting top talent in competitive markets
  • 37:13 Where to find more about the book and authors
  • 38:22 Closing thoughts

Discover how to deepen relationships, boost your organizational impact, and drive success for your product and company.

Learn more about Shobhit Chugh at intentionalproductmanager.com and connect on https://www.linkedin.com/in/shobhitchugh/

Learn more about Bruce McCarthy at Product Culture or connect on https://www.linkedin.com/in/brucemccarthy/ 

Learn more about Melissa Appel at Product Culture or connect on https://www.linkedin.com/in/melappel/

Get Bruce and Melissa’s book “Aligned: Stakeholder Management for Product Leaders”

www.intentionalproductmanager.com

 Ready to move to the next level in your product career? I'm Shobit from Intentional Product Manager. Join me as we discuss ways to help you stand out in your job search and your career, so you can have more impact and make more money. 

Welcome to the Intentional Product Manager podcast. With me today is Bruce McCarthy, who's author, speaker, founder at Product Culture, and Melissa Appel, executive coach for Product Leaders. And they together wrote a book called Aligned, Stakeholder Management for Product Leaders. It's been getting a lot of awesome reviews, a lot of great reception.

I'm excited to speak with both of you today.  Awesome. So let's talk more about the book. Like, I am curious about the origin story. What led to the writing of this book? 

Yeah. Um, so I've been leading product teams for a while and I found that at a certain point, the problems that people had on my team, the things that were sort of holding them back, weren't the inability to create a strategy or write a roadmap or whatever it was that was kind of failing.

Tactical. It was dealing with stakeholders. And so I had a couple of different people on my team who had trouble saying no in different ways. One of them just said no to everything with no explanation, which stakeholders did not like. And another one just said yes to everything because he felt bad saying no.

And so I was thinking that really what they need is some sort of resource on better ways to say no. And so I approached Bruce with that idea and he said, I think it could be a lot more. I think it could be kind of all of stakeholder management and that's sort of how we got started. 

That was the sort of the proximate cause if you will, but the ultimate cause also was, I think I also had an experience that taught me the value of stakeholder management and the, uh, the importance of handling that when as a, as a first time product manager, my.

First software product completely flopped. Not because I didn't understand the customer I'd done my research, not because the solution didn't work for them to solve their problem. It did. We had one customer who was happy, but because the sales team and the marketing team had no interest in selling the product, it didn't help them meet their numbers.

Everything was locked and loaded for them to promote the core product of the company. And even if I arguably had product market fit, I didn't have product organization fit. And so when Melissa came to me and said, there's this problem of saying no, I was like, well, yeah, there's also this problem saying, yes, you need to get everyone to buy in to your plan.

So let's take care of this, getting everyone in the company in what I would call your extended team on board. Let's talk about that problem. 

That's pretty awesome. And I know you both mentioned getting people to say no or yes. I'm assuming just maybe is not a good answer.  

Good one. Yeah. See, I think people actually are more comfortable.

Maybe this is counterintuitive, but they're more comfortable with a reasonable no, than they are with uncertainty. They are with vagueness. That's why people don't like politicians because you get a non answer, right? So product manager, Should not be about playing politics, should not be a politician, should say yes, because it fits with our strategy or no, because it doesn't fit with our strategy.

But we are recording this podcast five days before the election. So that's a very timely reference to everything else going on around us. Awesome. So let's then dig into some of the parts of the book. So you mentioned saying yes and no. What are the other struggles product managers have with product development?

Stakeholder management. 

I think one big problem that some people have is building rapport is sort of recognizing that their stakeholder is just a human like you, they have their own boss, who's asking them for things and they have their own success metrics and they have their own incentives. And if you can understand more about this person as a human, and as somebody who has their own kind of agenda, then it's easier to relate what you're trying to get across in their frame of reference.

And that allows people to engage more, uh, versus kind of putting up walls and being us versus them. 

To follow up on that, the question is how do you establish that rapport? And we have a bunch of advice in the book about that. Part of it is actually taking the time to reach out informally and talk to somebody without having an agenda right away.

Just talk about the weather, or the weekend, or your kids, or the sports team you both follow, or the coffee in the cafe and how lousy it is, or whatever, to make that human connection, initially. And then when you do get to talking about business, don't start with your side of it. Start with asking them about them.

Ask, start with asking about their job and what they're trying to accomplish and what success looks like and how they're measured and where the challenges lie and what they're doing about it and what's working and not working, then you'll naturally go into that conversation, that problem solving conversation that may be You can help them and they can help you.

And if you notice, those questions are pretty similar to a customer interview, right? You want to learn about your stakeholders the same way you're learning about your customers. Bruce sometimes says this along with his kind of origin story, which is, you don't want to just have product market fit, you want to have product company fit.

And that requires getting to know the people in your company and understanding how what you're working on relates to what everybody else is working on. 

very insightful advice. Also, it makes a lot of sense. And when some things make a lot of sense, I always tend to ask, but why aren't people doing this already?

Like what are things that block them from just doing it all the time? 

I think partly people don't acknowledge consciously that they need to do it. They kind of feel like, well, if I do my job of figuring out the market need and. Working with the sort of obvious people that I need to work with, say, if you're a product manager, maybe it's engineers and designers and maybe a data scientist or an analyst, and I produce the thing we're supposed to produce that will solve the problem like I did as a first time product manager.

They think that's enough, but you're not the product manager. of the code that you ship at the end of a cycle. You're a product manager of what is effectively a small business unit within the company. And your job isn't just to ship it. Your job is to make it successful. Successful for the customer, but also successful for the company.

And that means taking ownership. Taking ownership of the result and when you look at it that way you're like well obviously I need sales and marketing and support and finance and everybody. I need a much larger team than I thought. And but I think sometimes we just get caught up in the well if we build it they will come.

It seems. That there's almost a redefinition of a team going on where it's like, cool. My team is my engineers. I have a designer I work with, maybe QA. And now we're talking much, much broader here. Yeah. 

It's sort of like the immediate team, the day to day team, and then sort of the extended team, right? So you might not talk to your marketing counterpart every single day, but you do need to know what's going on in their world and you need them to know what's going on in your world.

Um, you know, a lot of. People complain about too many meetings. And I feel like those one on ones with stakeholders, whether they're like once a month or whatever it is, I feel like those are the best use of my time because it allows me to connect what I'm doing to the rest of the company, which improves my chance of success.

Some of the, um, best. Product launches that I've had, in contrast to that first one, were when I actually teamed up with someone in sales. One person who I did talk to almost every day because they were looking for the right opportunities, having conversations while I was still working on the product. the initial version of the product.

And so we had a tight feedback loop about what I was thinking, what he was hearing. Um, he'd get me on a call. I'd help out with getting the customer on board, but I'd learn a lot in the process. And that, that feedback loop that we talk about with, with the customer in experimentation, that feedback loop that we talk about of having a real, um,  collaborative, um, uh, effort between the, the product trio, the, the product and engineering and design that should be happening through all of these functions.

That's where really successful products come from. 

Now, one thing comes to mind, like what's a good trigger point to start some of these, is it like onboarding when you're starting in a new team or something else? 

So if you're only engaging with people, when you need something from them, you're not going to be as successful, right?

It's like the best time to look for a job is when you don't need one. The best time to like build relationships with stakeholders is when you don't need something from them urgently. So I would say when you start a new company, definitely go and go and meet everybody, go and figure out what all the departments do.

Um, but even if you've been in a company for a while, it's not too late to say like, Hey, you know, I'm realizing that I think that. You know, product and sales should have a better relationship. I'm curious about what your job is like and what your interaction with customers is like, I'd like to learn from you.

Right. And you can do that at any point. Um, and I think the best time to do that is well right now. Um, but it's, it's before you actually need something. 

It might feel like there's a lot to do here. You've got a lot to do with your customer research. You've got a lot to do with, uh, working with your immediate everyday squad.

Um, and this is just another thing for the list, but it's really leveraged, um, I think in terms of the long term success of your product, project, initiative, whatever, um, and you don't have to engage absolutely every day with absolutely everyone. I think it's possible, as Melissa says, To space it out, um, not make it a, an everyday, um, thing.

I think it's also possible to prioritize among the different stakeholders that you reach out to.  We've, um, got some advice in the book about how to map out the real org chart within your organization. The official one with the CEO at the top and the lines and boxes that all make everything look really neat.

It's not very useful in figuring out who you really need to connect with. First of all, you, you wouldn't even probably take a cross functional view. You'd probably just take a up the chain view initially, and that, as we've talked about, is not right. But then, which functions and at which level do you engage is hard to suss out at first. 

I'd give a couple of bits of advice about where to focus. One is, you know, Figure out if the company is sales led, engineering led, marketing led, finance led, whatever. Um, and emphasize talking to, making relationships with, using the language of that dominant function. It can be tricky to figure it out. I started off, um, at one company where half the company was engineers, and I worked with engineers all day long.

It was a technical product sold to engineers, and I thought, Well, obviously it's an engineering driven company, but I got a bunch of clues. Like, um, the CEO always talked about the sales numbers. First thing at company meetings and the CEO had, had a coffee every morning with the sales ops director who knew the state of play of every deal in the pipeline all the time. 

And, uh, it wasn't until I started helping out with. deals. I started going on sales calls that I got a promotion. All of those things added up and I realized, Oh, actually this is a sales driven company and I should have known better. It took me a while to figure it out, but it's possible to figure it out by stringing together those clues. 

The, um, the other thing you need to watch out for is what I would call the hidden power players where, um,  There's usually somebody on the org chart who has a vague title like BizDev or Strategy or Partnerships. Nobody reports to them and nobody really knows what they do. But they talk to the CEO or some other top function really often, informally.

And they turn up in meetings where you didn't know they were invited and you don't know why. Um, that person is probably what we would call a CEO whisperer. Um, somebody who, if they like what you're doing and they think you're on the right track and they think you're smart and working for the good of the company, will hopefully whisper the right things in the CEO's ear when it comes to budget time or hiring time to give you the resources that you need and the support that you need in the other departments. 

But the opposite is also true. If they don't know who you are, they're going to prioritize something else. Or if they think that you're working at cross purposes. You might need to find another job. 

Those are super useful. And one of the things that I'm hearing from both of you is a lot of this is based on your personal experiences.

But then I'm also curious, like, during the journey of writing this book, which I assume was a multi year journey, what were the kinds of people you came across with, spoke with, and any, like, any lessons that surprised you during those conversations? 

It did take two years to write. And we rewrote it almost entirely from scratch after the first draft.

And that was partly based on feedback. 

We had an early readers club, which was really helpful with the book. And we would release a chapter and get them to give us feedback. And they did end up giving us feedback on entire. Drafts as well. Um, but it turned into a little bit of a stakeholder management support group.

Um, which, which was great for everybody, right? We learned a ton about different people's experiences and they got to sort of, you know, both vent and also get feedback, not only from us, but from the other members of, of the early readers club. Uh, and I think that was, That was valuable all around and, and kind of gave us, uh, in many situations, counterexamples to our own experience.

Um, and it gave us examples of things that might happen differently in different cultures or different parts of the world or with different types of people. Uh, and that was all very useful to help us have a kind of more well rounded story and, and examples. 

It was great when people would just weigh in right in the Google Doc with their comments and say, um, this doesn't match my experience or I would interpret their behavior in a different way, uh, based on my company's culture.

Um, and that rounding out of the perspective and being able to offer multiple perspectives based on the early readers, um, was super helpful. We also found that she and I, uh, Melissa and I differed a little on our approach to things. Um, when it came to, like, how do you get alignment on a, uh, roadmap, we were pretty well aligned.

But, um, I was suggesting things like you really want to have as informal a one on one as you can, so therefore you might, uh, invite somebody that you wanted to have a little bit more time with out for coffee or a drink after work. Okay. And Melissa was like, well, that might work for you, Bruce, but as a woman, it might come off as inappropriate, um, if I were to ask a colleague out for, a male colleague out for a drink after work, um, and so we, we ended up sort of saying, um, not here's a list of things to do, but here are some tools you might consider, um,  Within the context of your comfort zone and the, uh, the expectations of the, the organization you're in.

Coming from your point of view, I would have not considered that. And it's great to see both of you team up and, you know, bring those different points of view. Give me one more instance of like what you learned from your, like some of your early readers club. It was just like. Surprising or a change your point of view.

I'm going to go with empathy. We have a whole chapter on establishing rapport that is really about gaining some empathy for your stakeholder. Melissa alluded to this a few minutes ago, asking about them, trying to understand them as a human. And repeating back to them what they've said to make sure that you got it right, and to show to them that you're trying to get it right.

And when they say to you, yes, exactly, or yeah, you got it, or I couldn't have said it better myself, then you know that you have  cemented a relationship and gained some empathetic connection with that person. So we really have emphasized that. But there were places in the book where In our first draft, anyway, we were coming off, I think, as unintentionally judgmental about stakeholders.

Oh, CEOs, they just randomly get ideas on airplanes from reading magazines. Oh, salespeople, they'll just sell, they'll say anything, promise anything, they don't care what the consequences are. Uh, and those kinds of  really prejudicial, um, comments that are not specific to any one person, but to a group. And  Um, they called us out on that, our early readers, and I was, um, I was like, damn, they are right.

We need to rethink this, and we need, we need to really double down on this idea of turning people who may come off as, uh, combative, or, um, selfish, or short sighted, um,  making the story reveal that, They're just human beings like you are, they're just trying to do their job like you are, and your job is to find common ground.

We weren't taking our own medicine, right, which is like what we realized, we're like, yeah, get to know them as people, but like also those sales people are terrible. Um,  and so it was like, it was like an us versus them kind of thing. And that's, that's actually, I think, one of the biggest triggers that caused us to rewrite the book from scratch after the first version, because we're like, we're like, There needs to be so much more in here about empathy and about understanding other people's points of view and about, you know, the whole like Kahneman, Traversky, like the, the things that we subconsciously do that, that don't make sense.

Um, and just sort of realizing that if somebody's behavior seems irrational to you, it's probably just something you don't know yet. Right? It's clearly rational behavior to them. And you just have to figure out. What's going on rather than dismissing it or getting defensive. Um, and I think that that's, that's something, I think that's probably one of the biggest learnings from our, from running the concepts by people and by running the drafts by people that we realized that we were giving advice, but not taking our own advice.

Yeah. It also turned us, it's kind of happened organically on to writing the book, not just as a sort of how to textbook, but also as.  Um, there is a narrative through the whole thing. It's basically a novel as well as a bunch of tools and frameworks about a product person who starts at a new company and needs to figure out who does what and how decisions are made and where the hidden power players are.

And. Um, needs to rally the troops, if you will, get that extended team together to solve some real significant problems with the company and the product. She shows a lot of leadership in the process, but she goes through a lot of struggle in the process. A chief part of it is getting to know her stakeholders as people and as people who have responsibilities and goals and figuring out what it's going to take to get them on board with a plan they can all align on.

I 

love it. Now, relating that to like maybe some of the work and Melissa, like specifically for you, you do executive coaching for product leaders. So how often does stakeholder management come in as a topic and like, what are the kinds of things you're working through? 

So I would say it's, it's always a topic, even if it's not the thing that people initially think that is the problem.

Um, frequently, you know, they're trying to get something to work and it's not working and they can't figure out why it's because. So and so is not aligned with it. Right. Um, whether that's, you know, a particular product or a process or some sort of change. So stakeholder management is often something that people recognize and say, oh, yeah, I could use help with that.

There's this person that I can't figure out. Um, but sometimes it's. It's a bit hidden as well and comes out later.  

I've had the same experience. Uh, in fact, more often than not, when I end up coaching somebody who's new to the head of product role, the VP or CPO, the job, like Melissa said, isn't teaching them product management.

They usually know that stuff. The job is teaching them how to reach out across the aisle, be part of the executive team. And. Yeah.  and act like it, play like it, um, figure out how to, uh, how to establish those relationships and maintain them. I, uh, coached a, uh, VP of product, um, who joined the executive team for the first time after having been there for a couple of years.

Um, and, uh, his CEO hired me to help him out. And he said, uh, he's, he's fantastic. Um, but he needs to learn how to be an executive. And what he meant by that was to manage his relationships with the other executives. 

I love that you have the interpretation of that because people might think, Oh, probably executive presence is the first thing they would go for, or like communication skills, but it's really about relationships here.

No, he was good at that too. It wasn't that at all. It was the relationships. 

Yeah. A lot of time it's, it's building the credibility. Right. To be considered part of the team or, um, you know, figuring out how to speak to people one on one before the big meeting, uh, in order to make sure that you know what everybody's going to complain about before you get there so you can.

Have a better meeting. And a lot of times, you know, as you move up into your career, you just see the meeting. You don't see the work that goes on behind the meeting. So you don't realize that there's work that goes on behind the meeting, right? Even just with, you know, executive presentations. If I do an executive presentation, I'm going to run, I'm going to mock the presentation up.

You know, and, and give it in front of some friendly faces and have them ask me the questions they think the executive will ask and then you refine it, but not everybody sees that that's part of the process. So sometimes it's like, well, you know, here's what's really going on behind the scenes for these successful meetings.

I have earmarked a couple of things I wanted to dig deep a little bit on, I actually can't find it, but I know the topic. So one of the things you talk about is the different cultures of decision making in companies. And I found that really fascinating. Like, tell us a bit more about that and how you might uncover what's the culture of decision making.

So I think, I think you're talking about the, um, kind of directive participatory consensus. So different people make decisions in different ways, but overall, The company usually has some way that decisions are made, right? The directive is usually some person at the top makes all the decisions and like, that's it.

Right? So you might, you might find that a company where everybody's always going to Saying, well, I can't make this decision. Cause like the CEO or whoever needs to make the decision and everybody's sort of deferring to, to one or a few people, um, consensus is like, we can't make any decision until everybody agrees.

And those situations don't often even ever come to a decision because you're unlikely to get everybody to agree. Um, that's one of the things that we talk about, the difference between alignment. And agreements, right? You don't necessarily have to agree with the decision to be aligned in supporting it.

Um, this, the, the concept of disagree and commit, right? Like, I don't necessarily agree, but I'm going to go with it. Um, but, uh, participatory is the way that we 1 decision maker, but they are obligated to get feedback. From a variety of different people before making the decision. So people have input, right?

But it's not a democracy. We don't just vote. Um, it's that there's one decision maker who goes and collects information and makes. a plan, a decision. And then, um, I I've, I've found that sometimes if something is blocked, right, you're trying to get a product out the door and you can't figure out why it's not progressing.

Sometimes it's that you don't know who the decision maker is or the decision maker isn't in the room, right? The decision maker hasn't even been involved and everybody's deferring to somebody who hasn't even been part of the conversation. So sometimes what's helpful is to identify a decision maker.

Okay. We're getting blocked. We can't figure out what's going on. Who makes this decision?  Is it me? Is it you? Is it somebody else? And often that will help unblock it. And knowing how the company tends to make decisions is helpful. Because like, oh, okay, well, we need the COO to make that decision. If you know that that's the person who tends to make the decisions, then now you know how to get things unblocked.

Not the question, I think, is just to ask when things seem to be stuck, whose decision is this? And if everybody's kind of looking at each other and nobody knows, Then propose something, say, um, I think it should be the VP of product, or I think it should be the CEO if it's hugely strategic or whatever you think, um, and see what kind of feedback you get from people there.

They might say, oh, it doesn't have to go all the way to the CEO. I think so and so can make this decision. And now you have at least a. a straw man, a potential decision about the decider, um, and you can, and you've, uh, unblocked the situation enough that you can move forward. 

I actually wish I had some of this language now way back when, because I remember I was interviewing.

at a company which had a more participatory culture and coming from a company that are very much a directive culture and they were puzzled by my stories and why I had to like get this permission to get this decision made and I wish I had the language to explain the differences and I think I would have done a lot, lot better then.

It's like, it wasn't that I was being indecisive. It's that this was the culture of the company and this is how we had to get things done when I was there. 

Yeah, exactly. Now, one more thing that, that surprised me in the book was this concept of mining for conflict. And it seems like, Hey, it's the opposite of what product leader should do.

Like why look for conflict? So tell me more about that concept. 

This, um, I borrowed this concept from Patrick Lencioni, who's written a bunch of business books like The Advantage and my favorite is Death by Meeting. And he says that you're mining for conflict, not that you're trying to get people to disagree, but that you're trying to get them to reveal that they disagree so that you can come to a better and more durable and more genuine alignment.

If people feel safe in. Saying in expressing their doubts. Well, what happens if, you know, there's a proposed decision, but the, there are some risks, there's some uncertainties. Uh, can we talk about those? Sometimes people will get to the end of a meeting and just say, Okay, yeah, sure, sure, fine. When they don't really agree, when they have some hidden doubts, and then they won't actually follow through because they, um, they were just saying yes to get out of the meeting at that point.

And you want to uncover those things. You don't want to let people break up the meeting with a decision that's not really made, that looks like it's made, but isn't. And you have what I would call a shallow alignment or fake alignment even. Um, I've been in situations where people say they've aligned. And then gone to their next meeting with their own team and said, yeah, we agreed on these four things.

We're only doing two of them. Just ignore the others. That's a signal that there was fake alignment, that they just said yes to get out of the meeting. And they didn't, in that case, um, I talked to the guy afterward and asked him what was going on with that. And he had to admit he, he didn't feel safe in disagreeing openly in the original meeting.

So we have a bunch of techniques to try to bring out those hidden objections or. worries, Like actually doing a challenge round where everyone in the room is expected to produce one doubt or risk or challenge to the plan, um, for discussion. And so now it's not only safe, but expected that you will say, well, I wasn't going to say anything, but there is this possibility if we don't take care of it.

And a lot of the time we've done this in workshops, A lot of the time what happens is the plan doesn't fundamentally change. From the initial plan after the mining for conflict, but it becomes more robust because you've played out the alternative scenarios and you've put in place some risk mitigation or some refinements to the objectives or the or the plan and now everybody is much more confident that it's achievable.

You go from everybody saying, uh, well, uh, three out of five, I think we, we probably can do this to four out of five, five out of five. Yes, we can definitely do this. 

And there's also, you know, not everybody might feel safe saying it in the meeting. So, you know, look out for people who don't say anything or who seem hesitant and go and talk to them afterwards.

They're like, Hey, listen, you know. I know we came to this agreement in the, uh, in the meeting, but you seemed a little doubtful. Is there anything you want to talk about? Um, if you know that somebody tends to agree to things and then reverse later, you could talk to them before the meeting, right? And try to figure out, Hey, I'm going to present this. 

I want to know your feedback, right? If you have any doubts like it, it's not a final version. We can change it. I, you know, I want to hear what, what you think. Um, so those, those one on one conversations, both before and after are also really helpful to, to you. get at hidden, you know, disagreements. 

Just as you said, before and after one on ones, hugely valuable if you know how to target them to the right people who are likely to have something important to add that won't come out in the meeting, or it's possible to have the meeting devolve into just a complete Argument and nothing gets decided.

I used to work with this, um, software architect who every time some new thing came up, she was exactly like that. She would just argue and, and, and, um, uh, question and, um, be disruptive in the meeting and everybody around the table is just kind of like sitting back going, waiting for the fight to be over.

And the only way I have, I found to diffuse that was to have a one on one. About that topic with her before the team meeting to hash out any concerns that she had and Once she had a chance to be heard, um, and acknowledged, and again, um, her concerns addressed in some fashion, then she became an advocate in the meeting.

And, um, so I was sort of pre mining for a conflict, if you will. 

There's also the idea of, if it's a big decision or a big change, that it shouldn't be a surprise to anybody in the meeting, right? The meeting should be more of a confirmation instead of a presentation. Um, I, I worked with a, a client who, um, we had, we had discussed, he and his team needed more time to do discovery and to kind of validate the things that they're working on the roadmap.

So I said, you know, your, your engineers are going to love you. Here's what I propose. You do a tech deck quarter.  Um, and he's like, actually, that would be super helpful. We have all these things we need to do, and it would give us time to like flesh out and validate the things we want to put in the roadmap.

I'm like, okay, you need to talk to the CEO today about this. And he was like, okay. And then, you know, the next week, oh, we were supposed to have a one on one. It didn't go through. Oh, I forgot to mention it. And so the, the day of the big kind of, you know, first day of the quarter engineering, I think maybe it even already started.

He's presenting this kind of big bang reveal of this roadmap. And of course, everybody has questions. It's the first time they've seen it. And so they're just trying to be helpful and he's taking it as criticism, but the whole thing could have been avoided if he had gone one on one to people in the beginning and said, Hey, I'm considering this change.

Like, do you have any concerns?  

This whole idea of mining for conflict is, is a powerful concept and it plays out more than just in the meeting where you're trying to test. It makes it explicitly bringing out disagreements and talking about them in an emotionless way about, well, the pros and the cons and the risks and the mitigations and so on.

And we're just trying to all together discover the best path forward. It makes, uh, makes for a culture of discussion. Of debate, of transparency, of we're talking about the real stuff that carries over throughout the organization. And I, I think that's, you know, somebody, somebody said, um, the, the person who wins is the, uh, wins the argument is the one that has the most accurate picture of reality.

Well, the more we can bring out all, everyone's diverse points of view, the more accurate and complete our picture is. 

Now, one last question from my side, and now I'm going to like go beyond the book. And since you both work with product leaders all the time, you're coaching them, what are like some of the topics that are top of mind at this point for them?

Well, founder mode is making the rounds right now. This concept that, um, you should. As a founder, not always just be a manager, a technocrat, a, uh, uh, someone who's managing, uh, and overseeing a process, but that you sometimes need to just dive deep and just like make, uh, directive decisions yourself. Um, and so I think there are opinions on, among the people that we work with directly on both sides of that, a whole bunch of VPs of product when that article came out, we're just like, Oh my God, Here we go.

Because their whole job, it feels like, sometimes is corralling founder CEOs who have the idea of the week, right? But that fails, again, the empathy test. Number one, there's a reason that the CEOs are in the position, and the other founders, that they're in. They figured out something good, so they, there's probably a germ of truth in whatever it is that they are doing.

putting forward. And um, number two, I think it's a balance. It's a find the right time and place for founder mode. If you're doing, if you're micromanaging everybody every day, then you're bottlenecking the company. You're making, forcing everybody to go through you for everything. But if you're selective and you're like saying, all right, you know, most things can be done.

Managed by the professionals, but here is the next big thing in for our company and it needs a, an entrepreneur's point of view. And so that's where I'm going to lean in. 

I think what I'm seeing as kind of the biggest thing that people are concerned about is hiring. So if you have an open position, there are hundreds of applicants and what, how do you even begin to go through these things?

Um, and so part of, yeah. Part of what we do in our coaching practice is helping people figure out how to hire. And it's not just like, we just need somebody good. It's okay.  What actually do we need? How do we know what success looks like in this role? Um, and how do we sort of suss that out? What questions do we ask?

Um, and, uh, I, I think it's, You need to sort of define what the role is and what the person's going to do. And a lot of times you actually have to step back a little bit and define product management, especially if they're somebody's hiring a VP or a CPO. It's okay. Is this person really responsible for delivery?

Or is that engineering?  Um, and you know, what, do we need somebody who has experience making a big change? Do we need somebody who has experience growing a team? Do we need somebody who has experience, you know, dealing with, uh, dealing with sales teams or like, what exactly is it that, you know, Is most important in the role.

And, um, sometimes people.  How did they just need to hire somebody and they, they don't have the time cause they have a gap in their team to really think about, go back and step back and think about what this person is really going to do, but it's, but it's important because it helps you make sure you hire the right person, which end up saving time in the long run.

I loved hearing the other side of things because I often hear the candidate side of things that it is tough. It is a tough market, but it's not easy for the hiring managers or hiring team either. They're also trying to figure out the right fit right now. 

I mean, it's essentially trying to make a good match, right?

Like matchmaking. It's, it's, it's hard because there's both sides of it and they need to know what they want in order to figure out whether or not it's a good match. 

And then last, where do people find more about the book about your work? 

Yeah, um, well, you can go to product culture. com. Um, that's where you can find out about the services that we offer as coaches, but we have a website for the book itself.

It's called aligned the book. com. And actually I'm glad you asked because if readers or listeners want to know more about the book, there's a bunch about the book itself there. And there's also some free bonus content. There is. Something that we recommend instead of the org chart, which is we call the stakeholder canvas.

This is where you, uh, organize all of your key stakeholders, what you know about them, what you need from them, what they need from you and keep track of your relationship so that that's available to be downloaded in Excel and, um, Google sheets and Miro. And there are a number of other similar free downloads that we think would be useful.

And you can also buy the book. Just on Amazon and some other places. There's a digital version. There's an audio version. So whatever your particular flavor of consuming books is. I think we, we got it covered. 

For all of them. I love to like switch back and forth. So people could buy multiple ones.

Excellent. Well, thank you so much for being on the podcast. I learned a lot. I'm sure listeners will have learned a lot. Our pleasure. Thanks for asking. Shobit. 

Thanks for having me. 

Hey, be sure to check out our website at intentionalproductmanager. com to see how you can level up in your career.