Bruce McCarthy: Managing Stakeholders

You’ve got the best plan in the world. You’ve done your homework, you’ve got the strategy. It all makes sense. You just need to execute. Do it right, you’re going to catapult ahead. What could possibly go wrong? Your organization must be aligned with you.

Bruce shares the key techniques to make your plan work by walking you through his framework for stakeholder management. From identifying real stakeholders – it’s not the org chart – to getting inside the heads of those people to find out what they need. Expect actionable ideas, practical tips, and a way of getting people to think differently. You will learn how stakeholders typically match personas that recur in organizations, what to watch out for and ways to manage them.

Understanding how to manage stakeholders is the difference between success and failure in your project or product. It can also mean the difference between being an individual contributor and a leader. Leaders get promoted.

Slides

Transcript

Bruce McCarthy
I’m going to talk about stakeholder management, that’s the official thing. And the last time I talked about this, which I’ve only spoken about publicly once before, was that how to web in Romania. And they changed my title from stakeholder management for product leaders to this, how to make everyone fall in love with your plan. So I hope that I haven’t over promised as a result. One good stakeholder management technique – under promise and over deliver, right? So I’ve already failed. Good way to start.

Introduction

Just a quick introduction, a lot of you know me, I’m that product guy. I wrote this book on product roadmaps. I got where I am today as an advisor for companies all around the world, by doing pretty much every job in or related to product. I’ve been in-charge of officially or unofficially, everything from engineering to partnerships, to marketing, to design, etc. And so, my discipline is kind of seeing how all the parts fit together, or rather, how they’re supposed to fit together and don’t always. As I mentioned, I wrote this book a few years ago with O’Reilly – Product Roadmaps Relaunched, and it’s I’ve been lucky enough that it’s been hit the right time at the, the right place at the right time. That is, and it’s become kind of the standard text on the on the subject, with the secret of this book. And this book success, I think, is that it’s not really about roadmaps. It’s about how to do software. It’s not about how to get your team, all aligned around your vision and your direction. In fact, there’s a whole chapter on stakeholder management. And I’m going to go in deeper than we do in the book on that topic today.

I work with companies all over the world, like I said, this is just a smattering of them today that I have helped or am helping, but it wasn’t always like that. I started off life in my first product management software, product management job with what I would consider an epic fail. A perfectly doomed plan, I describe it as in good BoS fashion, I would like to share that story with you. This is what is now available at a domain called ‘letterbuilder.com’ that was supposed to be the big thing that was going to drive my tiny little software company from product one to product two, and simultaneously get us into this new thing called the internet. And simultaneously get us to going public within a year. I was convinced, my boss was convinced but it did not work out that way. And I’ll tell you what happened. I thought I had done everything right. I knew who the customer was, what the customer’s problem was, I had tested that my solution to the problem was viable for them. And we were a week or two weeks away from launching this awesome rocketship of a new product. And so I went to the VP of Marketing to find out what we could do to promote it. And she said, ‘Oh, congratulations on being ready for the launch, Bruce, what is your marketing plan?’ And I said, ‘What? My marketing plan?’ I’m thinking, aren’t you the head of marketing? I started stammering out some ideas. And it quickly becomes clear that the marketing team has absolutely no intention or interest in marketing this thing. Their plans, their budgets, their people, their programmes are all completely aligned toward the core product of the business and completely committed for the rest of the year. I went from that meeting to the meeting with the head of sales, same story, ‘Comp Plan is fixed for the year. Nothing we can do.’ I got out of that meeting just in time to have a congratulatory lunch that the CEO and the President had scheduled with me for my impending launch. And the first question out of the CEOs mouth was, ‘What are your expectations for the product?’ It was a very quiet lunch. The product went nowhere, because I might have possibly had product market fit. But I didn’t have product company fit. I had thought about the customer, I had thought about the customers problem, but I had forgotten about every other part of the company, other than the engineers who were building it with me. I hadn’t gotten around to one of them to talk about it. Now I had the good fortune of not getting fired on the spot. And working for a guy, John Wang, who went on to become CMO for HTC – the handset maker in Taiwan – who showed me how to do it right. We work together on the next iteration of the core product, and I witnessed him go around and do his shuttle diplomacy and get everybody aligned on a common plan. It was brilliant. And I learned a lot. But in my first experience, obviously, even a good decision with bad understanding from your team is pretty much doomed from the beginning.

