Fatskills
Practice. Master. Repeat.
Study Guide: Principles of Product Management: Stakeholder Mapping (Power/Interest Grid, RACI Matrix)
Source: https://www.fatskills.com/product-management/chapter/product-management-stakeholder-mapping-powerinterest-grid-raci-matrix

Principles of Product Management: Stakeholder Mapping (Power/Interest Grid, RACI Matrix)

By Fatskills Exam Guides Team — the exam nerds behind 28,500+ quizzes and 2.1M practice questions across 500+ global exams.

⏱️ ~7 min read

Stakeholder Mapping (Power/Interest Grid, RACI Matrix)



Stakeholder Mapping (Power/Interest Grid, RACI Matrix) – Study Guide


What This Is

Stakeholder mapping is the process of identifying, analyzing, and prioritizing individuals or groups who impact (or are impacted by) your product—then tailoring your communication and influence strategy to align them. It’s critical because misaligned stakeholders = scope creep, delayed launches, or failed adoption. Example: A fintech PM launching a new fraud-detection feature must map stakeholders like the CISO (high power, low interest), customer support (low power, high interest), and engineering (high power, high interest)—then adjust engagement (e.g., quick updates for CISO, deep collaboration with engineering).


Key Terms & Frameworks

  • Stakeholder: Anyone who affects or is affected by your product (e.g., users, engineers, execs, legal, partners).
  • Power/Interest Grid (Mendelow’s Matrix): A 2×2 grid plotting stakeholders by power (ability to influence outcomes) and interest (level of concern). Used to decide how to engage them.
  • High Power/High Interest (Manage Closely): Deep collaboration (e.g., engineering leads).
  • High Power/Low Interest (Keep Satisfied): Minimal but strategic updates (e.g., CFO).
  • Low Power/High Interest (Keep Informed): Regular but lightweight updates (e.g., customer support).
  • Low Power/Low Interest (Monitor): Minimal effort (e.g., occasional users).
  • RACI Matrix: A table assigning roles to stakeholders for a task/project:
  • Responsible (does the work),
  • Accountable (owns the outcome),
  • Consulted (input needed),
  • Informed (kept in the loop).
  • Stakeholder Influence Map: Visualizes relationships between stakeholders (e.g., who influences whom) to identify hidden power dynamics.
  • Stakeholder Salience Model: Classifies stakeholders by power, legitimacy, and urgency (e.g., a regulator has high power + urgency).
  • DACI (Variant of RACI): Adds a Driver (who pushes the work forward) to clarify ownership.
  • Stakeholder Communication Plan: A table outlining who, what, when, and how to communicate with each stakeholder (e.g., weekly Slack updates for engineers, monthly exec summaries for the CPO).
  • Stakeholder Resistance Matrix: Identifies potential blockers and mitigation strategies (e.g., "Legal may delay launch—preempt with early compliance reviews").
  • Stakeholder Personas: Semi-fictional profiles of key stakeholders (e.g., "The Skeptical Engineer" who needs data to buy in).
  • Stakeholder Journey Map: Tracks how a stakeholder’s needs/concerns evolve over time (e.g., a CTO’s priorities shift from "feasibility" to "scalability" post-launch).


