Stakeholder Management

Understanding Stakeholders

Stakeholders are anyone who has interest in or influence over your work. Managing them effectively is critical for design success—great design that doesn't get shipped is worthless.

Types of Stakeholders

  • Executives: CEO, CPO, CTO (strategic direction, budget)
  • Product Managers: Feature prioritization, roadmap
  • Engineering: Technical feasibility, implementation
  • Marketing: Go-to-market, messaging
  • Sales: Customer needs, competitive intel
  • Customer Success: User pain points, feature requests
  • Legal/Compliance: Regulatory requirements
  • Users: Ultimate stakeholders

Stakeholder Mapping

Power-Interest Matrix

High Power, High Interest High Power, Low Interest
Manage Closely
Frequent updates, deep involvement
Example: Product VP		 Keep Satisfied
Regular updates, minimal detail
Example: CFO
Low Power, High Interest Low Power, Low Interest
Keep Informed
Share progress, gather input
Example: Customer Success team		 Monitor
Occasional updates
Example: Legal (unless compliance issue)

Example: Redesigning Enterprise Dashboard

Stakeholder Map:

  • High Power/High Interest: VP Product, Engineering Lead
  • High Power/Low Interest: CEO (cares about outcome, not details)
  • Low Power/High Interest: Sales team (will use in demos)
  • Low Power/Low Interest: HR (no direct impact)

Strategy:

  • Weekly syncs with VP Product and Eng Lead
  • Monthly exec summary for CEO
  • Bi-weekly demos for Sales
  • No specific engagement with HR

Building Relationships

Relationship Building Tactics

  • Regular 1:1s: 30 min monthly with key stakeholders
  • Understand Their Goals: What are they measured on?
  • Speak Their Language: Business metrics for execs, technical details for engineers
  • Share Early: Involve them before decisions are final
  • Give Credit: Recognize their contributions publicly
  • Be Reliable: Deliver what you promise, when you promise

Example: Winning Over Skeptical CTO

Situation: CTO didn't value design, saw it as "making things pretty"

Approach:

  1. Understand Perspective: Asked about his concerns (worried about engineering time)
  2. Speak His Language: Framed design in terms of reducing technical debt
  3. Show Impact: Shared data on how design reduced support tickets 30%
  4. Collaborate: Invited to design reviews, valued his input
  5. Quick Win: Redesigned internal tool engineers used, improved their workflow

Result: CTO became design advocate, increased design team budget 50%

Communication Strategies

Tailoring Communication by Stakeholder

Executives

  • Format: Executive summary, 1-pager
  • Content: Business impact, metrics, ROI
  • Frequency: Monthly or quarterly
  • Example: "Redesign increased conversion 15%, projected $2M annual revenue"

Product Managers

  • Format: Detailed docs, prototypes
  • Content: User insights, design rationale, trade-offs
  • Frequency: Weekly syncs
  • Example: "User research shows 60% struggle with checkout, here's proposed solution"

Engineers

  • Format: Specs, Figma files with annotations
  • Content: Technical details, edge cases, responsive behavior
  • Frequency: Daily during implementation
  • Example: "Button states: default, hover, active, disabled, loading"

Example: Airbnb's Design Review Process

Stakeholder: CEO Brian Chesky

Format: Weekly design review

Presentation Structure:

  1. Context (2 min): What problem are we solving?
  2. User Research (3 min): What did we learn?
  3. Design Solution (10 min): Walk through design
  4. Prototype Demo (5 min): Show it working
  5. Metrics (2 min): Expected impact
  6. Discussion (8 min): Feedback and questions

Key: Always start with user problem, not solution

Managing Expectations

Setting Clear Expectations

  • Timeline: When will it be done? (with buffer)
  • Scope: What's included and what's not?
  • Quality: What level of fidelity?
  • Involvement: When do they review?
  • Decision Rights: Who has final say?

