Stakeholder management skill

Stakeholder Management

How product managers build trust, gain buy-in, and manage the complex web of stakeholders who influence product decisions -- without surrendering the team's empowerment to discover and deliver the best solutions.

The Stakeholder Challenge

Product teams operate within a web of stakeholders: executives, sales, marketing, customer success, legal, finance, engineering leadership, and more. Each stakeholder has legitimate interests, constraints, and perspectives that affect product decisions.

The challenge is that stakeholders often come to product teams with solutions ("build this feature") rather than problems ("our enterprise customers are churning because of X"). An empowered product team must navigate this dynamic: respecting stakeholders' domain expertise and legitimate concerns while retaining the autonomy to discover the best solution.

The fundamental tension: Stakeholders want predictability and control. Empowered teams need flexibility and autonomy. The product manager's job is to manage this tension without sacrificing either stakeholder trust or team empowerment.

---

Understanding Stakeholders

Stakeholder Mapping

Before managing stakeholders, you must understand them. For each key stakeholder:

Dimension	Questions to Answer
Role and responsibility	What are they accountable for? What metrics do they own?
Concerns	What keeps them up at night? What risks do they worry about?
Motivations	What does success look like for them? What are they trying to achieve?
Constraints	What limitations do they face? Legal, budget, timeline, political?
Communication preference	How do they prefer to receive information? How often? What format?
Trust level	How much do they trust the product team today? What built or eroded that trust?
Influence	How much organizational power do they have? Who do they influence?

Common Stakeholder Types

The CEO / Executive Team

What they care about: Company strategy, revenue growth, competitive position, investor/board expectations, organizational health.

Common failure mode: The CEO has an idea and shares it with the product team, who interprets it as a mandate rather than an idea.

How to manage: Proactively share strategic context. When the CEO shares an idea, explore the underlying problem: "That's interesting -- what's driving that thinking? Help me understand the problem you're seeing." Then commit to investigating the problem, not necessarily implementing the specific idea.

The Sales Team

What they care about: Closing deals, hitting quota, responding to prospect requests, competitive feature parity.

Common failure mode: Sales promises features to close deals, then pressures product to deliver them.

How to manage: Build a regular feedback loop. Attend sales calls to hear customer problems firsthand. When sales requests a feature, dig into the underlying deal: "Which customer? What problem are they solving? What happens if we don't build it? Would they buy if we solved the problem differently?" Often, the customer's actual need can be met with existing capabilities or a different solution than what was promised.

The Customer Success Team

What they care about: Reducing churn, increasing satisfaction, resolving customer issues, driving adoption.

Common failure mode: CS becomes a feature request aggregation machine, passing along every customer wish without prioritization.

How to manage: Help CS categorize requests by problem severity. Establish shared metrics (retention, NPS). Involve CS in discovery -- they have deep knowledge of customer pain. Create a structured process for customer escalations that distinguishes "this customer wants X" from "this customer has a severe problem that affects many customers."

Engineering Leadership

What they care about: Technical architecture, team scalability, operational reliability, developer experience, technical debt.

Common failure mode: Product pushes for speed at the expense of quality, or engineering blocks product decisions with "it's not technically possible" when the reality is "it's technically hard."

How to manage: Build genuine partnership. Include engineering leadership in strategy discussions. Respect technical concerns about scalability and debt. Negotiate tradeoffs transparently: "If we take the shortcut now, what's the cost later? Is that a conscious tradeoff we want to make?"

---

The Art of Evangelism

What Product Evangelism Is

Product evangelism is the ongoing work of sharing the product vision, strategy, and discovery findings with stakeholders to build understanding, alignment, and trust. It is not a one-time presentation; it is a continuous communication practice.

Why evangelism matters: Stakeholders who understand and believe in the product direction will support team autonomy. Stakeholders who feel uninformed will attempt to control the team through mandates and escalations.

Evangelism Techniques

1. Share the Customer Story

The most powerful evangelism tool is direct customer evidence. When stakeholders see real customers struggling with real problems, their perspective shifts from "I think we should build X" to "how can we help these customers?"