Key Insight

The key insight that I want to share with you today, especially if like many product managers, or many entrepreneurs, or many founders, you’re good at dealing with customers, you’re good at figuring out what is the real need behind the stated need, you’re good at doing a customer interview. Use those skills internally, treat your internal stakeholders, just like customers, in terms of figuring out what’s really going on, and what’s really going to motivate them because you need them to be motivated in order for your plan to fly. So I’ve developed this four stage plan for stakeholder management. Actually I was on a call this morning, and people were urging me to call it stakeholder engagement, rather than management, which I kind of like because it isn’t about controlling them more than it is about bringing them into the onto your team. But these are the four stages.

Four Stages of Stakeholder Management

First, you gotta figure out who they are, prioritise them, understand them – that’s critical part – and then you got to lead them toward a destination.

Identification

Let’s talk about these each in turn, identification. The official org chart of your company, even if you drew it yourself as a CEO, or a founder, is probably wrong in some significant ways. In fact, it’s probably worse than useless. It’s kind of misleading. I found this great graphic about the real org chart, right? The real org chart is way more complicated having to do with who’s sleeping with who, what, who has secret back office ties, Who’s mad at who else? Who’s jealous or owes a favour, it’s a mess, right? So how do you navigate the real organisation? Some of you have probably seen this chart, this favourite sort of tool of consultants and product managers, a two-by-two grid that allows you to prioritise your stakeholders according to influence and interest, That is influences whether they can have an effect on whatever it is that you’re managing. And interest is whether they care what happens. And so the people in the upper right hand quadrant, naturally, you’re going to prioritise them. But we’ve taken this a little bit of a step further and put some labels and some descriptors for the personas that typically inhabit these four quadrants. And I call this the Tips framework. First, in the upper right hand quadrant is the actual core team that is working on your product, or your service, or whatever it is that you’re trying to get done. And so they have obviously the power to act or not act, do what you want them to do, or to do something different. So they have great influence. And they have great interest because it’s their project as well as yours. So I prioritise those folks first, when thinking about who my stakeholders are.

Second, though there are outside of your core team, other power players in the organisation, maybe executives, maybe founders who are no longer in an executive role, but still highly influential. May be people in the centralised bureaucracy who can approve or not approve your plan. But anybody who’s may or may not be all that interested in your product or your project or your campaign or whatever, but has the power to say no or yes, or make it much harder or much easier. You need to get to those people too. Then there were those who are impacted by the thing that you’re trying to get done. And whether it’s done well or poorly, think of the customer support team who you may or may not consult, but who’s going to be taking the calls when your first version goes out the door and it’s buggy. Or think about the customers, of course, although we’re talking mostly about internal stakeholders.

And then this, the folks in the lower left who have less interest and less influence are still on my chart, even though technically, they probably don’t have a whole lot of a stake in your thing, are the subject matter experts, because they have information that you need to make good decisions. And so you need to bring them into the fold, treat them like part of the team just as much as, as anybody else on this chart. And also, you want to make sure that somebody who is not currently aligned or in favour of your product, or your project or your launch or whatever, doesn’t go around and find some contradictory information from these subject matter experts. So get to them first. So this is my Tips Framework. And you might be thinking, ‘That kind of covers everybody, doesn’t it?’ And that’s right, everybody potentially, is a stakeholder, your list of stakeholders for whatever you’re trying to get done is potentially everybody in the company, all the analysts, the board, the investors, the customers, you name it. And that’s a lot worse, if you’re not the CEO, most of them don’t work for you. If you are the CEO, you might be thinking, okay, not my problem. But of course, you all know the difference between a really bought in motivated employee who’s going to take ownership and get stuff done on their own versus an employee who is just doing exactly what you tell them, and nothing else at all. That’s a huge difference we’ve been hearing about all week in ineffectiveness. So if you’ve identified the stakeholders, and you’ve realised that there’s a billion of them, what do you do, you got to prioritise? We have to can’t get to everybody. So you’ve got to prioritise those that you’re going to spend more energy up with.

