The 7C’s of Stakeholder Mapping
The 7 C’s to help navigate conflicting stakeholders’ views towards building product…
Over the last decade & a half of building high performing product teams, hiring across hierarchy, managing product managers, collaborating a variety of stakeholders who come from eclectic backgrounds & who are pioneers in their domains / fields to say in the least, an elementary level I’ve noticed a common pattern that seems to hold good universally. The world seems to be divided into 2 major groups.
SAMPLE SPACE 1: who understand the troubles, the hardships, the “lows”, appreciate the need for collaborative work which involves brushing shoulders with XfN teams & navigating stakeholder troubles on a daily basis
SAMPLE SPACE 2: who brush that experience aside terming it as “nothing extravagant” equating it to child’s play
Well, one thing is clear though. For the ones who fit into category (2) there, it could again mean 2 things there:
SAMPLE SPACE 3: they haven’t faced / been through the pervasive problems one’d usually associate with such a multivariate team set-up more so in a fast-paced super-collaborative work environment
(OR)
SAMPLE SPACE 4: they are gifted / born with absolute powers & hasn’t taken them much to gain a mastery over the craft of dealing with stakeholders
And here’s a rough percentage break-up of those groups:
But the percentage of such gifted people (SAMPLE SPACE 4) could be approximated to ~01% although sadly the ones fitting into (SAMPLE SPACE 3) could be a strong ~74% leaving us with ~25% of people constituting (SAMPLE SPACE 1).
And if you happen to find yourself fitting into this (SAMPLE SPACE 1) you may find this post an ideal one.
NOTE: Although one may think that problems stemming from stakeholders is usually associated with the ones who are new into their careers & starting afresh over some of those managerial roles, I have had to deal with many calls from product leaders who have narrated tons of problems (some not so common & totally geography specific) over my mentoring sessions at TPW - Facebook.
Take a step back & analyze this for once. You (if you happen to be playing the product manager’s role) are also a stakeholder. And given that stance, there are some things you strongly believe in, you stand up for & wouldn’t want to budge away from, giving the impression of being tough to work with, not being flexible…
But does that mean you would bend the rules just to accommodate / carry someone’s perspective over?
The answer is an “absolutely NOT”. Isn’t it?
So, if you delve deeper you come to an understanding that it is not about YOU / YOUR beliefs as much as it is about ensuring that the other team members / stakeholders align / fall-in with respect to say, an end goal per se. And that also ought to lead one to a certain point of wisdom which is:
“No Stakeholder ever asks to be MANAGED, in fact they may get repulsive if one tries to. One just ought to do everything one possibly can to get everyone aligned & putting in an honest amount of work towards reaching a given outcome, otherwise things may go haywire & all hell may break loose”.
So, as is evident, it is NOT about managing stakeholders as much as it is about UNDERSTANDING & finding effective ways to COLLABORATE smoothly with them & finding ways to overcome whatever major / minor blockers one encounters along the way.
EACH STAKEHOLDER DOES HOLD A DIFFERENT PERSPECTIVE:
Every stakeholder does head a given team / unit & is only but natural that they would surely carry a unique perspective. It is also true that in many a case the clarity a given stakeholder would have over a certain aspect is paramount given how nobody else, none of the other stakeholders may have a clue about it.
Let’s hypothesize. Post release, product manager is tracking the day-end / session-wide analytics to see healthy patterns of usage amongst the user groups on a daily basis. Given the impression of nothing being altogether wrong with the user groups, the focus could then shift to an alternate GTM route / the next feature build & release. But come the month-end, they are staring at a 25% CHURN given how many didn’t bother to renew their subscriptions.
If you happen to be a product manager, chances are you are going through this strange Deja-Vu moment right now. As you sit there thinking, “yes, been there, done that”, you know exactly where I am heading next.
Factoring each of those stakeholder perspectives (however gruesome one perceives it to be) ought to be a mandatory exercise for every one holding a managerial position, more so a product manager. So, here are a few aspects that I had earmarked over the course of my product / entrepreneurial experiences & have used to my advantage as for working with stakeholders across the org. is concerned.
And, I repeat. There is absolutely no need to manage stakeholders, for a good reason that they are all lateral hires (not freshers in any sense of the word) & are capable enough to understand the gravity of any situation & play to it accordingly. The thing to do is to listen, comprehend, understand what the stakeholder’s stance is, what they believe in & what they don’t, which is why I call it mapping the stakeholders based on the respective understanding of the situation.
And I call them the “7 C’s of STAKEHOLDER MAPPING”.
01) Clarity
When the role the stakeholder plays tends to make a lot of difference in getting to the bottom of understanding & formulating problems at a macro level & elucidating those requirements at a micro level, the clarity some of them may carry about the markets, the users collectively & the targeted user group in particular could be worth a goldmine. And one way to determine the clarity the stakeholder is coming with is:
Ask them to describe the whole problem in detail & on a parallel vein ask a few questions to random user who fits the ICP about the very same thing
Over your product discovery / research, comparing the results obtained as a part of that question there, analyzing them for gaps could help determine the clarity the stakeholder has
02) Criticality
Some stakeholder's perspectives are considered more critical when some aren’t & that could be the truth as for many orgs. When the reasons behind this could be aplenty, it could be down to how that person seems to be right most times given the history pointing to ample success post hitting the direction suggested by that stakeholder. When there’s largely no problem with that, it just doesn’t hurt to factor in the perspectives of the other stakeholders, you never know what relevance could be found there.
Have all the relevant stakeholders voiced their opinion about the problem / issue leading into the strategy / drafting a roadmap?
Can we call for a confidence vote to determine the strength of the strategy / roadmap that was finalized recently?
03) Control
The control the respective stakeholder has over the strategic direction / a given roadmap does make a lot of difference when it comes to the decision of carrying a feature forward. When the belief is that it would work out pretty well if it happens to be coming from someone who has been market-facing, someone with a higher sense of purpose around the org. When determining it may not be that straightforward, one could still ask:
What’s the backstory behind the strategic route / initiative you suggested?
Could you elaborate on the logic leading into your prioritization ?
NOTE: Make sure to ask more follow-up questions to delve deeper into the process / manner in which the suggestion has been made, touch upon the nuances & how the decision was influenced while determining the biases.
04) Commonality
When stakeholders who are market-facing tend to hear a lot of raw emotions given their respective interfaces with the user groups, one can’t just leave behind the ones who are building product like say, Design, Devs etc. When the former lot could get severely influenced by those direct opinions from the users they may / may not augur well for the org. And there could be a few odd times when all of them stakeholders put their finger on one feature that just ought to be built, although this could rarely happen at start-ups given how every other person could be jostling their ideas on to the others. You can confirm that by asking:
How many stakeholders share similar insight about a problem pertaining to a certain user group?
How many stakeholders think that building (x) does make sense right now?
05) Commitment
Sometimes strategy can be dictated totally by the market conditions, usually the competition. When competitors happen to deliver a feature that captures a section of your market share, you are hardly left with a choice but to promise your users possibly the very same feature over your upcoming release, when of course delivering something much better value would add up a lot of brownie points. So, you could kick it off by asking your stakeholders:
Are we bound by external pressure to deliver this (x) feature soon?
Have any of our teams / stakeholders got into promising the delivery of a feature to the user groups?
06) Complication
It is very possible that some of the requests / insights you obtain from the stakeholders could blow the top off in terms of the complexity when they are transformed into strategic initiatives. The complication of the whole requirement ought to play a significant part over dictating strategic direction. And that can be down to just one simple question:
Do we have teams & do they have the knowhow to go about delivering this?
Can we deliver with minimal effort / Can we perceive this as a LOW HANGING FRUIT?
07) Consequence
When there seem to be tons of alternate routes & all of them seem like they would lead to something great, the impact & the magnitude of it ought to be the right parameter to pin on. This also proves to be a great way align every stakeholder because it would force them to think objectively from the user’s perspective primarily. The questions you ought to remember here are:
What would be the consequences of us undertaking this strategic initiative?
What would change for the user base & by what magnitude?