Techniques:

• Invite stakeholders to observe user testing sessions
• Share video clips of customer interviews (with permission)
• Present customer journey maps based on real research
• Quote customers verbatim in presentations and reports
• Bring customers to internal meetings (customer panels, advisory boards)

2. Share Discovery Findings Proactively

Do not wait for stakeholders to ask "what are you working on?" Proactively share:

• Weekly summary of discovery activities and findings
• Key insights from customer interviews
• Prototype test results (what worked, what failed)
• Data analyses that reveal opportunities or problems
• Competitive intelligence relevant to stakeholder concerns

Format matters: Adapt communication to stakeholder preferences. Executives want a one-page summary. Engineering wants technical detail. Sales wants customer quotes and competitive positioning.

3. Pre-Sell Ideas

Before presenting a major discovery finding or strategic recommendation, pre-sell it to key stakeholders individually. This accomplishes several things:

• Surfaces objections early, when they can be addressed
• Gives stakeholders a chance to contribute, creating ownership
• Prevents public surprises in group settings
• Builds coalition support before the formal decision

The pre-sell process:

1. Identify the 3-5 stakeholders whose support is critical
2. Schedule 1:1 conversations to share your thinking
3. Present the evidence and reasoning, not just the conclusion
4. Ask for their perspective and concerns
5. Incorporate valid feedback into your recommendation
6. Acknowledge their input when presenting to the broader group

4. Demonstrate Results

The most powerful form of evangelism is demonstrating results. When teams consistently deliver customer outcomes (not just features), stakeholder trust grows organically.

Build a track record:

• Celebrate outcome achievements, not just launches
• Share before/after metrics for shipped solutions
• Present case studies of discovery insights that led to better solutions
• Acknowledge when discovery findings prevented a bad investment

---

Dealing with HiPPOs

What a HiPPO Is

HiPPO = Highest Paid Person's Opinion. This refers to the pattern where the most senior person in the room makes the product decision, regardless of evidence, data, or customer insight.

Why HiPPOs Are Dangerous

• Senior leaders are typically the furthest removed from daily customer reality
• Their intuition is calibrated to a different era (when they were individual contributors)
• Their authority makes it socially costly to disagree, suppressing better ideas
• Their "suggestions" are interpreted as mandates, even when intended as ideas
• Decisions made without evidence cannot be evaluated or learned from

Strategies for Managing HiPPOs

1. Redirect from Solution to Problem

When a HiPPO proposes a solution, acknowledge it and redirect to the underlying problem:

• "That's an interesting idea. Can you help me understand what problem you're seeing that prompted it?"
• "I want to make sure we solve the right problem. What are you observing that makes you think this is needed?"
• "Before we commit to a specific approach, can we align on what success looks like?"

2. Use Evidence, Not Opinions

Never argue with a HiPPO opinion-vs-opinion. That's a power dynamic you will lose. Instead, bring evidence:

• "We tested this concept with 5 target customers. Here's what we found..."
• "The data shows that 60% of users drop off at this step. We investigated and found..."
• "We interviewed 10 customers who churned. The top reason was..."

3. Propose an Experiment

When you cannot dissuade a HiPPO directly, propose a low-cost experiment:

• "Let's test this with a small prototype before building the full feature"
• "Can we run a two-week experiment with 5% of users to validate the assumption?"
• "Before we commit the full team, let me do some discovery to reduce the risk"

This preserves the HiPPO's authority while introducing evidence-based decision-making.

4. Build Trust Over Time

The long-term solution to HiPPO culture is building enough trust that senior leaders defer to team judgment on product decisions. This requires:

• Consistently delivering results
• Proactively sharing discovery findings
• Being transparent about failures and learnings
• Demonstrating deep customer and business knowledge
• Never being surprised by information the HiPPO already has

---

Building Trust with Executives

The Trust Equation

Executive trust in the product team is a function of four factors:

Trust = (Credibility + Reliability + Intimacy) / Self-Orientation

