Stakeholder Alignment: Navigating Their Agenda to Find Shared Opportunities
Stakeholder Alignment: Navigating Their Agenda to Find Shared Opportunities
Don't resist stakeholder agenda. Use them as your competitive advantage.
I have been working in strategy and product for 15 years.
During that time, I have launched products from 0 to 1 at Littlepay, grew and achieved significant double-digit growth revenue across products at PayPal, and built and coached product organisations, hiring and scaling up to 12 squads, most recently at TIER.
The most significant part of my role (apart from coaching / mentoring / ‘people management’) is managing stakeholder relationships and priorities. Often, this gets bundled up into different kinds of questions whenever I speak to a new stakeholder:
how do you manage demanding stakeholders and priorities?
what is your approach to prioritisation ensuring <insert idea> is included?
how do you ensure <stakeholder strategy> can be met amidst a large list of things we ‘need to do’?
…and so on.
I invested so many hours in navigating the best way to align with stakeholders that I once received a gift from a colleague: a trophy of a cat, with the label ‘MVCH- Most Valuable Cat Herder” 🐱!
But do you want to know a secret?
For every domain, problem and stakeholder group, I actually use the same 4 steps to align with stakeholders, with positive feedback each every time.
Technique #1: Map Out Stakeholder Groups and Needs
Sounds daunting at first, but can be truly quick activity with your product leader and teams. Here’s how it works:
Figure out who your full list of key stakeholders are, mapping them by ‘power’ vs. ‘influence’, as per my previous blog post, to understand their stakeholder segment:
Players (Both High Power and Influence)
Subjects (Low Power, High Interest)
Context Setters (High Power, Low Interest)
Crowd (Both Low Power and Interest)
Assign stakeholders (at least) four stakeholder groups, each with different communications strategies (e.g., Collaborate vs. Consult vs. Involve vs. Inform),.
Define more frequent or detailed review points and cadence with your high power/influence stakeholders. Ensure strategic reviews or prioritisation sessions always include Players and Subjects.
Technique #2: Understand Agenda and Evidence
With every stakeholder comes their own agendas (i.e., strategic objectives, or pain points / bug bears) for you you must navigate. Here’s how I do this with ease:
Company Goals: Understand the link between company goals to their departmental objectives
Product Link: Identify which areas your product can contribute to such goals
Evaluate the evidence: For the ideas and initiatives the stakeholder is aiming to deliver or ‘push’, understand the data and evidence there is to suggest their hypotheses are true.
Question yourself: are the data points strong or weak? Are they based on market-sales intent? Or do they come with strong behavioural insights (e.g., based on current usage of product)?
Quick note: Don't simply take sales and market feedback as the only source of data that suggests <feature XYZ> must be built. Always check data quality and rate the confidence of the evidence, using methods such as Itamar Gilad’s Confidence Meter:
Technique #3: Check Alignment in Objectives
This part should be a simple check.
Avoid accepting your stakeholders’ first priority objective as yours.
Evaluate how well their objectives match your product vision and strategy, and your overarching goals for your Product (e.g., in this quarter).
Map out the metrics that your stakeholder cares about, then identify: is it a leading (input) indicator, or a lagging (output) indicator? What product success metrics DRIVE the metrics that they have?
Strong alignment comes from a product success metrics that directly impacts your stakeholder lagging indicator. If you avoid accepting your stakeholder requests based simply on their objectives and match it to your strategy, you’ll automatically levelled up your ‘outcome-based’ delivery product muscle.
Take for example the above set of leading and lagging metrics for an e-commerce retailer looking to improve Sales Revenue:
The Stakeholder wants to drive Sales Revenue to $500k in H2 this year, and suggests to increase Increase Average Order Size through two feature ideas: Increasing Retail Inventory, and 'Adding X% for $Y value’ feature.
Meanwhile, a Product Team wants to increase Average Revenue Per User (ARPU) by X%, driven by card abandonment, payment authorisation and increasing order size.
We clearly see an overlap: Increasing the Average Order Size! In this case, we have a solution idea from a stakeholder that requires the PM to assess the evidence and data that suggests that such ideas would indeed drive value to their shared goals.
Technique #4: Use the ‘Positive No’ framework
Per each stakeholder Segment and Objective, checking against their Evidence and Strategic Alignment, you should be able to do a final segmentation of their ideas into two categories of opportunities:
a ‘Potential Yes’ which may involve negotiation or investigation of whether the evidence is strong enough to suggest some feature / opportunity should be prioritised; or
a ‘Positive No’ which definitely involves either education or rejection (with workarounds)
I wrote in depth about tactfully rejecting feature requests in my previous blog post, so feel free to read through that free resource when you can, to understand how best to say no to your stakeholders.
For those who don’t have the time to read another 5 minutes, just know that the concept originated by leading author William Ury’s book ‘The Power of the Positive No’, which aims to:
Assert and defend your key interests
Make your “No” firm and strong
Resist the other side’s aggression and manipulation
Say “No” clearly, respectfully, and effectively to anyone
Get to not just any “Yes”, but the right “Yes”
So how does one say Yes vs No? Here are some key pointers 👇
The Case for Using a ‘Potential Yes’
In the scenario where there is a high degree of evidence (and confidence behind this evidence) and a high degree of alignment, you should start negotiating with your stakeholders to describe the trade-offs of accepting the request, particularly if you accept it into your backlog immediately. Statements like this come to mind:
“We believe that (this request) is also as important as the other items in our backlog, but we cannot do both at the same time”…
Product managers can also introduce prioritisation methods to decide whether to accept the request now or delay it to another time. This quadrant is essentially a “yes, but…” answer to express the trade-offs. It could be argued that in no other quadrant would you ever say “yes” to the incoming feature request.
Finally, if you do accept a ‘feature’, don’t just take the solution idea on face value. Ensure you use product discovery habits that allows your team to rapidly experiment on how to best validate the problem statement, and also come up with alternative solutions or experiments that also address the outcome you are trying to achieve.
That is, ask yourself:
What is the shared outcome we are trying to drive, and what hypotheses exist?
What problems are being faced by our customers for this <use case>?
What opportunities and solution ideas do we have to <solve pain, create gain> for this use case?
What experiments can we conduct to validate the hypotheses?
What measurements can we take during experiments so we can share and report back to stakeholders which ideas are better and why?
The Case for Using the ‘Positive No’
For those situations you need to reject a request, usually when there is low strategic alignment and low evidence, Ury suggests a “Yes-No-Yes” technique. That is:
Initial Yes — The initial “yes” is a yes to yourself, expressing your own priorities and interests. Saying Yes to yourself allows you to embrace your own interest and importance to build a platform for your Positive No.
Assertive No — The “no” asserts power through respect. This must not be a reactive or angry “no”. It must be a “no” that respects your existing priorities.
Second Yes — The final Yes is for a mutually beneficial relationship with the other party in future. You explore different ways in which you can evolve the situation into something that is mutually beneficial over the long run.
For example:
“I also want our prospective customers to view our company as innovative.
… but building a bespoke report to help them analyse their transactions may not achieve that. From previous interviews, customers have stated that their existing Business Intelligence (BI) tools can achieve the same result in an efficient and innovative manner, when integrating with our <existing API product>.
What if we came up with a few tools to suggest to the prospective customer? Here are some example tools that other customers have used in the past.
I’ve used this template response in almost all feature request escalations that come to me and it works each and every time, with positive feedback from stakeholders who (eventually) understand the reasons, trade-offs, and priorities.
Final Thoughts
Saying no to your stakeholder often always is a scary path for new product managers to the job. When faced with the challenge of a stakeholder who has a loud voice, make sure you arm yourself with the above techniques, as they will give you a stronger profile internally each and every time you justify decision making.
Make sure you have the key tenants:
Segment and Map your Stakeholders via Power vs. Interest
Map Company to Stakeholder to Product Goals / OKRs per Request
Understand and collate Evidence (or, data gaps identified for evidence missing)
Segment your stakeholder’s idea or opportunity via Strategic Alignment vs. Evidence
Use a Positive No or a Potential Yes, depending on the segment.
Good luck!