Common Expectation Mismatches

  • "Can you just make this quick change?" (Scope creep)
  • "Why is this taking so long?" (Underestimating design time)
  • "This isn't what I expected" (Not enough check-ins)
  • "We need to ship tomorrow" (Unrealistic timeline)

Prevention: Overcommunicate early, document agreements, regular check-ins

Example: Managing Scope Creep

Situation: PM keeps adding "small requests" mid-project

Response:

  1. Acknowledge: "That's a good idea"
  2. Quantify Impact: "Adding that will take 2 weeks"
  3. Offer Trade-off: "We can do that OR feature X, not both"
  4. Document: Update project scope doc
  5. Escalate if Needed: Involve manager if PM insists

Result: PM understood trade-offs, prioritized better

Handling Disagreements

Disagreement Resolution Framework

  1. Listen First: Understand their perspective fully
  2. Find Common Ground: What do we agree on?
  3. Present Data: User research, metrics, examples
  4. Propose Experiment: "Let's test both approaches"
  5. Escalate Thoughtfully: Involve manager if stuck
  6. Disagree and Commit: Move forward even if you disagree

Example: Design vs Business Conflict

Situation: Sales wants prominent "Request Demo" button, designer thinks it's too aggressive

Sales Perspective: "We need more demo requests to hit quota"

Designer Perspective: "Aggressive CTAs hurt user experience and brand"

Resolution:

  • Common Goal: Both want more qualified leads
  • Data: Looked at competitors, analyzed user feedback
  • Compromise: Prominent but tasteful CTA, tested 3 variants
  • A/B Test: Measured demo requests AND user satisfaction
  • Result: Found design that increased demos 20% without hurting NPS

Presenting to Executives

Executive Presentation Structure

  1. The Ask (30 sec): What do you need from them?
  2. The Why (2 min): Business context and opportunity
  3. The Solution (5 min): Your recommendation
  4. The Impact (2 min): Expected outcomes and metrics
  5. The Plan (1 min): Next steps and timeline
  6. Q&A (10 min): Address concerns

Executive Presentation Tips

  • Lead with Conclusion: Don't make them wait
  • Use Visuals: Show, don't just tell
  • Know Your Numbers: Be ready for financial questions
  • Anticipate Objections: Prepare responses
  • Be Concise: Respect their time
  • Tell Stories: User anecdotes are memorable

Example: Pitching Design System to Board

Audience: Board of Directors (non-designers)

Presentation:

  • The Ask: "$2M investment in design system over 2 years"
  • The Why: "Inconsistent UX hurting brand, slowing development"
  • The Solution: "Unified design system like Airbnb and Uber"
  • The Impact: "30% faster development, $5M savings, better UX"
  • The Plan: "6-month build, 6-month rollout, 12-month adoption"

Result: Approved full budget, became strategic initiative

Influencing Without Authority

Influence Tactics

  • Build Credibility: Deliver consistent results
  • Find Champions: Allies who advocate for you
  • Use Data: Research and metrics
  • Tell Stories: User narratives are persuasive
  • Make It Easy: Reduce friction for stakeholders
  • Give Credit: Share success with others

Example: Changing Company's Design Culture

Challenge: Engineering-led company, design had little influence

Approach:

  1. Quick Wins: Redesigned internal tools engineers used daily
  2. Show Impact: Measured productivity improvements
  3. Build Relationships: Paired with engineers on projects
  4. Educate: Lunch & learns on design thinking
  5. Find Champions: Engineering manager became design advocate
  6. Scale: Success stories led to more design investment

Timeline: 18 months from low influence to design-led culture

Result: Design team grew from 2 to 20, design now in C-suite

Managing Up

Managing Your Manager

  • Understand Their Goals: What are they measured on?
  • Make Them Look Good: Your success is their success
  • No Surprises: Share bad news early
  • Bring Solutions: Not just problems
  • Ask for Feedback: How can I be more effective?
  • Respect Their Time: Be prepared, be concise