The question is which department really calls the shots at your company? Ask yourself, if the CEO or yourself were in there, what department would step in and make decisions? Sounds like product would be at the top. Maybe this is a self selected audience. Engineering popping up a little bit, sales, finance. I got this same answer from a group of product managers at a poll that I did earlier, and I think you’re all lying. I don’t think product is really calling the shots at most people’s companies. If you are, congratulations. But I’m not surprised to see engineering popping up here. I’m not surprised to see sales fairly far up on the list as well, those are fairly typical. So I’m discounting number one and going to number two. Let’s go back to the slides. There are a whole host of these stakeholders, and I think of them as kind of existing in layers, or have an onion or orbits around you and your core development team that’s working on something in the centre of a solar system or an atom. And I think it’s necessary to map these out and figure out who you’re going to talk to. I know that I, over time, as a practising product leader would gradually make my way out to these departments. And at one company I did I started working with the other product teams, with the execs, with customers, with finance, with loads of other departments. But one of the things you got to do in prioritising is figure out which of these planets and orbits matter most at your company. And at this one company I worked at, I didn’t get promoted, until I started working with sales. I learned by experimentation that the company was really quite sales driven, even though the engineering department was four times as large and was led by an SVP who reported to the CEO. Again, not the real org chart, the sales team, getting noticed by them, helping them that’s what got me noticed and in a enabled my boss, the SVP, to promote me. So that’s one way to prioritise is figure out which department really rules in your company. Then I think supposing you have your shortlist of people that you need to understand. You notice I didn’t say, influence or manage or control. I said, understand, because that’s where it starts. Just like with customers, we don’t go and we do a demo and say our product is awesome, right? We go and we ask them about themselves. So this is the same method that I want you to use with stakeholders internally is seek first to understand. I think the best way to make sure that you’ve understood somebody is to seek a high bandwidth, intimate communications mechanism. And my favourite is face to face one on one, have coffee with people, find an informal intimate setting like coffee or lunch or a beer after work and have an unscripted, unscheduled, unofficial, meeting with them. Drop back to these other lower bandwidth, less intimate communications mediums, once the rapport and the understanding is really established. I’d say synchronous before asynchronous, but I don’t and I don’t mean that in priority. I just mean in terms of like chronology, once you’ve established the relationship, it’s much easier to go asynchronous.

And then I think you also really need to learn to read the room, you really need to learn to read between the lines, and hear what is said, but also hear what is not said. I think that motives are really hard to get directly from people very often, unless everybody is Danish, or Dutch. But if they’re English, good luck. I think you have to infer motives from, from behaviours from what is said, What is not said. And you can also often at least as a first cut, you can infer people’s motives from where they sit in the organisation from their job function, and who they work for. For example, if you are a product person, and you are sharing your roadmap, or your vision or whatever sort of artefact with sales, there are some typical sorts of questions or bits of feedback that you can expect to get like, ‘how is this going to help me close a deal?’ ‘Can I promise this?’ ‘What about the competition?’ And of course, I have a lot of things that I want to see on your roadmap. But the questions are going to be the the opening questions and concerns of engineering are going to be different. ‘This sounds like a lot of work.’ ‘What about the tech debt?’ ‘I would never use that.’ Not that that’s relevant, because you’re not the customer, but engineers are opinionated people. And is there a strategy here? Or will you change your mind tomorrow would be sort of typical of an engineer, and you can anticipate those kinds of questions. Finances also is, ‘will this help drive our numbers?’ ‘When do we start to see ROI?’ ‘And when can I stop paying for all these expensive team members that you that you keep hiring?’

Their legal has their concerns, everybody has their own concerns. And you can start there, or you can listen for the signs that those things might be there in what they say indirectly start with what you know, or suspect about a stakeholder based on their job or your past experience or who they work for. But then spend the majority of the time listening and trying to validate your assumptions with them, or invalidate your assumptions with them. Treat them like a customer, and listen to them in order to get the best understanding.

