Research Your Stakeholders Like Your Users

by Kristen DeLap


Product and UX folks ruthlessly research and analyze their users, to great effect. In fact a closing statement of mine in my team meetings is “go talk to your users”. While there is always room for improvement, this is a skill that we all know and employ well.

An artifact of that is often a user map. At its core, a user map is trying to answer questions around what is this person trying to do, what's getting in their way, and what do they actually need (which is often different from what they say they want). You're looking at goals, pain points, context, and behavior. And crucially, you're looking for the gap between what they say and what they do.

In contrast, the traditional stakeholder map, which we've explored before, is mostly about power and interest. Where does this person sit? How much do they care? How much can they affect your work? It's a useful diagnostic. But it's organizational, not human. It helps you categorize people. It doesn't help you understand them.

An interesting move is what happens when you apply the user research lens to a stakeholder. Instead of asking how much power this person has, you ask: what are they actually trying to accomplish this quarter? What are they afraid of? What are they protecting? What do they say they want versus what do they actually respond to? What context are they operating in that you can't see from your seat? Where is the friction in working with you (even if they'd never say it out loud)?

That's user research, but applied inward.

Designers, researchers, and product managers use this kind of curiosity every day. It's a skill. The shift is simply in recognizing that your stakeholders have pain points too. They have constraints you can't see. They have things they're trying to protect. Treating them accordingly - with the same rigor and genuine interest you'd bring to a user interview - tends to change the quality of the conversation. You can stop negotiating and start understanding.


STAND-UP EXERCISE

Choose one stakeholder your team interacts with regularly, perhaps someone whose priorities feel misaligned, or whose feedback is hard to predict, or who you find difficult to bring along.

Using the same empathy map format you'd apply to a user map that stakeholder as a team. Work from what you already know: how they show up in meetings, what they push back on, what they consistently ask for, what seems to matter to them. Note where your knowledge is thin — those gaps are as useful as the answers.

I like to use a virtual whiteboard with the following sections:

  • Says: What are they saying about their expectations, concerns, and feedback? Get direct quotes from the stakeholder. 

  • Thinks: What are they thinking but might not be vocalizing? Consider their worries, aspirations, and priorities. 

  • Does: What do they do in relation to your product? Note the stakeholder's actions and behaviors. 

  • Feels: How do they feel about the product or their involvement? Observe their tone and body language.

  • Hears: What might the stakeholder hear from others that influences their perspective? Feedback from colleagues, market trends, or industry news…

Once you have this, you can begin brainstorming pain points and opportunities. Try to pinpoint specific areas where the stakeholder faces challenges or frustrations. And then highlight areas where improvements could be made to better meet stakeholder needs and expectations, and improve the relationship.

When you're done, sit with the map for a moment. Does anything surprise you? Where are you making assumptions you haven't tested? Is there a conversation you could have, or a way you could frame your next interaction, that accounts for what you now see? Which of the opportunities are you going to take advantage of?

The goal isn't to psychoanalyze your colleagues. It's to bring the same quality of attention to the people inside your organization that you already bring to the people outside it.

Miro board with stakeholder name at top and 7 sections with sticky notes

The Drama Triangle vs. The Empowerment Dynamic

by Kristen DeLap


Within product teams, between product teams, and with stakeholders, there can be conflict. In the 1960’s, an American psychiatrist named Stephen Karpman mapped out three roles that people play in conflict. He created a model that illustrates destructive interaction, and called it the Drama Triangle. (Karpman loved the dramatic arts, and found these archetypes to be roles we play, or masks we put on, in conflict scenarios.)

The Hero

The Hero (also called the Rescuer) wants to save the day. But the action is often a quick fix that makes the problem go away, not a long-term solution. The Hero is motivated by wanting to be right. And this can result in acceptance and praise from others, but their heroics are limited in effectiveness and don’t address the underlying issues. Often a Hero might jump into the middle before knowing all of the facts, so a true solution wouldn’t be possible.

The Villain

The Villain (also called the Persecutor) wants to place blame. They want to figure out who is at fault and throw them under the bus. Occasionally they blame themselves, but more often they point the finger at someone else. Many times the blame goes to an undefined “they”, in the form of blaming “management” or “engineering”. When you are speaking with a Villian, it can often feel like gossip.

The Victim

The Victim is driven by fear. They pursue personal safety and security above all else. Victims can list many reasons why they are the real victim of a person, circumstance, or condition. “I was never trained on that”, “There’s not enough time”, “Nobody is helping”, “I’m not allowed to talk to customers”, etc. The Victim operates from a place of powerlessness and helplessness. Victims will seek help, creating a Hero to save the day, who often perpetuates the Victim's negative feelings and leaves the situation broadly unchanged.

Note: In this model, Victims are acting the part, they are not actually powerless/being abused. But accusing someone else of “playing the victim” and gaslighting them is a classic Villain move!

In 2009, a way to distrupt these interactions was published. David Emerald created The Empowerment Dynamic (TED*) which stops the reactive nature of the Drama Triangle and empowers new roles.

VICTIM > CREATOR

Victims stop thinking “poor me” and become Creators. Victims are reactive - focusing on scarcity, considering themselves powerless, and not seeing choices. Creators, however, claim their own power in a situation and focus on possibilities. Creators take responsibility and look for what they can do to alter a situation.

VILLIAN > CHALLENGER

The Villain stops blaming and becomes the Challenger. Where the Villain points finger about the present situation, Challengers bring new perspectives to others through positive pressure in a way that creates a breakthrough. The Challenger inspires and motivates, a kind of teacher who points the Creators opportunities for growth.

HERO > CoACH

