[ad_1]
How to manage stakeholders? This beguiling group offer both a bane and a boon to the Product Manager / Owner, so let’s explore ways of effectively engaging them.
Some say ‘everyone’, but that’s not all that helpful.
I distinguish between those you are actively working with constantly in your standard day-to-day, formalised processes, and those who represent distinct groupings inside your organisation who require bespoke partnering arrangements.
Let’s begin by subtraction…
Software Engineers: Your partner Engineering team is typically a core group to liaise with, whom you engage with via standups, retros, demos and so on, so I see these as a distinct group outside of your “Stakeholder” community.
UX is the same, which will be one or more people (hopefully!) that you are engaged with constantly.
Customers — customers will have personas representing the groups/cohort segments. You’ll doubtless be meeting these people weekly at least, or should be. I don’t use the term stakeholder for this group because the way you interact with customers is a well trodden path involving journey mapping, stories, interviews, A/B testing, Net Promoter Score etc etc. I recommend Teresa Torres’ Continuous Discovery Habits to look into how to engage this group.
What does this leave?
… well, it leaves us with ‘the rest’, which includes the various functions and levels within them.
For instance Analytics/Data Science, Marketing, Sales, Finance, HR are common stakeholder groups within an organisation. Together with these core functions will be groups that vary enormously by company — for instance domain specialist functions (e.g. Payments, Customer Success, Master Data Management, market reps by region/country, industry dependent subfunctions etc etc).
So these are the stakeholder groups we’ll talk about in the rest of this article.
Knowing which areas we define as comprising stakeholders does not yet mean we know within those functions/groups who we are going to engage with.
In fact, this simple question requires thought: do you know who to influence? do you know why? Do you know who to keep close, and who to let alone?
You cannot hope to influence and manage all stakeholders, you will drown, so you should ensure you are proportionate and focusing your effort on those that matter most.
Here is a tool to help, called the Power / Interest matrix, developed in 1991 by Aubrey Mendelow. It is a nice, simple way of plotting where someone is in terms of their ability to influence or impact your project/product. If you can roughly approximate someone’s power and interest, in your product, you can map them on this grid. Then gear your engagement accordingly.
Now, we’ve determined who we are going to manage, and whether we are going to engage them actively, or just keep them informed or monitored. Let’s take things further to hone in on those we are going to manage actively — the Keep satisfied group or the Manage Closely group, as defined in the matrix above.
Group and bilateral dynamics
Time and time again I have seen people raise things in groups, which should be handled in direct 1–2–1 calls. My rule of thumb, when dealing with important stakeholder groups (cross-functional or single function), is to minimise contentious topics in such forums. If you have a gripe to raise, about performance in a particular department, or the way someone is behaving on the call, or an approach being proposed, you want to be thinking how to defuse that or circumvent it.
‘Why?’ I hear you say, isn’t it better to tackle it head on? to be courageous?
Whilst I have written on the topic of the importance of courage in the Product Manager / Owner, in group calls the brave thing to do is to use your fine-tuned people skills to circumvent — resist the temptation to go into conflict. I have time and again found conflict doesn’t work, because if you try to confront head-on a requirement or plan or contribution you don’t agree with, which has cropped up in the call, you are likely to get into a heated argument in front of everyone. You might feel courageous and righteous, but the chances are, your thought process is going to be diluted by a toxic mix of hormones triggered by fight or flight, and your logic will suffer as a result.
Let’s say you take to the fight — and you win, well then, you’ve just burned one or more people publicly. That kind of makes you a bully in my eyes, but setting that aside, you’ve certainly burnt a bridge that won’t easily rebuild.
Alternatively, you battle and lose — well, in this case, you look like the one whose logic failed, whose thought process crumpled under the external pressure. Again, a bridge has been burnt, but moreover your proposal is critically wounded and perhaps your credibility.
Perhaps what you took affront to is, in any event, partly or fully correct, and it’s you that’s not thinking straight? how will you know, if your brain is full of anger or fear?
If your neocortex is disengaged by a pint of cortisol pumping it’s way round, then you won’t likely be communicating well. Worse still, is your chest tightening? That won’t help your health long-term.
No, the way to handle such events is to do your best to take them out of the meeting and into a 1–2–1 call afterwards, where you can calmly talk to someone with the logic approach at the forefront. Logic and calm are your friends, so you ask to take things offline, to catchup and deep dive on topics outside the call.
If you need to — ask questions, because good questions can be asked in the right way and don’t necessarily trigger fight or flight modes. But you will have to ask questions with real tact to minimise the conflict.
1–2–1s / Bilaterals
Why do 1–2–1s work so well for this contentious stuff? It’s because group dynamics are different. People will talk in private more calmly, with their neocortex more fully engaged. In a group, behaviors change. For example, defence mechanisms; people are just much more defensive in groups than in 1–2–1s, and so, they are less apt to take in new information that contradicts existing viewpoints, and more prone to confirmation bias.
“In individuals, insanity is rare; but in groups, parties, nations and epochs, it is the rule” — Nietzsche.
For me, bilaterals are the single most powerful tool in stakeholder management. How are they done right? It depends on the stakeholder, and really the best approach is to be chameleon-like.
The chameleon bends their manner of response, of dialogue, of humour, of body-language, to the person they are interacting with. Your goal is to make them feel comfortable, take the edge out of the businessy conversations by asking about their work week, their personal life, make small talk, get to know them, and then move onto more contentious topics to discover whether they are allies or detractors, whether they have a challenging viewpoint or new information to share. Listening attentively, to inputs you have carefully prized from people in a psychologically-safe environment, will give you a huge advantage, and win support for your work and your plans…
…Alternatively, the 1–2–1 will create a psychologically safe place for you yourself to climb down from your high ladder, to see things from their perspective and to discover new approaches or different paths, without a drop of blood on the carpet.
Alliances
Alliances sound like a kind of military tactic, but in reality it’s as simple as it sounds, yet simple things are often difficult to truly master.
If you have grasped the fundamentals of where group arrangements work for you, and where bilateral stakeholder management is needed, you are on the road to naturally forming alliances.
In practise, the usefulness of alliances is in decision-making fora. If you are going into a decision-making meeting of some kind, say for instance a sponsorship sign-off or Vision alignment session, you want to gain allies before you venture into that meeting. Depending on the number of people in the session, you want to be looking at having several solid supporters who can speak alongside you, or more.
You should be trying your very best to avoid the possibility of being an island, being the solo representative of the idea or plan or proposal. This is a dangerous place to be.
I’ve also observed a lot of people go to meetings with the support coming solely from their immediate manager. In my eyes that is the lazy approach, and has a high risk of failure because it places the single point of failure on that manager; if they are sick or away suddenly, you might be on your own, moreover, if it is just you two, that carries so much less sway than if it is a product rep together with another function supporting the proposal.
So my advice is — where there’s a lot riding on the call, hold bilaterals, get support, then venture forward. Do not go into critical meetings alone or with your function only for support.
Tech and non-tech
Some stakeholders are technical, some non-technical.
For the non-technical, your best weapon is analogies. Consider ahead that product work is complex, dense, heavy, dry and often hard to absorb. Non-technical stakeholders need help to be able to comprehend the technical aspects to the work, to empathise with you and the team.
Simple analogies make the most complex of technology questions and approaches easy to understand.
I once had a data issue which was causing complexities in our environment, it was a constant source of pain and whilst we’d put in place various technical means, processes and suchlike to reduce the impact, there were still some data issues occurring at frequency. It was a complex specialist topic that stakeholders struggled to understand. I used a simple analogy that made it come alive for them:
“there has been a flood, and we have dammed it up to stop it happening, but the tap is still running: my proposal is about turning off the tap”.
…People got it, immediately, and engaged in the proposals actively.
Another critical aspect to managing non-technical stakeholders is to use presentation/slideware collateral. I know some organisations are not fans of this, and prefer the written narrative approach instead (a-la Bezos), but there is definitely a place for visualising concepts. The best visualisations of a technology or data flow are simple, colourful, blocky things. The very top notch ones explain themselves with no commentary required. They rarely have much if any text. Needless to say, this puts more weight on the presenter to give context or be ready to answer questions not answered by the distillation the slides provide.
I recommend Slide:ology as a good intro to how to craft good slideware.
Turning to Technical stakeholders, I will admit that as I am a PM from a non-technical background, I initially found this audience very difficult. If anything, in hindsight I wished I had turned to my engineering managers to manage those stakeholders more. Now, it’s different, as my technical knowledge is reasonably solid, from pure experience in the field. But an odd thing has happened — I find myself talking to technical stakeholders less about technology and more about customer/business side events.
Actually, I have come to believe that this is a maturity that comes with time in the Product space…. you speak less about technologies and technological innovation than you do about business and customer problems, about roadmap impact on metrics, about the organisational strategy and where you are on that plan. And this is a good thing, because it brings the technologists up out of the weeds of technical design into the macro/high-level space of business results. You move them from where they naturally inhabit to where they less frequently operate.
So my recommendation for technical stakeholders is simply that, focus on customer and business problems you are looking to solve, and encourage debate about that, leave those who are actually doing the engineering to focus on engineering challenges. If a stakeholder wishes to engage on a more technical level, then can they be redirected to a different group to engage?
Don’t try to be the jack of all trades unless you need to be, Principal Engineers, Engineering Leads and Engineering Managers are there for a reason.
Often, senior technical stakeholders might ask a technical question but what they are really getting at is a much less technical problem or vision aspect to the product, and it’s just about gearing the conversation into that direction.
- Determine who the stakeholders are
- Determine their importance and prioritise your focus
- Circumvent conflict in groups
- Use 1–2–1s for contentious topics and bilateral alliance formation prior to group decisions
- Use analogies for non-tech audiences to describe dense topics or complex detail
- Elevate technical conversations to business outcomes with senior tech stakeholders OR circumvent and redirect to avoid tech detail
I hope people found this useful and would love to hear comments or feedback. Follow me for more like this!
[ad_2]
Source link