And this is another reason why I mentioned earlier body language. Body language is huge in communicating. And it’s especially huge I’m finding when you are listening. And one of the techniques that I use a lot is mirroring. That is if someone has a particular posture, if they’re standing like this in a sort of a confrontational manner. Well, I stand the same way. But if they’re more relaxed, then I’m going to be relaxed. I just happen to my wife and I while we were talking about these slides a week ago, and I realised that we were both sitting in exactly the same cross legged position with mirrored knees, my right knee was up her left knee was up, it was weird. But people do that unconsciously, you can do it consciously. You can also do what’s called fronting, which is not just to turn your head towards somebody, but to really bring your whole body to face them if you’re talking to them, and you can make eye contact.

One of the things that I’ve done with my Zoom setup at home is to set up a teleprompter so that the camera is actually behind the Zoom image. So when I’m looking at your image, I’m really looking at the camera and it makes it look like I’m really making eye contact. People have commented on that, that it’s noticeable that I’m doing that on Zoom, because so many of us are looking at a Zoom lens, or on a Zoom looking like this, we’re a little bit off to the side and down, because that’s where that’s where the image is. Leaning in is good to leaning in. But if you’re in a real conversation, people interpret you going like this, to mean I am interested. And that’s a good thing to communicate. The other thing non verbally, again, to sort of reinforce ‘I’m listening, I’m getting you I’m hearing you, I’m validating you’ is the triple nod. We all do this unconsciously. ‘Right. Keep going. Yep. I gotcha.’ – that’s what you’re saying. When you give the triple nod, it’s ingrained in us as behaviour.

Punctuation gestures are good. I do this a lot. And you can mimic other people’s punctuation gestures, if you if you like. And if you want to give them the impression again, that you are on a wavelength with them. Same thing goes for word choice if somebody has a favourite word, I’ll never forget. When I was young, I had some cousins. I’m from the Boston area, it’s wicked cool. But I have some cousins from Atlanta. And when I was a kid, the word for something is good was ‘wicked’. But my cousin’s from Atlanta, use the word ‘tough’ in that accent. And I don’t know why ‘tough’, but that was their term of coolness. And when I said wicked, they looked at me funny. Like, why would you say that? And I tried an experiment when I was 10. I started to use their words. I said ‘Oh, that’s really tough.’ And I said it in their accent, they didn’t notice they passed right by them. Because right at that moment, I was one of them. I kind of thought they’d make fun of me for trying to imitate them. But it didn’t happen. I think it just flew completely over their heads. Speaking style, volume, and cadence, and tone, all of these things actually make a difference. And you can convey your own emotions with them. But you can also match somebody else’s emotions and make them feel like ‘yeah, okay, this person gets it.’

Now, why would you do all of that? Why would you do all that mirroring? Well, you’re trying to understand them, and you’re trying to make them feel understood as well. And so the more you mirror, the more they will reveal, the more they will trust you. And the more you will get the straight story and not have to read between the lines completely, the more open they will be to the possibility of you asking a difficult question and saying, ‘So are you saying something that might be controversial?’ This I find is a super technique for getting buy-in from your engineers. Have those one-on-one conversations, or sponsor those one-on-one conversations between your team and customers. Create that same sort of empathy that you have with your customer, between your customer and your teammates, and set up the this sort of same one-on-one or small group dynamic to have a high bandwidth conversation there. And it will pay off in spades.

And then there’s the leadership part. The leadership part, I think, is probably the most important. Up to now we’ve just been sort of mapping out the territory and doing a bunch of discovery. Like a good product manager doing their market research. But now we have to put a stake in the ground and lead people in a direction. And I think, first, before you decide how to do that, you need to understand your organisation and how they make decisions. This has come up a bunch of times in the past couple of days. Amir mentioned for example, that he’s not fond of consensus driven decision making it takes too much time. And I agree that’s the kind of the slow way to come to a very average, nobody is really happy decision. Think about the last time you tried to agree with your extended family when they were visiting on where to go to dinner. It’s like you end up with the safe option. These other other types of decision making are on this grid, our directive, which is very top down, and democratic, which is completely bottom up, but actually uses literally uses voting most of the time, it’s different than consensus, because every one is expected to go with the majority. Participative is sort of this hybrid approach where someone is meant to drive a decision or own a decision. But they are also required to take input from stakeholders from around the organisation.

