Stakeholder Management

Everyone has opinions about the product. Sales wants features that close deals. Support wants bug fixes that reduce ticket volume. Executives want strategic bets that impress the board. Marketing wants features that generate press coverage. Engineering wants technical improvements that make the codebase healthier. Every one of these perspectives is legitimate. None of them should individually drive the roadmap.

Stakeholder management is the discipline of gathering input from all of these sources, synthesizing it into a coherent product direction, and making decisions that serve the user and the business while keeping stakeholders informed and reasonably satisfied. It is one of the most time-consuming parts of the PM job and one of the most important.

The Input vs Decision Distinction

The single most important concept in stakeholder management is the difference between input and decision-making authority. Everyone gets input. Not everyone gets a vote.

Stakeholder rights:
  - Share their perspective and data
  - Be heard and acknowledged
  - Understand why decisions were made
  - Be informed about changes that affect them

Stakeholder rights they don't have:
  - Veto power over the roadmap
  - Direct access to engineering's backlog
  - The ability to override product prioritization by escalating
  - Final say on what gets built

This is easy to state and hard to enforce. The PM who does not explicitly establish these boundaries will become a feature factory, taking orders from whoever has the most organizational power.

At Spotify, product teams (called "squads") have autonomy over their domain. Stakeholders provide input through structured channels, but the squad decides what to build. This model only works when stakeholders trust the process, and that trust is earned by PMs who consistently make good decisions and communicate them clearly.

Understanding What Stakeholders Actually Want

Most stakeholder requests are solutions masquerading as problems. Your job is to uncover the underlying need.

What they say:             What they mean:
-----------------------------------------------------------------
"We need Salesforce         "I need deal data visible to the team
 integration."               without copying it manually."

"The dashboard needs         "My boss asks me for numbers I can't
 more charts."               get without asking data engineering."

"We need to redesign         "New users are confused and support
 the homepage."               is overwhelmed with basic questions."

"Can you add bulk            "I spend 2 hours every month doing
 actions?"                    something that should take 10 minutes."

"We need feature             "Our biggest competitor just launched
 parity with [competitor]."   this and three deals are at risk."

When you hear a feature request, ask: "What problem would this solve for you or your team?" Then ask: "How are you handling this today?" The answers will either validate the request or reveal that the real need is different from the proposed solution.

Mapping Your Stakeholders

Not all stakeholders require the same level of engagement. A simple power-interest matrix helps you allocate your limited time.

                    High Interest
                         |
         Manage Closely  |  Keep Satisfied
         (Eng Lead,      |  (CEO, VP Sales)
          Design Lead)   |
                         |
  Low Power -------------|------------- High Power
                         |
         Monitor         |  Keep Informed
         (Individual     |  (Finance, Legal,
          engineers,     |   Marketing)
          junior PMs)    |
                         |
                    Low Interest

Manage Closely (High Power, High Interest)

These are your core collaborators: engineering lead, design lead, and your direct manager. They care deeply about the product direction and have significant influence. Engage them in decision-making, share early drafts, and ensure alignment before announcements.

Keep Satisfied (High Power, Low Interest)

Executives, VP-level stakeholders, and board members. They do not care about daily decisions but have strong opinions about strategic direction. Give them concise, outcome-oriented updates. Do not waste their time with details. When they do engage, treat their input seriously because they often have context you lack.

Keep Informed (Low Power, High Interest)

Customer-facing teams (support, customer success, solutions engineering). They have deep knowledge of user problems but limited ability to influence the roadmap directly. Create structured channels for their input and close the loop when you act on their feedback.

Monitor (Low Power, Low Interest)

Teams that are tangentially affected. A light-touch newsletter or shared dashboard is sufficient. Do not over-invest here.

Structured Input Channels

Ad hoc Slack messages and hallway conversations are terrible input channels. They are untracked, unsearchable, and create the impression that whoever messages you last gets priority. Create structured channels instead.

Effective input channels:

Feature request form:
  - Standardized format: problem, who it affects, frequency,
    business impact, proposed solution (optional)
  - Visible to all stakeholders (transparency reduces repeat requests)
  - PM triages weekly, acknowledges within 48 hours

Monthly stakeholder review:
  - 30-minute meeting with representatives from sales, support,
    marketing, and engineering
  - PM presents current priorities and reasoning
  - Stakeholders share top concerns
  - Not a negotiation session — it's information exchange

Quarterly roadmap review:
  - PM presents the upcoming quarter's plan and the reasoning behind it
  - Stakeholders provide feedback
  - PM publishes final roadmap within one week
  - Changes from the previous quarter are explicitly noted with reasons

Customer advisory board:
  - 5-10 customers who represent your target segments
  - Quarterly calls to understand their evolving needs
  - Direct input from users, not filtered through sales or support

Atlassian runs a structured feedback process where customer-facing teams submit "customer impact" tickets with standardized fields. PMs review these weekly and patterns influence prioritization. This works because the input is structured, visible, and consistently processed.

Running Stakeholder Meetings

Stakeholder meetings go wrong in predictable ways. Here is how to run them well.

Before the meeting:
  - Send an agenda with clear objectives
  - Share any data or context needed to have a productive discussion
  - Identify which decisions need to be made vs which are informational

