5 Questions on Stakeholders Management with Bruce McCarthy

We talked with Bruce McCarthy, founder of Product Culture, author, and speaker at product management, development, innovation and tech events worldwide.

Here’s some insightful information he shared about stakeholder management, empathy, and decision processes in cross-functional teams.

1. As a product manager you want to “make friends and influence people”. This means asking everyone’s opinion as well. How do you develop a participative feedback process that will not keep things stuck?

I think this is a really insightful question. It’s very easy to get bogged down in constant opinion management. This diagram shows the four decision styles that are typical for different organizations.

There is the directive, top down sort of “everybody just has to follow orders” approach. 

There is the democratic: “we all vote on everything” kind of approach that some organizations prefer. 

There is consensus, where people are always stuck in analysis paralysis, always discussing, and “nobody’s really 100% bought-in” kind of process. All of these have their pros and their cons. 

My favorite method is something that I call the participative method. This method is one where it’s a combination of directive, and consensus; someone owns the decision, a product manager or somebody else, whether that decision is about:

  • taking the product to market
  • which market to take the product to
  • what the feature priorities are
  • when to fix bugs, etc.

But the owner has an obligation to seek input from stakeholders around the organization. Their obligation is not to take a poll; that would be democratic and give the decision to the majority. Their obligation is not to follow the opinion of “the hippo” – the most highly paid person, but to take all of the advice into account and own making the best decision for the company. That’s the participative method.

What makes this method work is what I call “the advice process”. In this process, someone owns the success of an endeavor, a product, a project, or a campaign. They’re required to seek the important input from people around the organization who are impacted, who have a say, or who have good information and good input. Their job is to drive alignment among that group.

Alignment is not the same thing as consensus. Consensus is when everyone just agrees. Alignment is when someone is actually molding or driving agreement; where even if some of the people don’t agree, they’ve been consulted, they’ve had a chance to speak their mind; they’ve been listened to and their point of view validated. But also, the reasons why we’re not going a certain way are explained. When you do that, people are typically willing to disagree and commit. They’re willing to align even if they haven’t arrived at consensus; they’re willing to support and commit to a decision, because you heard them out, even if it wasn’t their idea or their highest preference.

The role that we’re talking about here is often thought of as a product manager’s kind of role. But it could be anybody who has ownership of any sort of decision. This is what Apple would call the directly responsible individual, the DRI for short.

At Apple, when someone is trying to learn the right contact on a project, they’re asked who’s the DRI on that.  At GitLab it’s the same. Every project is assigned to a DRI who’s ultimately held accountable for the success or failure of the project.

The people who work on the project don’t necessarily work for the DRI, but they know that this person owns the decisions. Sometimes that’s even called “owning the D”. 
DRIs are super useful – not as a job title – but as a role in leading an effort or making a decision. They’re really useful for:

  • cross-functional teams, where there are people from different departments
  • complex decisions or projects where a lot of input and information is necessary,
  • delegating decisions close to the data (the customers’ feedback or the business line)

The DRI does all these things:

  • aligns with authorities on the objectives, 
  • aligns with stakeholders on priorities and how things will be measured
  • reviews all the available data
  • seeks all the best advice
  • makes the decisions and then communicates those decisions
  • communicates progress toward the goals broadly and regularly

If we go back to “how do we get opinions”,  well, getting opinions doesn’t mean giving up your decision authority. It means consulting them and getting advice from them. It means always saying, “I’m trying to make my decision, and I need your help to make a good one. I need your input and your insight”.

2. How do you deal with a stakeholder who owns financial decisions but does not have domain expertise and wants to come with input on product decisions? How do you keep them happy while enforcing the best product decisions?

I  think there are three things that you can do:

  1. Fold them into your advice process and make sure that they’re heard and validated, and not excluded from the process because especially if they hold the purse strings, they’re not going to be satisfied with that. 
  2. The second is to agree on who owns different decisions. Ideally, you agree that product decisions have been delegated to the product manager, director, or VP. That person will act as the DRI and use the advice process and make sure that their voices are heard; but that decision is theirs to own. 

A person with the purse, strings, a CEO, a CFO, or whoever, may have the authority to defund your project or your product ,or to fire you. But that’s to be used in extremes where they believe you are simply making wrong decisions one after another. In the meantime, micromanaging you is removing your authority as the DRI.  I think it should be possible to have an open discussion about who owns which decisions. 