I think there is actually at least I have a strong opinion about the one that is most effective in organisations, this notion of the of participative leadership, I think is extremely powerful. It’s more efficient in terms of getting to a decision quickly than consensus. And it’s more effective in terms of getting to a good decision than just top down without a lot of input. Just the rule by hippo, I think is what I would call the directive approach. And I’m not the only one. Bain and Company says that companies that use this participative decision making style, tend to be top performers, have better employee engagement, and have employees who recommend like on Glassdoor. A participative style often improves the speed and quality of decisions.

So sort of putting together, I don’t think stakeholder management is about getting signatures, I don’t think it’s about fulfilling requests from from a queue of customer requests or sales requests or customer support requests. And it’s not also not about having a plan and then just doing objection handling or PR for your plan. I think it’s not reactive, it’s proactive. I think it’s a form of leadership, or it’s an aspect of leadership.

And so my definition of stakeholder management, for my upcoming book on the topic is leading a group of people to do something great, something worthwhile. That’s what stakeholder management is for me. I want to talk a little bit about how to manage that participative process. In the leading section of my framework, and I call this the advice process. In the advice process, somebody has to be responsible, somebody has to have ownership of the outcome you’re looking for, of hurting the cats, if you will, and they need to seek input from those cats. They need to go through the tips framework figure out, prioritise who to talk to and get the necessary input. They have an obligation to do that and then they have an obligation to drive alignment among those stakeholders on the plan. Consensus doesn’t require everyone to buy in. But if you follow this process and you really understood the needs of your stakeholders, and they feel that you have understood and listened to them, they’re more likely to disagree and commit to use a phrase than if you didn’t do that. So this advice process of seeking input enables you to drive alignment much more easily if you own success. And I think Martin Luther King said it well, when he said, ‘A genuine leader is not a searcher for consensus but a moulder of consensus.’ Somebody who’s going to drive toward alignment, in among the key groups, Apple calls it the DRI, the ‘Directly Responsible Individual’. Just like Amir said, Apple’s not the only one, though. They say it is the key contact, or the key decision maker on a project at GitLab. They use the same comment, same concept, every project is assigned to DRI who is ultimately held accountable for the success or failure of a project, they don’t do all of the work. And lots of people who do, actually do the work on a project don’t work for them. Not directly anyway. But nonetheless, they are accountable for the success of that project. The DRI is extremely useful for anything that’s cross functional, because again, you’re influencing across reporting lines, you’re creating a virtual org chart within the official one, complex decisions or projects, which again, require input from a lot of folks, or delegating to somebody who’s close to the data close to the customer, or whatever, is the real source of truth for the success of a project.

Sounds like a typical software, Product Manager sort of job, right? But it applies in lots of different other scenarios, the DRI, their job is to align with leadership on the objectives, the real outcomes, we’re looking for align with stakeholders on metrics and priorities. And it doesn’t say here, but also methods, how are we going to do that, they review all the available data from the subject experts, they seek the best advice from those same experts, they communicate decisions and reasons why, even when they end up disagreeing with some of their stakeholders. And they communicate progress broadly and regularly. It’s really as close to the idea of the product manager as the mini CEO as you can get. In fact, I’m reminded that Jeff Bussgang from Flybridge Capital, came and spoke at an event I was at, and he said that he liked to invest in startups where one of the founders was a former product manager, because it’s the best training, in his opinion. Of course, he’s a former product manager, too, for general management, because you have to learn to lead without authority, before you have the authority. And I think that gets better results.

So I told you at the start of the of my talk about a screw up that I made early in my product management career. And I’d like to tell you a better story. This goes back to the 1940s, actually at Ford Motor Company. This guy, Chase Morsi, had just joined the company. He was in it during the war, he was an analyst with the logistics department of the Army, and helped and the Navy and helped win the war in the Pacific. He joined Ford Motor Company in the product planning department. And he’d been there only, I think, three months, when he discovered that upper management had made the decision to kill off the Ford V eight engine, that from the 1939 or 40, no the 1948 or nine model forward, they were only going to have V sixes and V four engines. And he knew in his heart that this was a mistake. He’d been a Ford driver all his life. And he knew that the differentiator, the reason why to buy a Ford was the very powerful the eight engine and he went to his boss and said, ‘This is a huge mistake. We got to stop this.’ And his boss said, ‘Well, you might be right but your opinion, no matter how passionate is not going to change the direction of the whole company and all these high powered executives.’ So fortunately, his boss said so ‘go get some data.’ And Chase did the first customer survey in the history of Ford Motor Company. And he also went and convened a whole bunch of dealers and asked them all about their perceptions of Ford’s and about the differentiation from the other.

