stakeholder-management

name	stakeholder-management
description	Use when you need to update stakeholders, write executive summaries, manage cross-functional relationships, or resolve conflicts with engineering and design.

Stakeholder Management

Manage product stakeholder relationships effectively. Write clear status updates, prepare executive summaries, communicate across functions, and resolve conflicts constructively.

Announce at start: "I'm using the stakeholder-management skill to [purpose]."

Checklist

You MUST create a task for each of these items and complete them in order:

1. Identify stakeholders and their needs — Who cares about what?
2. Draft the communication — Status update, executive summary, or presentation
3. Review for stakeholder language — Is it in their language? Focused on what they care about?
4. Include risks and asks — Don't just report. Ask for what you need.
5. Present and follow up — Close the loop

Step 1: Identify Stakeholders and Their Needs

Stakeholder Map

Stakeholder Group	What They Care About	How to Communicate	Cadence
Executive/VP	Strategic alignment, ROI, key risks, resource decisions	Concise executive summary	Monthly or per milestone
Engineering Lead	Technical feasibility, dependencies, clarity of requirements	Detailed plan + trade-off discussions	Weekly or per sprint
Design Lead	User experience, consistency, design system alignment	Design reviews + user research findings	Weekly
Marketing	Launch timing, competitive positioning, messaging	Feature briefs + launch timelines	Per feature/launch
Sales	Customer commitments, competitive differentiators, availability	Enablement materials + roadmap highlights	Monthly
Customer Success	Feature changes, known issues, training needs	Release notes + support documentation	Per release
Legal/Compliance	Regulatory requirements, privacy, terms updates	Formal reviews of changes	Per significant change
Peer PMs	Dependencies, shared resources, learnings	Informal syncs + roadmap alignment	Bi-weekly

Step 2: The 3-Part Status Update

Use this format for regular stakeholder updates. It scales from a Slack message to a full document.

Part 1: Headline

One sentence. The most important thing to know.

Examples:

• "Feature X is on track for launch next week. Beta feedback has been positive."
• "We've discovered a blocking issue in Feature Y. Now targeting a 2-week delay."
• "Q3 OKRs are all on track. Activation rate improved from 40% to 52% so far this quarter."

Part 2: Key Accomplishments

3-5 bullet points of what was accomplished since the last update.

This period:
• Shipped onboarding redesign to 25% of new users — early data shows +15% activation
• Completed 12 user interviews for the collaboration feature discovery
• Resolved the performance regression (P95 latency back to 1.8s)
• Signed off on design specs for the dashboard v2

Part 3: Key Risks, Blockers, and Asks

What's at risk? What do you need help with? What decisions need to be made?

Risks & Blockers:
• [BLOCKER] API team timeline slipped by 1 week — need to re-plan sprint scope
• [RISK] Analytics contractor leaves end of month — need to prioritize knowledge transfer
• [NEEDS DECISION] Mobile-first or desktop-first for the dashboard? Need alignment by Friday

Asks:
• Engineering: Need 2 engineers for the API integration spike next sprint
• Leadership: Please review and approve the Q4 roadmap draft by EOW

Status Update Template

# [Product/Feature] Status Update — [Date]

**Headline:** [One sentence — what's the most important thing to know?]

## Accomplishments
- [Accomplishment 1]
- [Accomplishment 2]
- [Accomplishment 3]

## Metrics
| Metric | Current | Target | Trend |
|--------|---------|--------|-------|
| ... | ... | ... | ↑/↓/→ |

## Risks & Blockers
- [Risk/blocker with impact and mitigation]

## Next Priorities
- [What's happening next]

## Asks
- [What do you need from the reader?]

Step 3: Executive Summaries

When communicating to executives, use the SCRA framework:

Situation — Context. What's the landscape?

Complication — What changed? What's the problem or opportunity?

Resolution — What are we doing about it? (Present options, recommend one)

Ask — What do we need from you? (Decision, resources, air cover)

Example

Situation:
Our user activation rate has been stuck at 40% for the past 3 quarters.
This is below our target of 65% and the primary reason retention is flat.

Complication:
Research with 20 users revealed that new users are overwhelmed by
the empty dashboard — they don't know what to do first. Competitors
all provide guided setup, which we lack.

Resolution:
I'm proposing a 6-week onboarding redesign sprint. We have 3 paths:
A) Full redesign (8 weeks, highest impact)
B) Quick-start templates only (3 weeks, medium impact) ← recommended
C) In-app tips only (1 week, lowest impact)

Ask:
Approve path B and allocate 1 designer and 2 engineers for 6 weeks
starting next sprint. I need your decision by Friday to hit Q3 targets.