Credibility

Do executives believe the PM knows what they are talking about?

Build credibility by:

• Demonstrating deep customer knowledge in every interaction
• Presenting data fluently without needing analysts to interpret
• Understanding the business model and financial implications
• Knowing the competitive landscape in detail
• Being honest about what you don't know

Reliability

Do executives believe the PM will follow through?

Build reliability by:

• Setting clear expectations and meeting them
• Proactively communicating when plans change and why
• Never over-promising and under-delivering
• Providing regular, predictable updates (not just when asked)
• Following up on every commitment

Intimacy

Do executives feel comfortable sharing sensitive information with the PM?

Build intimacy by:

• Maintaining confidentiality when executives share concerns
• Being willing to have difficult conversations privately
• Showing empathy for the pressures executives face
• Building personal rapport outside of formal meetings
• Understanding the executive's communication style and adapting

Low Self-Orientation

Do executives believe the PM is focused on the company's success, not personal agenda?

Demonstrate low self-orientation by:

• Advocating for the customer's interest, not the team's convenience
• Acknowledging when a stakeholder's idea is better than yours
• Being willing to kill your own idea when evidence doesn't support it
• Sharing credit generously when things go well
• Taking responsibility when things go badly

---

Structured Stakeholder Communication

The Stakeholder Update

Weekly cadence: Send a brief, structured update to key stakeholders.

Format:

PRODUCT UPDATE: [Team Name] - Week of [Date]

WINS THIS WEEK
- [Outcome achieved or key discovery finding]

CURRENT FOCUS
- [What the team is working on and why]

DISCOVERY INSIGHTS
- [Key learnings from customer research or testing]

NEEDS / DECISIONS
- [Decisions needed from stakeholders, with deadline]
- [Support or resources needed]

METRICS
- [Key metric]: [current value] (target: [target])

The Quarterly Business Review

Present a deeper strategic update quarterly:

1. Results: What outcomes did we achieve vs our OKRs?
2. Learnings: What did we discover that changed our understanding?
3. Strategy update: How does the strategy evolve based on what we learned?
4. Next quarter focus: What problems will we tackle and what outcomes do we target?
5. Needs: What resources, decisions, or support does the team need?

Handling "When Will It Be Done?"

This is the most common stakeholder question, and the most dangerous. The honest answer is often "we don't know yet because we haven't completed discovery."

Approaches:

• For discovery-phase work: "We're currently validating whether this solution will work. I'll have a timeline estimate after we complete user testing in [timeframe]."
• For delivery-phase work: "Based on our current velocity and scope, the team estimates [timeframe]. I'll flag it immediately if that changes."
• For high-uncertainty work: "There are several approaches we're evaluating. I'll narrow it down to a timeline estimate by [date] after our feasibility assessment."

Never commit to a timeline before discovery validates the solution. A premature commitment becomes a constraint that prevents the team from pivoting to a better solution when evidence warrants it.

---

Managing Feature Requests

The Request Processing Framework

When a stakeholder brings a feature request:

Step 1: Acknowledge and explore "Thank you for bringing this to my attention. Can you help me understand the context? What problem are you or the customer trying to solve?"

Step 2: Capture the problem, not the solution Document the underlying problem, the customer segment affected, the severity, and the business impact -- not the specific feature requested.

Step 3: Assess against current priorities Does this problem align with current objectives? Is it more severe than problems the team is already working on?

Step 4: Communicate the decision If pursuing: "This aligns with our current focus on [objective]. We'll investigate it as part of our discovery work." If deferring: "I understand this is important. Right now, our team is focused on [objective] because [reasoning]. I've captured this for future consideration and will revisit it during our next planning cycle." If declining: "After assessment, this problem affects a small number of users and doesn't align with our current strategic direction. Here's what we recommend as an alternative..."

The key principle: Never say "no" to a problem. Say "not now" to a specific priority ordering, and explain why. Stakeholders can accept deprioritization when they understand the reasoning. They cannot accept feeling ignored or dismissed.