How To Align Our Stakeholders
Read on my website / Read time: 5 minutes
β
Thank you to our sponsors who keep this newsletter free for the reader:
Why Do Customers Buy Your Product?
Product Managers who understand buyer psychology build better products and look like geniuses to their bosses and customers. Learn buyer psychology in 3 minutes a week.
|
Expert ChatGPT Prompt Guide
Join 600k+ people from companies like Apple, OpenAI, and NASA at the Rundown.ai to get free access to our expert ChatGPT prompt guide.
|
β
When I asked my readers for topic suggestions, stakeholder alignment was the number one request.
Small wonder. Stakeholder alignment is something every product manager has to deal with.
Even newly minted product managers quickly realize how important building alignment is to not only their product's success, but to their own careers.
The reality is stakeholder management is the key to:
- Delivering results.
- Enhancing our impact.
- Unlocking our next career step.
This is true regardless of whether we work at a giant corporation or at a startup.
The challenge, of course, is that none of these people report to us. We can't just TELL them what to do and expect them to blindly accept it.
Yet, they're all looking to us to direct the ship in one direction.
And, like all human beings, they have their own opinions and agendas.
We all know the consequences of stakeholder misalignment:
- Misaligned expectations.
- Lack of direction.
- Failure to deliver results.
- Disappointed customers.
- Demotivated teams.
- Loss of trust with product management.
- Questions around the value product management is bringing.
Stakeholder alignment is a human problem, not a rational one.
When I first started as a product manager, I discovered this wonderful tool called a Prioritization Scorecard.
It was simple. Identify 3-7 criteria, weight each one, score all my backlog items against these criteria on a scale of 1-5, and voila! - a number pops out. The one with the highest score was clearly the top priority, followed by the second, etc.
As a Computer Science major and former software engineer turned MBA, this was beautiful to me. It was logical. It was rational. It was fair. It was simple. It made complete sense.
Except that it never, ever, ever worked that simply.
My scoring was challenged.
My criteria were challenged.
My assigned weights were challenged.
Many simply ignored my beautiful formula and advocated for their own thing.
"Customer X is a bajillion dollar account. Their needs should obviously be top priority."
"We promised the Board we're doing AI this year. Where is that?"
"This approach short-changes technical debt. If we donβt prioritize that, we're going to have an unstable product, and then ALL customers will be impacted."
"What about the list of bugs that Customer Z has been waiting on getting resolved for the last 3 months? They're up for renewal this year, and further delays will jeopardize their relationship with us."
My failure was that I approached stakeholder alignment as a rational problem.
This is common among product managers.
We're problem solvers. We're analytical. We apply critical reasoning. And we're damn good at it.
So it's natural to want to apply this to roadmap prioritization.
If we can just find the right algorithm, we can crack the code.
The reality is that stakeholder alignment is a HUMAN problem.
Which means it's a <cringe> political one.
Stakeholder alignment requires psychology and EQ.
Stakeholder management is about building trusting relationships. Like with any relationship, one of the keys to this is effective communication. Add to that, the need for strong leadership skills.
As product managers, we learn to use empathy and psychology to uncover customer opportunities. We push ourselves to think outside the box to design the best solutions for our customers.
We need to use those same skills to build relationships with the people inside our organizations.
For this issue, let's talk about how we can apply these skills toward stakeholder alignment on roadmap priorities.
Here are 4 things you can do this week to begin aligning your stakeholders:
1. Identify the product objectives.
Start with the company's business objectives. These may be articulated as certain goals, OKRs, KPIs, or other business outcomes. We need to make sure we understand what they are.
Armed with these, take a first stab at what you think the product goals should be that contribute toward the corporate objectives.
For example, at one company I worked at, the bulk of the revenue growth that year was to come from expansion of existing customer account relationships.
That meant the following objectives for our product:
- Supporting new use cases for those customers.
- Supporting certain integrations that would unlock additional revenue.
- Improving the overall product experience (ie, resolving quality issues with the product performance and user experience).
We then identified metrics to measure these that made sense for our business.
The goals for your product may be different, of course. The point here is to:
- Craft goals for our product that align with and contribute toward the top-level company business objectives.
- Identify metrics to measure progress toward those product goals.
2. Socialize the product goals with your stakeholders.
First individually, then collectively.
We want to talk with each stakeholder individually to assess alignment and get buy-in, and then confirm as a group. This is called using "shuttle diplomacy."
This small-to-big approach might seem like it requires a bit more upfront legwork, but it's actually more efficient than having one big meeting with everyone.
- It reduces the chances of having everyone react in the moment all at the same time, especially given it will be the first time theyβll be seeing the recommended priorities.
- It allows each stakeholder to feel like they have a voice in crafting the strategy.
- The Direct-to-Big-Meeting approach has a higher risk of conflicting feedback or of one or two dominating the meeting. This can be harder to navigate, often results in getting less traction, and can risk eroding our credibility.
Admittedly sometimes meeting with each individual stakeholder may not be practical. (Bigger organization, schedules, etc.) In that case, we still want to try to meet with them in smaller clusters before the big meeting with everyone.
When approaching these stakeholder conversations:
- Stress that these can always be changed later, if needed. We just need something in place to get started.
- Take note of the feedback. If there are conflicts, use an authority as a tie-breaker, such as your product executive, CEO, or some other senior executive who can play that role.
- Publish the decision: document it in a Google Doc, Notion page, or some official company space, and then share it out in an email, Slack, or whatever your company uses. This provides the dual benefits of memorializing the decision and providing full transparency to it.
3. Prioritize product initiatives against the agreed-upon goals.
With the product goals agreed-upon, review the various product initiatives we have on our plate and take a first-pass at mapping them to the goals.
Think about:
- Which ones give us the best chance of achieving the agreed-upon goals? Why?
- Are there any trade-offs that need to be considered?
- Which ones don't line up? Are outliers?
We're not talking about lining up each individual backlog item, user story, or Jira ticket to the goals. We're talking about overarching themes.
In the example I shared above, we had over 50 UI related improvements, a number of support tickets and bugs, and some tech debt, sitting in our backlog. Prioritizing each of these against the product goals would have been too much work and, frankly, a waste of time.
Instead, we identified two initiatives called "Improved User Experience" and "Platform Stability". (I know, not the most super clever names. But they got the job done!) Most of those backlog items fit nicely within these two initiatives.
We were able to share a strategy map that looked something like this:
An added benefit here is how this approach began to lend itself toward crafting a product roadmap!
It's ok to have a few items listed as TBD in the first cut. They just mean further research may be required to identify them. They also present an opportunity to invite collaboration from our stakeholders who may have ideas on how to solve for them.
4. Socialize the product strategy with the stakeholders.
Once again, use shuttle diplomacy to align the stakeholders - first individually, then confirm as a group.
What we are NOT doing at this stage is identifying the specific work R&D will do to accomplish these goals, the resources that will be dedicated, and the timelines in which they will be accomplished.
The goal here is to align on which are the key initiatives that will give us the best chance to realize the product goals and, thus, the company objectives.
Once we're all aligned that, yes, these are the most important product initiatives, we can then work with engineering on feasibility to make final roadmap prioritization decisions.
5. Work with engineering to get a sense of feasibility.
We're not getting estimates for every item on our backlog. We're trying to get some sense of the level of effort for the agreed upon initiatives from the previous step.
We're not looking for date commitments at this stage and we don't need exact estimates, nor detailed requirements. We're looking for directional guidance on how much effort these will take.
Exactly how to measure and represent this can vary in each organization. I've found using t-shirt sizing or a rough order of magnitude is good enough for this exercise.
Mainly, we're trying to "draw a line" somewhere, such that those "above the line" are the ones we would recommend deliver the most value and are likely most feasible.
I've often found it useful to represent this via a 2x2 matrix:
The reason I like this is because it at a glance highlights initiatives that are likely worth investing in vs. avoiding.
This is one approach. There are many out there. Use what makes best sense in your context.
The intent here is to get to a final set of proposed priorities for our roadmap that we believe will help achieve the agreed-upon goals.
6. Review the final set of proposed priorities with the stakeholders.
Present the ones most aligned with the foundational goals set in the previous steps.
Highlight any trade-offs based on feasibility.
For example, a stakeholder may argue to prioritize something that's "below the line". Because we've worked with engineering on feasibility, we can discuss with that stakeholder what they would swap from what's "above the line."
When doing so, frame things in economic terms:
"We could certainly prioritize building the new reporting tool. Engineering is estimating that's a relatively large effort and would consume 25% of our quarterly development capacity. That would put projects Delta and Gamma at risk, which are collectively valued at $1.1M in ARR this year. Is that a trade-off we want to make?"
Summary
- Involving our stakeholders to co-create the roadmap reduces the risk of roadmap derailment.
- Gather input and develop our own a point of view. Then use shuttle diplomacy to gain alignment.
- While not providing any guarantees, using a collaborative process provides transparent visibility into how and why we're prioritizing things on our roadmap, thereby making it more likely to help us gain buy-in on our proposals and avoid derailing our roadmaps.
- After all, it's harder for someone to argue against something they helped create! π
Give this a try this week and let me know how it goes.
See you next week.
β