Unit 8: Working with stakeholders: alignment and influence

Learning objectives

By the end of this unit, you should be able to identify key stakeholder types and their motivations, use structured techniques to build alignment without authority, and handle common stakeholder conflicts productively.

Video script

Reading material

Building alignment without authority

The pre-meeting meeting. Before any important product decision, have one-on-one conversations with key stakeholders. Understand their perspective, share your thinking, and surface disagreements early. By the time you're in the group decision meeting, you already know where everyone stands and have addressed the biggest objections. This isn't going behind people's backs. It's giving everyone the chance to process and respond thoughtfully.

Speak their language. When talking to Sales, frame your priorities in terms of revenue impact and competitive positioning. When talking to Engineering, frame them in terms of technical approach and architecture implications. When talking to executives, frame them in terms of strategy and metrics. Same decision, different framing.

Show your work. When you say no to a request, show the reasoning. "Here's the data on what our users need most. Here's how I evaluated the alternatives. Here's why I chose this direction." Transparency builds trust, even when people disagree with the conclusion.

Create feedback loops. After shipping something, share the results with the stakeholders who were involved in the decision. Did the feature have the impact you predicted? What did you learn? This closes the loop and builds credibility for future decisions.

Handling conflict

Stakeholder conflicts are normal. They happen because different parts of the organization have different incentives, and that's healthy. The question is how you handle them.

When Sales wants a feature for one customer. Ask: how many other customers have this need? Is this a pattern or an outlier? If it's a pattern, it might be worth pursuing. If it's one customer, it's a customization request, not a product decision. Frame it that way.

When leadership disagrees with your prioritization. Listen carefully to their reasoning. They may have context you don't (a strategic partnership, a board commitment, market intelligence). Share your reasoning with equal transparency. If the disagreement persists, escalate it clearly: "We see it differently. Here's the trade-off. How should we decide?"

When engineering pushes for tech debt work. Take it seriously. Technical debt is real, and ignoring it creates compounding problems. Ask for specifics: what's the impact of not addressing it? How does it affect the team's ability to deliver on product priorities? Often there's a way to bundle tech debt work with product work rather than treating them as competing priorities.

Practical exercise

Exercise: Stakeholder alignment simulation

Scenario: You're a PM at a B2B SaaS company. You've done discovery and believe the team should focus on improving the onboarding experience for new customers (data shows 40% drop-off in the first week). But you're facing three competing requests.

1. The VP of Sales wants an integration with HubSpot because three enterprise prospects asked for it.
2. Customer Success is asking for an in-app help system because support tickets are up 25%.
3. The CTO wants to migrate to a new database infrastructure to handle growing scale.

Write a one-page stakeholder alignment document that:

• Acknowledges each request and explains why it matters
• Makes the case for your onboarding recommendation
• Shows how some of the other requests might be addressed within or after the onboarding work
• Proposes a timeline that gives each stakeholder visibility into when their concerns will be addressed

The goal is to practice being transparent, strategic, and empathetic in a real-world trade-off situation.