The other thing to consider is that the DRI, the product manager and this financial person may have different goals.

  1. The third thing is agreeing what the real objectives of the product, the project, or initiative are. If you agree on what the desired outcomes are, you’ll gain a lot of trust between a non-specialist stakeholder who’s an executive and the product manager who needs to make the decisions. 

If you and they agree that growth is the number one thing, and it’s okay to run at a loss of a certain amount in order to achieve growth, then you’re aligned on the objectives. And it’s a lot easier to agree on the priorities.

Or maybe it’s the other way around. You think it’s growth, but the CFO thinks it’s actually margin. You need to resolve that first; the objectives need to be aligned before priorities, or initiatives, features, roadmap or any other thing. Because you’re operating from different principles, I wouldn’t align only with that one financial stakeholder on what the business objectives for your product are. Ideally, there are other people involved in that decision too.

But if it’s a small company, and it’s the CEO, and they’re calling the shots, then maybe they’re the only person you need to align with.  If you align on those objectives, it’s going to be a lot easier to align on the specifics. 

3. Who are the three most important stakeholders in a tech company based on your experience?

That’s hard to answer, because it’s different everywhere. There are certainly some commonalities, but it depends on size, industry, and the people’s personalities. If you’re trying to make your way around your company’s organization chart to identify the most important stakeholders, I would say that the org chart isn’t very helpful. 

Take a look at this fun diagram from Mark Walsh that shows someone’s attempt at marking up the official org chart with the real information.

Source: Extant Structure by Mark Walsh from Integration Training (integrationtraining.co.uk)

As you can see, in a typical organization, it’s a mess. And the information that’s written between the lines is more important than in the black and white part of the org chart. I tend to think that the real org chart has nothing to do with the official hierarchy like you’d see in a PowerPoint slide. 

The real organization chart is the people you care about, who can influence your product or project. I think you can map them on a two by two grid of influence vs. interest. Ask yourself: how much power do they have in the organization to make a decision or influence a decision vs. how interested are they in what you’re doing?

That’s fairly typical when thinking about stakeholder mapping. But I’ve taken a little bit of extra time and named each one of these quadrants. 

I think that the people in the upper right hand quadrant of high influence and high interest are primarily your team. That is the team that’s actually doing the work to build and support and maintain and host your product, the people who are contributing as part of their full time effort to it. 

You should consider their concerns, their influence, and their advice. First of all because they have the power to build or not build what you want, and they have the interest because they’re working on it every day, all day. In addition, there are other power players within the organization, the CTO or the CFO or someone else. This is also a part that really varies by organization. 

Better questions here would be: “who could shut us down if they didn’t like what we were doing?” Even if they don’t have the official org chart or straight line reporting relationship to do so. Who could say: “we’re not doing that”, or could whisper in someone’s ear that we shouldn’t do that. Who does the CEO have breakfast with would a good question to answer. 


Another question would be: which executives or which departments ask the most questions in product feedback sessions? If push comes to shove, do we work on something that’s going to help us close a deal this month? Or do we work on roadmap items? Answers to these questions will give you clues as to where the power lies within the organization outside of the people who are actually working on your product day to day.

I think it’s also important to consider people who may not have a lot of influence, but who are impacted strongly by your product. This may be the QA team, or the customer support team – those people are going to be highly impacted by whether or not you have something that customers can easily use and understand. Your customers, of course, fall into that category, but we’re thinking mostly about internal stakeholders here. 

Don’t forget about thought partners, channel partners or implementation partners!  Those folks have high interests as well.  Although they’re outside the company, they may not have a lot of power. 

Then, the last quadrant is people with low influence and low interest, but who may have critical information that will help you make good decisions as the DRI. They  could be experts within your company, like the legal team, the finance team, or the HR team. And sometimes, watch out for this: they can be power players! The legal team can shut down this partnership and that OEM (original equipment manufacturer), the use of open source software – all sorts of stuff – if you don’t make sure that you’ve considered their interests. 

The same goes for finance; they may be able to approve or not approve your pricing, for example. So, make sure you understand what the power dynamic is there. Do they advise or control these things? In either case, make friends with them just like any others, and make sure whether they fall into the power player camp or the subject experts camp. 

4. What’s the solution when empathy is not an option, because you don’t agree or trust the other person, or you have different data or you have a different belief?