The repeating brands, specifically Chevy. And it turned out that the eight according to these folks, was really the only reason to buy a Ford compared to a Chevy. Chevy’s were slightly cheaper, but they only had a V six. So if you wanted that rumble, you needed the V eight. And that’s why people bought Ford’s, he validated that. But honestly, he knew that that wasn’t nearly enough. So he also went to the procurement department bought a Chevy V six, and had them dismantle it, and price out all the parts. And they discovered that the Chevy V six was actually slightly more expensive to source than the Ford V eight. So the bean counters were actually like, ‘oh, maybe this isn’t such a bad financial decision to keep the V eight, after all’, so he went to finance. And also it turned out manufacturing was working on a way to build the V eight engine even more efficiently. So they figured out that they could produce a Ford V eight, that would out compete the Chevy V six for less total money at a higher profit margin. He went back with all this evidence to the executive team. And in a marathon session, he brought all of these functional experts with him and made his proposal to uncancelled V eight. And at first the executives were pretty like ‘No, no, we’ve looked at this, this is this is a done deal.’ But expert after expert from the customers, the dealers, the procurement, the finance, the manufacturing, all said ‘no no Chase’s, right, we really need to not do this, it’s would be better for the company, if we keep making the VA will make more money.’ They said, and it took all day. But he finally or not he they finally convinced the executives that they had no choice but to listen because he had driven alignment among all of these stakeholders from around the organisation. And you could argue that he saved Ford Motor Company in the process. The V eight went on to be the star player in why people bought the Mustang why people bought the Thunderbird, all the iconic Ford cars that we think about from back in the day. It’s not just cars. You know, it’s universal sort of business reality. And I think following this, these five steps is how to have a much more successful product launch than I did, and how to successfully launch things the way the way Chase Morrissey did.

And if my experience is any indication, figuring out the real org chart, and acting accordingly is also really good for career advancement. I am writing a book and it’s coming out next year from O’Reilly, we’ve already handed over two chapters and full outline. This is the outline, we’re going to cover building trust, establishing roles, speaking the language of different departments, getting to yes, getting to know while still people being happy, and then sustaining buy in over time. That’s the outline. That’s it. That’s it on stakeholder management today. Thank you for your attention.

Mark Littlewood
So questions?

Audience Member
Thank you for wonderful talk to us. I was wondering if we could look at this from the perspective of the hippo. A number of people in this room aren’t necessarily product managers, larger organisations, they are the CEO, the principal, but they would like to have better alignment within their organisation. And to get the people to play nicer with each other. Can you talk a little bit about your experience with best practices that leaders can bring to the table? To enable the framework you’re talking about? just done it?

Bruce McCarthy
I think first and foremost, I would say, and thank you for the question. It’s a good question, I would say, to be open and explicit about this role of about this style of decision making. And if you really do intend to be participative, which many of you at least had the intention to in the poll, to make it official, and say, for any given decision, or project, or product, or campaign, or whatever it is, there’s a DRI, there’s a responsible person, and this person has the authority from you, as a leader, to make decisions on your behalf on the company’s behalf. But also the other, the flip side of it, to seek input, they have to listen to your opinion. They don’t have to go with your opinion. I think being really clear about about your willingness to provide the authority clears up a lot of potential misunderstanding, because a lot of a lot of the time I find this even with my own team. They keep teeing up things to me to decide. And I keep saying to them, what would you do? And they usually come back with a good idea. So I say, Great. What I really should say is, since I’ve learned that they 99% of the ideas are good, at least from my team, is maybe I should tell them just don’t even tell me just do it. That way, I’m not a bottleneck. I think I also why I sent to, to the slack group for the book, early today, a quote that to me summarises a bunch of the talks that I’ve heard this week, which is if you can’t trust your team to make decisions on their own, you probably haven’t been clear about your strategy. Right. I was thinking of Chris’s talk yesterday, I was thinking of Amir’s talk today. A lot of people have essentially been saying that, that it’s hugely. It’s a huge, I was gonna say empowering step. But really enabling step is what I is what I’m thinking to be really clear about what’s important, what direction we’re going in, what is the vision? What is the strategy for achieving the vision, if you do that, over, communicate that and then say, and you are allowed to make decisions within that framework, you’re in charge of this, you’re in charge of that. You might as well have no meetings on your calendar, like a mirror. I really want that calendar. By the way, I have not achieved that. Did that answer your question?