Step 4: Managing Up

Principles for communicating with executives and leadership:

• No surprises — Flag risks and issues early. Bad news does NOT get better with age.
• Speak their language — Business impact, ROI, strategic alignment. Not feature details.
• Be concise — Lead with the headline. Details are for appendices.
• Bring options, not problems — "Here's the situation, here are 3 paths, I recommend B because..."
• Know their priorities — Frame your work in terms of what THEY care about.
• Connect to strategy — Every ask should tie back to a company goal or OKR.
• Respect their time — If you booked 30 minutes, use 25. Send pre-reads.

Step 5: Cross-Functional Communication

Engineering

• Build trust: Understand technical constraints. Don't overpromise to stakeholders what engineering can't deliver.
• Be specific: Vague requirements waste engineering time. Clear acceptance criteria = faster delivery.
• Respect technical judgment: Engineers know how to build. PMs know what to build. Stay in your lane.
• Include engineering in discovery: Engineers present in user interviews = better solutions and fewer feasibility surprises.
• Credit the team: When things go well, it's the team's win. When things go wrong, it's the PM's responsibility.

Design

• User outcomes over pixel perfection: Ship and learn. Don't block on a 2px alignment.
• Design rationale: Understand WHY design made their choices before challenging them.
• Include design in discovery: Designers should be in user interviews, not receiving secondhand notes.
• Speak design language: Learn basic design principles. It builds credibility and speeds collaboration.

Marketing/Sales

• Give them lead time: Marketing needs weeks to prepare launch campaigns. Don't surprise them with "we're launching tomorrow."
• Arm them with evidence: Customer quotes, data, competitive comparisons. Help them sell.
• Don't overpromise: Sales will promise what you tell them. Be conservative in external commitments.
• Protect the roadmap: Sales will ask for features to close deals. Have a process for evaluating these requests.

Customer Success/Support

• Preview features before launch: Support should never learn about a new feature from a customer.
• Document known issues: Be honest about what's rough. Support can set expectations.
• Listen to support: They hear unfiltered customer feedback every day. Mine this for discovery insights.

Step 6: Conflict Resolution

Common PM Conflicts

Conflict	Typical Positions	Resolution Approach
Refactor vs. new features	Engineering wants to refactor. PM wants new features.	Allocate % of capacity for tech debt. Connect refactors to user-visible outcomes.
Design perfection vs. shipping	Design wants pixel-perfect. Engineering wants to ship.	Define "good enough to ship" together. Use design QA checklist. Iterate post-launch.
Timeline pressure	PM pushes for aggressive timeline. Engineering says it'll take longer.	Scope the date, don't date the scope. What must ship by the date? What can follow?
MVP scope disagreement	Different opinions on what's "minimum"	Go back to user outcomes. What's the smallest thing that tests our riskiest assumption?

Resolution Framework

1. Separate people from the problem — Focus on the issue, not personalities.
2. Go back to user and business outcomes — What's best for the user? What moves our metrics?
3. Use data, not opinions — Customer research, analytics, experiments. "I think" is weaker than "the data shows."
4. Make trade-offs explicit — "If we do X, we delay Y by Z weeks. Are we okay with that?"
5. Escalate with context — If stuck, present options with trade-offs to leadership. Don't just drop the problem.
6. Build trust through consistency — Follow through on commitments. Admit mistakes. Share credit.
7. Celebrate shared wins — When the team succeeds, it's because everyone contributed. Say so.

Key Principles

• No surprises — Flag risks early. Bad news ages poorly.
• Bring options, not problems — Show you've thought about solutions before asking for help.
• Speak their language — What matters to an executive is different from what matters to an engineer.
• Be consistent — Regular, predictable communication builds trust.
• Ask for what you need — Status updates without asks are journal entries, not stakeholder management.
• Close the loop — When someone gives you input, tell them what you did with it.

Red Flags

• Status updates that are all good news (unrealistic — there are always risks)
• Surprising stakeholders with bad news at the last minute
• Asking leadership to solve problems without presenting options
• Throwing engineering under the bus for timeline slips
• Overpromising to sales what the product can't deliver
• Avoiding conflict instead of resolving it (it gets worse, not better)
• Taking credit for team wins
• Not following up after asking for input

Key References

• "Crucial Conversations" by Kerry Patterson et al.
• "Influence Without Authority" by Allan Cohen and David Bradford
• "Articulating Design Decisions" by Tom Greever
• "EMPOWERED" by Marty Cagan (chapters on stakeholder management)
• "Radical Candor" by Kim Scott