The Hero stops trying to save the day and becomes the Coach. The Coach is a support role, helping others create the lives they want and evoking transformation. Heroes take over and micromanage. Coaches facilitate and encourage. A Coach leaves the power with the Creator, not taking it for themselves.

Shifting to the empowered roles instead of the sabotaging ones has to be a conscious move, but one that can be implemented within a team that has good trust and psychological safety. Conflict and tension will always be present to some degree, but we can better manage it and our reactions to it.


STAND-UP EXERCISE

Present The Drama Triangle and Empowerment Dynamic to your team. Use this 3 minute video to help illustrate. Talk to your team about what roles they most often play, and in which scenarios. One person might always choose the same role, or they may play different roles based on the people or circumstances involved. How can your team support each other when they see the drama roles surfacing?


Identifying Stakeholders

by Kristen DeLap


A key part of product management is managing stakeholders, as most teams require participation, guidance, and approval from a wide range of people across the organization. But oftentimes, product managers treat all stakeholders equally in terms of focus or time expended. A key component to effective stakeholder management is identifying your various stakeholders and grouping them by need. Having this knowledge will help your product team communicate effectively with these groups, and therefore gain early alignment on goals and plans, as well as address any conflict or risk early on.

Often stakeholders can be grouped by their levels of power and interest. A simple two by two can map these out - resulting in four groups: Players, Context Setters, Subjects, and Crowd. (This matrix was popularized by the book Making Strategy: Mapping out Strategic Success.)

The needs of each of these groups are different.

Players
High Interest, High Power
- need to be managed closely
- need high-quality data/insights regularly
- get buy-in on big decisions early
- ask for feedback often

Context Setters
High Power, Low Interest
- need to be kept satisfied
- they can influence the future overall context
- raise awareness with them
- could convert them to players?

Subjects
High Interest, Low Power
- need to be kept informed, "read only" stakeholders
- make use of their interest through low-risk areas of involvement
- "goodwill ambassadors"

Crowd
Low Interest, Low Power
- not worth time to actively manage
- inform via general communications
- aim to move into Subjects

How you interact with these groups in form of the cadence, information provided, and size of audience will all vary. But it is important to keep these general needs in mind, as the more you can tailor communication to gain support or approval from various stakeholders, the more likely your initiatives are to succeed.


STAND-UP EXERCISE

Have your team do a stakeholder analysis by first listing all the groups (or individuals) they know to be stakeholders for your product. Then work to sort these folks into the 2x2 matrix, paying attention to both the level of power and interest. After their needs are identified, the product manager and team can begin to create tailored communication plans, focusing on building and maintaining trust with each of the groups.


Negotiation Tactics

by Kristen DeLap


One of a product managers most used, but perhaps most underrated, skills is negotiation. Almost every conversation a product manager has can feel like a request that needs to be weighed and agreed upon in some fashion. While a product manager can (and should) say “no”, the way in which they get to the no, or verbalize the no, is all about negotiation. It is a key pillar of communication, and one that can affect speed, outcomes, and team morale.

Specific negotiations with a pessimistic developer, or an over-promising salesperson, or an impassioned stakeholder will be different. But there are core strategies that remain the same.

When we think about negotiations, we often think of them as positional - where each party stands in opposition and applies pressure in attempt to get the other to yield. This is most often seen in bargaining transactions, or when someone is talking about “holding a hard line.” However, the better approach is often principled negotiations, where all parties come together as a team to find the best outcome and maintain the relationship. The Department of Product wrote up an informative article that summarizes the findings of the Harvard Negotiation Project on principled negotiations well.

According to the study, there are 4 facets which make up principled negotiation:

  1. People - Try to separate the people from the problem, by focusing on the real issue, not who brought it up. Then be sure to bring in empathy for the multiple perspectives involved, participation from those people, and resist the temptation to get emotional.

  2. Interests - Understand the shared interests, which are common to all parties, and the divergent interests, where they disagree. Also keep in mind many interests can be traced back to security, wellbeing, sense of belonging, recognition, or control, and so try to address these root causes first.

  3. Options - Generating options for an outcome should be separate from deciding, and no option is a bad one when you are just at the brainstorming phase. Then compare and contrast within your list.

  4. Criteria - Attempt to use objective criteria wherever possible in your negotiation to move away from emotional influences. Search for criteria like fair market comparisons, professional standards, scientific judgement or raw data to analyze options.

A product manager even tackling one or two of these strategies in their daily interactions can rapidly move them toward more effective communication. Not every negotiation feels like intense conflict, it can simply be a question of priorities or slightly different goals. Negotiation isn’t inherently a good or bad thing, but getting to the best answer makes a difference for speed, morale, and outcomes. And, importantly, the best answer isn’t winning - it is a result that is good for all involved, takes the appropriate amount of time to get to, and preserves or even strengthens relationships.


STAND-UP EXERCISE

Give a prompt to product managers to ask them about a negotiation conversation they had this week / sprint / cycle. Examples might include - an executive wanted a new feature added to an MVP; do we prioritize working through this technical debt or getting started on this new initiative; the designer wants more time to iterate and the engineers just want to get going; our lead candidate just got another offer for $10K over our budget; do I really need to attend this meeting or can I send another team member…

What went right? What went wrong? Using investigation of the four facets of principled negotiation, where could they have dug in deeper? Be sure to share yourself, as negotiation is not a once-and-done skill, but a learning path for all of us.

A following stand-up could come back to this topic and ask if anyone was able to use these techniques to find a desired or beneficial outcome.

BONUS:
The Prisoner’s Dilemma is a famous game theory problem that shows that single event negotiation is very different from multiple event negotiation. On any given product team, you’ll need to negotiate often, so it is best to stay focused on the long term relationship. Have your team play though this interactive game “The Evolution of Trust” to learn and enact the theory.