1:1 with Manager Structure

  • Project Updates (10 min): Progress, blockers
  • Help Needed (5 min): Where you're stuck
  • Strategic Discussion (10 min): Bigger picture topics
  • Career Development (5 min): Growth and feedback

Stakeholder Communication Cadence

Communication Schedule

  • Daily: Engineering team (during implementation)
  • Weekly: Product Manager, direct manager
  • Bi-weekly: Cross-functional partners
  • Monthly: Skip-level manager, key stakeholders
  • Quarterly: Executives, board
  • Ad-hoc: Major decisions, blockers, crises

Example: Spotify's Communication Rhythm

Daily: Squad standup (15 min)

Weekly: Design critique, PM sync, manager 1:1

Bi-weekly: Chapter meeting (designers across squads)

Monthly: All-hands, design showcase

Quarterly: OKR planning, strategy review

Result: Everyone aligned, no information silos

Crisis Management

When Things Go Wrong

  1. Acknowledge Quickly: Don't hide problems
  2. Assess Impact: How bad is it?
  3. Communicate Plan: What you're doing to fix it
  4. Execute: Fix the issue
  5. Follow Up: Confirm resolution
  6. Learn: Retrospective to prevent recurrence

Example: Launch Day Bug

Situation: Major redesign launched, critical bug found

Response:

  • Immediate: Notified all stakeholders within 30 min
  • Assessment: Bug affected 10% of users, workaround available
  • Communication: Hourly updates to stakeholders
  • Fix: Hotfix deployed within 4 hours
  • Follow-up: Post-mortem, process improvements

Outcome: Stakeholders appreciated transparency, trust maintained

📅 Evolution of Stakeholder Management

Pre-2000: Top-Down Approval

Example: Traditional corporate hierarchies

  • Designers presented to executives for approval
  • One-way communication (upward)
  • Formal presentations and sign-offs
  • Limited stakeholder involvement
  • Design decisions made by HiPPO (Highest Paid Person's Opinion)

Pre-2023: Collaborative Engagement

Example: Agile product teams

  • Regular stakeholder check-ins
  • Design reviews and critiques
  • Cross-functional workshops
  • Stakeholder mapping and analysis
  • Two-way communication and feedback

2023+: Transparent & Async

Example: Public design docs, Loom videos

  • Public design documentation
  • Async video updates (Loom, Figma)
  • AI summarizes stakeholder feedback
  • Real-time collaboration in design tools
  • Stakeholders self-serve information

Fun Fact

The "stakeholder" term comes from gambling, not business! In the 1700s, a stakeholder was someone who held the bets (stakes) in a gambling game to ensure fairness. The business meaning emerged in the 1960s when management theorist R. Edward Freeman argued that companies should serve all stakeholders (employees, customers, suppliers), not just shareholders. Interestingly, designers often forget that users are stakeholders too—not just executives!

⚠️ When Theory Meets Reality: The Contradiction

Theory Says: Involve stakeholders early and often for buy-in

Reality: Apple's design team famously excludes stakeholders until designs are final—and it works.

Example: Apple's Secretive Design Process

  • Design team works in complete secrecy
  • Even executives don't see work-in-progress
  • No stakeholder input during design phase
  • Present only when design is complete and polished
  • Result: Most cohesive, visionary products in tech

Lesson: Too many stakeholders can dilute vision. Apple's approach works because design has ultimate authority and trust from leadership. Most companies need stakeholder involvement because design lacks that power. Know your context and political capital.

📚 Resources & Further Reading

Books

  • Monteiro, Mike. Design Is a Job. A Book Apart, 2012.
  • Cialdini, Robert. Influence: The Psychology of Persuasion. Harper Business, 2006.
  • Stone, Douglas, and Sheila Heen. Difficult Conversations: How to Discuss What Matters Most. Penguin Books, 2010.

Articles & Papers

Frameworks

  • RACI Matrix (Responsible, Accountable, Consulted, Informed)
  • Stakeholder Mapping
  • Power-Interest Grid
← Previous: Design Operations Next: Team Building & Culture →