Audience Member
I have an org chart question for you, Bruce. What would you say is the ideal relationship between the top technical person in an organisation whether it’s called CTO, Director of Engineering, whatever, and the top product person. And same question asked a different way, Have you seen organisations where engineering and product are siloed and actually don’t have good integration?

Bruce McCarthy
I’ve seen it a bunch of different ways, one reporting to the other flip to the other way, completely, completely separate. And there’s been a trend over time actually, it used to be that product management reported in to either a CTO or a head of an a VP of engineering, or they reported into marketing. And now they are usually their own department, with a VP or a CPO reporting to the CEO, parallel to the chief technical person who might be a CTO or VP of engineering, or something like that. And I think that’s usually the best answer is that they both have a seat at the table, and they are peers. And that way, neither can really overrule the other, so they must come to alignment. But the exception to that is when they don’t, or won’t or can’t come to alignment, I seen that situation to where there just seemed to be seems to be a fight for dominance between the two. And, you know, you can try to say, dudes, you know, you each have really your sphere and where they overlap you need to align. But that doesn’t always work. And so I’ve been in some organisations where the best answer was, either the CPO is in charge or the CTO is in charge, and the other one works for them. There’s a company I work with now, I don’t see any reason not to say, German company called commenda. Does anybody know this company? One person there. Their CTO is the senior most technical person in the organisation, the VP of engineering, the VP of product and the VP of design, I’ll report to him, Daniel. And that works because of Daniel’s personality. He is the Dr. He’s a perfect example of the DRI certain decisions, He reserves to Himself. But he uses the three of them as sounding boards and input before making a decision. A lot of decisions, he pushes down to them. product, you’re the DRI on priorities. Engineering, you’re the DRI on actually writing, you know, choosing technologies and actually getting it done. And they’re super explicit about those roles, about those sub roles within things. That’s helpful.

Audience Member
Thank you very much for your talk, Bruce. I particularly like the story of the chain, the Romanians changing the title, I can fully understand why Transylvania wouldn’t want people holding steaks. I’m curious to know you talk a lot about the DRI. And you’ve talked about the the old chart, the reward chart and all these people with the power particularly to sort of obstruct rather than to achieve stuff. So my question is, how do you ensure that the DRI has a fighting chance of succeeding and isn’t just the full guy?