Step-by-Step / Process Flow

  1. Identify Stakeholders
  2. Brainstorm all possible stakeholders (internal + external). Use:
    • Org chart (for internal teams).
    • User segments (for customers/partners).
    • Past projects (who was involved before?).
    • Risk logs (who might block or derail?).
  3. Example: For a checkout redesign, stakeholders include UX, engineering, legal (PCI compliance), marketing, customer support, and payment partners (Stripe/PayPal).

  4. Map Power vs. Interest (Grid)

  5. Plot stakeholders on the Power/Interest Grid (use a whiteboard or Miro).
  6. Pro tip: Ask: "Can this person kill the project? Do they care deeply about the outcome?"
  7. Example: A CPO (high power, high interest) vs. a junior marketer (low power, low interest).

  8. Assign RACI Roles

  9. For each key task (e.g., "Design fraud-detection UI"), assign RACI roles.
  10. Rule: Only one "A" (Accountable) per task (e.g., the PM owns the feature spec, but engineering owns the implementation).
  11. Example:
    | Task | PM | Engineering | Legal | Marketing |
    |--------------------|-----|-------------|-------|-----------|
    | Write PRD | A | C | I | I |
    | Build API | I | R/A | - | - |
    | Draft compliance | C | - | R/A | - |

  12. Tailor Engagement Strategies

  13. High Power/High Interest: Weekly syncs, co-creation (e.g., engineering).
  14. High Power/Low Interest: Monthly 1:1s, high-level updates (e.g., CFO).
  15. Low Power/High Interest: Newsletters, office hours (e.g., customer support).
  16. Low Power/Low Interest: Passive updates (e.g., Slack #announcements).

  17. Anticipate & Mitigate Risks

  18. Use the Stakeholder Resistance Matrix to identify blockers (e.g., "Legal may delay launch—engage them early with draft compliance docs").
  19. Example: If the CISO is skeptical, preempt with a security review before the PRD is finalized.

  20. Iterate & Update

  21. Stakeholder maps are living documents. Revisit:
    • After major milestones (e.g., post-launch).
    • When org changes occur (e.g., new CTO).
    • If resistance emerges (e.g., engineering pushes back on scope).

Common Mistakes

  • Mistake: Assuming all stakeholders are equally important.
  • Correction: Use the Power/Interest Grid to prioritize. Why? You’ll waste time over-communicating with low-power stakeholders (e.g., spamming the CFO with daily updates).

  • Mistake: Assigning multiple "Accountable" (A) roles in RACI.

  • Correction: Only one "A" per task. Why? Shared accountability = no accountability (e.g., if both PM and engineering are "A" for a feature, neither owns the outcome).

  • Mistake: Ignoring "low-power" stakeholders who can derail the project.

  • Correction: Even low-power stakeholders (e.g., customer support) can escalate issues to high-power allies. Why? A single complaint from support to the CPO can kill a feature.

  • Mistake: Treating stakeholder mapping as a one-time activity.

  • Correction: Update the map quarterly or after major changes. Why? Stakeholder power/interest shifts (e.g., a new CTO may suddenly care about your project).

  • Mistake: Over-relying on RACI without addressing how to engage stakeholders.

  • Correction: Combine RACI with a communication plan. Why? RACI tells you who is involved; the plan tells you how to keep them aligned.


PM Interview / Practical Insights

  1. Interviewer Trap: "How would you handle a stakeholder who disagrees with your prioritization?"
  2. Answer: Use the Power/Interest Grid to assess their influence, then:


    • If high power/high interest: Co-create a solution (e.g., "Let’s run a small experiment to validate your concern").
    • If high power/low interest: Align on outcomes (e.g., "I’ll share data weekly to keep you informed").
    • If low power: Acknowledge but don’t over-index (e.g., "I’ll note your feedback and revisit in the next sprint").
  3. Tricky Distinction: Stakeholder vs. User

  4. Stakeholder: Anyone who affects the product (e.g., engineers, legal, execs).
  5. User: The person who uses the product (e.g., a shopper on an e-commerce site).
  6. Why it matters: You might build a feature users love but stakeholders hate (e.g., a "one-click checkout" that legal blocks for compliance reasons).

  7. Real-World Scenario: "Your CTO wants to cut a feature you believe is critical. How do you respond?"

  8. Answer:
    1. Clarify the "why" (e.g., "Is this about timeline, cost, or strategic alignment?").
    2. Propose alternatives (e.g., "Can we build a lightweight MVP instead of cutting it entirely?").
    3. Escalate if needed (e.g., "If we cut this, we risk losing X% of users—can we discuss with the CEO?").
  9. Key: Frame it as a collaborative problem-solving exercise, not a debate.

  10. Interview Question: "How do you manage stakeholders with conflicting priorities?"

  11. Answer:
    1. Map their power/interest (e.g., is one a high-power exec and the other a low-power IC?).
    2. Find common ground (e.g., "Both want to improve retention—let’s test which approach works better").
    3. Use data (e.g., "Our A/B test shows Feature A drives 20% more engagement than Feature B").
    4. Escalate if needed (e.g., "If we can’t align, let’s ask the CPO to decide").

Quick Check Questions

  1. Scenario: Your engineering lead (high power, high interest) insists on a technical approach that will delay the launch by 2 months. How do you respond?
  2. Answer: Propose a phased rollout (e.g., "Let’s launch the MVP now and add the optimizations in v2"). Why? Balances their technical concerns with business needs.

  3. Scenario: Your customer support team (low power, high interest) keeps flagging a UX issue, but your data shows it’s not a top pain point. How do you handle it?

  4. Answer: Acknowledge their feedback, but prioritize based on impact (e.g., "I’ll add this to our backlog, but let’s focus on the top 3 issues first"). Why? Support sees edge cases, but you must prioritize scalable solutions.

  5. Scenario: Your CFO (high power, low interest) asks for a last-minute cost analysis of your project. How do you prepare?

  6. Answer: Provide a 1-pager with key metrics (e.g., ROI, payback period) and highlight risks (e.g., "If we delay, we’ll lose $X in revenue"). Why? High-power/low-interest stakeholders need concise, outcome-focused updates.

Last-Minute Cram Sheet

  1. Power/Interest Grid: Plot stakeholders by power (influence) and interest (concern) to decide engagement.
  2. RACI Matrix: Assign Responsible, Accountable, Consulted, Informed roles per task.
  3. Only one "A" per task in RACI—shared accountability = no accountability.
  4. High Power/High Interest: Manage closely (weekly syncs, co-creation).
  5. High Power/Low Interest: Keep satisfied (monthly 1:1s, high-level updates).
  6. Low Power/High Interest: Keep informed (newsletters, office hours).
  7. Low Power/Low Interest: Monitor (passive updates).
  8. ⚠️ Stakeholder maps are living documents—update after major changes.
  9. ⚠️ Low-power stakeholders can escalate—don’t ignore them.
  10. Stakeholder Personas: Create semi-fictional profiles to anticipate needs (e.g., "The Skeptical Engineer").


ADVERTISEMENT