During the meeting:
  - State the purpose upfront: "This is an input session, not a
    decision-making meeting"
  - Give each stakeholder 2-3 minutes to share their perspective
  - Ask clarifying questions, do not debate in real-time
  - Capture every input visibly (shared doc, whiteboard)
  - Do not promise anything ("I'll take this back and evaluate it")

After the meeting:
  - Send a summary within 24 hours
  - Include what was discussed, what you heard, and what happens next
  - Follow up individually with stakeholders who raised urgent concerns
  - Close the loop when decisions are made, even if the answer is no

The Anti-Pattern: Design by Committee

The most dangerous stakeholder meeting is one where the group designs the product together. This produces incoherent compromises that satisfy nobody.

How committee design happens:
  Sales: "We need a dashboard with deal metrics."
  Support: "Can we add ticket volume to the dashboard too?"
  Marketing: "We should show campaign performance."
  Engineering: "If we're building a dashboard, let's make it
               customizable."
  Executive: "I want to see revenue and churn on one page."

Result: A dashboard with 15 widgets that nobody configured
        correctly and everyone ignores.

The PM's job is to gather input, synthesize it, and make a decision. Not to build consensus on the solution. Consensus on the problem is valuable. Consensus on the solution produces mediocrity.

Managing the Sales-Product Relationship

Sales is the stakeholder group that creates the most tension with product. This is structural, not personal. Sales is measured on revenue. Product is measured on long-term user value. These incentives diverge on time horizon.

What sales wants:                What product wants:
  - Feature X for a specific       - Features that serve all users
    customer                       - Sustainable product architecture
  - Committed delivery dates       - Flexibility to learn and adapt
  - Customization options          - Simplicity and consistency
  - "Just this one thing"          - Focus on the roadmap

Strategies That Work

Maintain a "sales request log" that is visible to both teams. When sales submits a request tied to a deal, capture the deal size, the customer name, the specific problem, and the requested solution. Review this log monthly with sales leadership.

Sales request log example:

Request: Custom reporting module
Customer: Acme Corp
Deal size: $300K/year
Problem: Their compliance team needs quarterly audit reports in a
         specific format
Current workaround: Manual export + Excel manipulation (4 hours/month)
Requested solution: Custom report builder with template support

PM assessment: The underlying problem (compliance reporting) affects
12% of enterprise prospects. A lighter solution (pre-built compliance
report templates) would serve most of them with 20% of the effort.

This approach turns adversarial negotiations ("why won't you build my feature?") into collaborative problem-solving ("how do we address this need for the most customers?").

When to Say Yes to Sales

Sometimes you should build what sales is asking for. The signal is when multiple unrelated deals stall on the same requirement.

Build it when:
  - 3+ independent deals cite the same gap
  - The total revenue at risk exceeds a meaningful threshold
  - The feature aligns with your target market direction
  - The engineering effort is proportional to the business impact

Don't build it when:
  - It's one large deal with unique requirements
  - The feature would complicate the product for all other users
  - Sales hasn't closed the deal even without the feature gap
  - Building it creates a support and maintenance burden that
    exceeds the deal value

Communication Cadences

Consistency beats intensity. Stakeholders who receive regular, predictable updates trust the process more than stakeholders who get sporadic deep-dives.

Recommended cadences:

Weekly:
  - Triage feature requests (30 min)
  - Slack update to core stakeholders: what shipped, what's in
    progress, any blockers

Biweekly:
  - 1:1 with sales lead, support lead, marketing lead (15 min each)
  - Share upcoming sprint priorities

Monthly:
  - Stakeholder review meeting (30 min)
  - Written product update (email or doc): metrics, shipped work,
    upcoming priorities, decisions made

Quarterly:
  - Roadmap review and planning
  - Customer advisory board call
  - Retrospective on previous quarter's priorities vs outcomes

Common Pitfalls

Letting the loudest voice win. The stakeholder who sends the most emails or escalates most aggressively should not get priority by default. Weight input by data and user impact, not by volume or organizational power.
Treating all stakeholders equally. A VP of Sales and a junior account executive do not need the same level of engagement. Map your stakeholders and allocate time accordingly.
Avoiding difficult conversations. Telling a stakeholder "we considered your request and decided not to pursue it because [reason]" is uncomfortable. Not telling them is worse. They will assume you forgot or ignored them.
Making promises in the moment. Stakeholder meetings create pressure to commit on the spot. Resist. "I'll evaluate this and get back to you by Friday" is always better than a premature yes.
Not closing the loop. If a stakeholder submitted a request three months ago and has heard nothing, the process is broken. Even if the answer is no, communicate the outcome.
Becoming a feature factory. If your roadmap is entirely driven by stakeholder requests, you have lost product strategy. Stakeholder input should inform 30-50% of priorities. The rest should come from your own discovery, data analysis, and strategic vision.

Key Takeaways

Everyone gets input. Not everyone gets a vote. The PM synthesizes stakeholder perspectives into a coherent product direction. Create structured input channels to replace ad hoc requests. Map stakeholders by power and interest to allocate your time. Run stakeholder meetings for information exchange, not group design. Manage the sales relationship through a visible request log and clear criteria for when to build deal-specific features. Communicate consistently and close the loop, even when the answer is no. The PM who manages stakeholders well earns the autonomy to make good product decisions.