I’m going to challenge your premise and say that I think that empathy is always an option. You should first seek to understand. You may have other data, or another opinion. You may not agree, but you should seek to understand their point of view to the best of your ability and be able to explain it sympathetically. 

Even if you don’t agree, or you have contradictory data, this will help them trust you that you’re an honest broker who has understood them. If they trust you, it’s going to be easier for you to trust them as well. 

Take the time to validate – not that you agree – but that you understand. Take a moment to simply summarize or repeat in your own words what you’ve understood from them, even if you don’t agree. Then, take the time to explain why you don’t agree. 

Say something like: “I have some information that you didn’t have, some contradictory data. I know you’re saying that this is really important, because you’re hearing it from many customers. But here’s the data of the entire customer base. We actually just did a survey on this. You’ve talked to four customers and they all said that they wanted “x”. But the survey of 1,000 customers say that you somehow have coincidentally run across a pocket of almost the only ones.

That’s the sort of conversation that you can have, but only after you’ve heard them out, and have been honestly curious about their point of view, their data and their sources. Maybe they have some information that you don’t have about the situation. Maybe there’s been a change in the market that is driving interest in this thing. And that’s why all four of their most recent conversations have brought up this topic that the survey last month did not turn up. 

Regarding the possibility of not trusting the person, I strongly feel that you should default to trust,  but verify. Have a conversation where you can see that you all agree on the same objectives, the same data. So logically, you all know what you should prioritize. If they don’t agree, you can ask: “can you explain to me why you’re thinking of something else?” Seek to understand their real motivations. 

If their real motivations are different from what you’re saying, they will either come out, if they feel safe sharing with you what their real motivations are. Or they’ll become obvious to you because they’re making some illogical connections between goals and facts. When someone’s argument from a common set of facts doesn’t really make sense, that’s a clue that there is more you don’t know about their motivations. 

In those situations, I would do one of two things. First, I would actually try to draw them out on that. I would try to say: “if I were you, in your situation, (say in sales), I would be trying to close business this month, too. Even if that’s not the best thing for the roadmap, overall, I totally get it. It’s okay that you feel that way, it makes sense. I hope you’ll also understand that I need to prioritize, not what’s going to close one deal, but what’s going to close lots of deals.”

They may appreciate that you’ve laid it out on the table for them, even if they can’t quite admit it themselves. And there are many perfectly understandable, valid reasons why people might want something that you’re not going to agree to. It can affect their bonus, their team, or their budget. You can be sympathetic with them and have empathy. You can offer to help in other ways than changing the roadmap, like talking with their customer.

And if you display that empathy, they may be so relieved that you were willing to name the nameless. Then, the problem of trust goes away. 

If you really cannot get them to act in a consistent, ethical way that displays integrity, like they tell you one thing, and then they go back and tell their team or their department or their boss something else. If they do this consistently, regardless of whether you do everything that I’ve just said to try to build a relationship, then you cannot trust that person. 

If that person is not in a position of power, I would simply isolate them, and not include them in your process any more than you have to. If that person is in a position of power, if they’re your boss, or in your direct chain of command, or  have a great deal of influence on your project or product and you cannot trust what they say, maybe you shouldn’t be working at that company. In any case, it’s going to be difficult for you to do a good job. 

5. Negotiations in stakeholders management – what’s the most effective approach for good long term results?

I don’t like the word negotiation in stakeholder management, or in a product context. I prefer the word collaboration, collaboration to arrive at alignment. Negotiation implies that you each have power, and you’re trying to agree on a price;  I’ll do this for you if you’ll do that for me. That’s not how the DRI or the advice process works. We’re a good team within a company.

The way it works is we’re all trying to meet our common goals. And let’s align on what those goals are first. And then let’s agree, let’s brainstorm, and discuss the best ways to reach those goals. 

I don’t want to be in a situation where I have a different goal than what you have. That’s a recipe for having to negotiate. That’s a recipe for win-lose logic, and I want a win-win logic. The logic I want is for us to collaborate to find the best possible solution for the company and for the product. 

Sometimes you disagree. That’s fair. But I don’t want to split the difference when you disagree. I want to find the right answer for the company. If you want to change the pricing and the pricing czar within the company says no, that’s not a question of negotiation. They’re always going to say “no” to something that doesn’t follow their policies.

Then it becomes a question of “are you going to comply or are you going to escalate it to a higher authority”. I think it should be collaboration first, and then escalation if it doesn’t work.