Bruce McCarthy
I think there are two techniques. And, I try to use them both wherever possible, what one is in a large organisation, if you’ve got some people who are essentially the gatekeepers or the approvers, like their centralised bureaucracy, like pricing, or finance or legal where you have to get their sign off, even though they don’t really care at all about your product or your project, it can be hard. And so they may or may not be aligned, I tell a story in the book about a situation where I was a product manager and I had a proposal that the pricing department just hated. They just thought it was the worst thing ever. And I use two techniques. One technique was to use the hierarchy. All right, where does this person report? And where does that intersect with where I report. And it turned out that the head of my business unit, who was three, four levels above me was was the only place that they came together. So I appealed to him, and he overruled the pricing guy and have conversation. That also was a learning for me, because I learned also in that in that interaction, the business side, the sales side, because this guy was really effective, effectively, the head of sales was the power player department in that particular company. But at the same company, I also found making friends actually really helps if you make friends in the finance team, the legal team, the pricing team, whatever, whatever teams you think you might need. Friends in the sense of, we don’t just talk about work, friends in the sense of, Hey, you want to grab lunch? I speaking of asynchronous again, at the same company, so a bunch of a bunch of my insights came from my little startup company 75 people being absorbed into Dun and Bradstreet. 10,000 people been around for 200 years now. at a tech company, we also weren’t located at headquarters, our company that was acquired, we were here in Boston, and they’re headquartered in New Jersey. So I found that in order to become real to people, I had to go to New Jersey every week, in order to overcome the fact that they just never answered my emails. Unless, and here’s what I did, I had this finance guy that I really needed to connect with. And he kept ignoring me. So I just turned up at his cube, right before lunchtime, introduce myself and asked him if I could buy him lunch. And he’s, he’s about to go to lunch. What’s he going to do? Say? No? finance guy? Yeah, he’s a finance guy, right? I just offered free food. So that I made friends with this guy, I became a real person, we chatted about nine things. Other than the one thing I really wanted to talk about, which was my finance need. But by the time we got around to that we were buddies. So it wasn’t a big deal. And I made that relationship. And I was able to go back to him. And I was able to have an email conversation with him later once I made friends. So those are the those are the two things use, use that use the hierarchy and make friends. How often did you end up going to lunch with them? I’d say pretty much every time I went to New Jersey, which so it was about once a week. While while we were working on this thing, which was probably six months.

Audience Member
Just reflection of the asynchronous, environment, and stakeholder management. I think it’s actually very critical as well. And even as a founder, I think it’s super critical to actually think about it. And one of the things that you mentioned in your talk, that really resonated with me, was kind of, as a founder, like CEO, you actually have to have buying from the people on hold, any kind of plan that you have. And, you know, in our organisation, so I think something that is very critical, like asynchronous is basically, you need to have a document that outlines the plan or the idea. And then you basically ask people to comment and read that. Like, that is the way you buy in. And then sometimes they say, this is not good. And then you do a meeting with them. But a lot of times, they will just read, provide you some great feedback. And then you kind of have their buying, and then you can go forward with a plan. So honestly, even for founders, this is super critical to kind of understand the dynamic and get the buy in, because even you could as a CEO, you can just say do this. But then, people will not right, be very motivated to do anything. If you do that strategy.

Bruce McCarthy
We tell product managers, think of yourself as being as accountable as the CEO for the success of your thing. Well, I would say to you, founders and CEOs, you might be able to just issue orders. But that’s not likely to get the results that you’re really looking for. So let’s flip that on its head. And I want you all to act like product managers, that is trying to convince people that they want to do what you think is best, as opposed to that they must do what what you’re asking them to do. Figure out what motivates them, understand that do your homework, and figure out what what it’s going to take to get your employees to take ownership of things from you. So you don’t have to do it all. You don’t have to do all the thinking. Right? That’s, that feels like the biggest bottleneck for a lot of growing companies is the CEOs personal bandwidth, which Amir’s might be awesome. But the rest of us with a packed schedule. Probably can’t make as many decisions in a day.

Bruce McCarthy

Founder, Product Culture

Bruce founded Product Culture to help communicate the key principles underlying consistently successful product-focused organizations.

He and his team help companies like NewStore, Camunda, hyperexponential, Socure, and Toast achieve their product visions through Advising, Accelerator programs, and the Product Culture Community. Bruce is a serial entrepreneur and team leader. He literally wrote the book on roadmapping: Product Roadmaps Relaunched: How to Set Direction While Embracing Uncertainty. His next book, Aligned: Stakeholder Management for Product Leaders is expected summer 2024.

His previous talks at BoS Conference have been instrumental in helping our attendees unblock some of the significant challenges that all companies face as they grow. You can watch them here.

Next Events

BoS Europe 2025 🇬🇧

🗓️ 31 March – 1 April 2025
📍 Cambridge, UK

Spend time with other smart people in a supportive community of SaaS & software entrepreneurs who want to build great products and companies.

Save your Spot

BoS USA 2025 🇺🇸

🗓️ To be announced soon
📍 Raleigh, NC

Learn how great software companies are built at an extraordinary conference run since 2007 to help you build long term, profitable, sustainable businesses.

More Details