Build consensus across diverse stakeholders by understanding their thinking, surfacing disagreement, and making deliberate trade-offs. Transforms stakeholder chaos into coordinated support. Trigger on: 'stakeholder alignment', 'buy-in', 'disagreement', 'getting approval', 'cross-functional decision', 'executive alignment'.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
Align Stakeholders
description
Build consensus across diverse stakeholders by understanding their thinking, surfacing disagreement, and making deliberate trade-offs. Transforms stakeholder chaos into coordinated support. Trigger on: 'stakeholder alignment', 'buy-in', 'disagreement', 'getting approval', 'cross-functional decision', 'executive alignment'.
dependencies
[]
connectors
[{"name":"Slack","reason":"Monitor stakeholder concerns and sentiment in real-time"},{"name":"Google Calendar","reason":"Identify key decision-makers and review meeting patterns"},{"name":"Google Drive","reason":"Access strategy documents and track feedback from stakeholders"},{"name":"Email","reason":"Understand stakeholder communication and concerns"},{"name":"Notion","reason":"Document stakeholder requirements and alignment strategies"}]
author
Harmony
version
1.0.0
icon
sparkles
cover
screenshots
[]
category
Strategy
Purpose
Many great ideas fail not because they're bad ideas but because stakeholders aren't aligned. Sales wants one thing, engineering can't build it, finance is worried about budget, and marketing is planning around an assumption nobody validated. By the time you notice misalignment, months have passed and you're reworking everything.
This skill teaches you to build alignment before you need it, not after decisions fall apart. It's based on a critical insight: stakeholders rarely disagree about what they actually think. They disagree because they don't understand how others think. When you understand how a person thinks—their constraints, incentives, what they actually care about—disagreement often resolves or at least becomes a clear trade-off both sides understand.
The skill covers how to approach stakeholders with genuine curiosity instead of trying to convince them, how to present options with recommendations so people can make informed choices, how to distinguish disagreement from misunderstanding, how to build trust through consistency, and how to repeat messages relentlessly so understanding sticks across diverse audiences.
When to Use
Use this skill whenever you need agreement from multiple people with different incentives. It's especially valuable when:
You're launching a major initiative that requires buy-in from multiple teams
There's visible tension between stakeholders and you're not sure why
You've explained a decision multiple times and people still don't seem to understand it
You're heading off a disagreement before it becomes a problem
You're building trust with a stakeholder who's been burned before
You're presenting to executives and need fast decisions, not endless deliberation
You're navigating organizational politics without compromising the work
You need approval from someone who has power but hasn't been engaged yet
Instructions
Step 1: Understand How They Think, Not What They Think
Most alignment work focuses on what people think: "Sales wants growth, engineering wants simplicity." But understanding stops there. The real insight is how they think—the underlying logic that drives their positions.
Before a major alignment conversation, invest in understanding:
Their constraints: What are they responsible for? What are they measured on? What keeps them up at night?
Their mental models: How do they see the world? What patterns do they notice? What analogies do they use?
Their past experiences: What burned them before? What worked before? What shaped their current thinking?
Hilary Gridley calls this "understanding how they think." You're not trying to change their position—you're trying to understand the logic that created it. When you understand someone's mental model, you can speak their language. You can show how your idea fits within their framework instead of asking them to abandon it.
Example: Your VP Sales is skeptical about a product strategy. Instead of assuming they just don't get it, ask: "Tell me about a time strategy worked and a time it didn't." Their stories reveal their mental model. Maybe they've seen strategy derail when execution was weak, so they care deeply about realistic timelines. Now you can frame strategy with execution detail. They'll see you understand their real concern.
Step 2: Get Pre-Alignment on Strategy
Many alignment problems are preventable if you get buy-in on strategy before tactics. Shreyas Doshi calls this "get pre-alignment on strategy"—before you propose a specific direction, make sure key stakeholders agree on the frame.
Instead of: "Here's the feature we're building. Can you support it?"
Do this: "We're trying to solve X problem, which affects Y stakeholders, and would help us achieve Z outcome. Does that strategic direction make sense? Are there other strategic directions we should consider?" Get agreement on the frame. Then: "Given we're aligned on that direction, here's the specific solution we're proposing."
This is harder upfront (it takes time to get strategic alignment) but prevents downstream disagreement because tactical disagreement is resolved through reference back to shared strategy.
Step 3: Present Options with Recommendation
Don't present a single option and ask for buy-in. Present multiple options with a recommendation. This shifts the conversation from "do you agree with my choice?" to "here are the trade-offs, here's what I think we should do, do you see it differently?"
Matt LeMay's framework:
Option 1: Minimal investment, slower results. Pro: lower risk. Con: might not move the needle.
Option 2: Medium investment, medium results. Pro: balanced. Con: might feel like hedging.
Option 3: High investment, maximum potential. Pro: could be category-defining. Con: highest risk if it doesn't work.
Recommendation: "I think Option 2 is right because [reasoning]. Here's what could change my mind [conditions]."
With options, stakeholders can engage with trade-offs instead of just accepting or rejecting your idea. You're showing you've thought about alternatives, not just fallen in love with one approach.
Step 4: Distinguish Disagreement from Misunderstanding
Two people can seem to disagree when they actually just don't understand each other. The engineering lead says "we can't build this in three months." Product hears "engineering doesn't want to." But maybe the engineering lead means "we can build it in three months if we cut these other things" or "we can build it in three months if you accept these technical shortcuts."
Tomer Cohen's framework: When you hear disagreement, ask clarifying questions:
"Can you help me understand what you mean by [specific term]?"
"What would change your perspective on this?"
"If we did X, would that address your concern?"
Often, the "disagreement" dissolves because you were using different definitions or didn't actually understand the constraint. Real disagreement (where people genuinely want different outcomes) is rarer than it appears.
Step 5: Approach with Curiosity, Not Conviction
Ami Vora's insight: approach disagreements with genuine curiosity, not conviction that you're right. "Here's what I'm thinking. I might be missing something. Help me understand your perspective."
This sounds like weak positioning, but it's actually the strongest position. When you're genuinely curious, you:
Learn things you didn't know (often solving the disagreement)
Build trust because you're actually listening, not just waiting to talk
Give the other person space to move without losing face
Create psychological safety for disagreement (people will be honest instead of defensive)
The alternative is coming in convinced. "Here's why this is right. Let me convince you." This activates their defense mechanisms. They dig in even if they might have agreed.
Step 6: Build Trust Through Consistency
Ian McAllister's observation: Trust is built through consistency over time, not through single moments. You can't make a massive trust deposit in one conversation. Trust compounds through:
Doing what you say you'll do: When you commit to something, deliver on it
Being honest about uncertainty: When you don't know, say so. When something might not work, name it
Following up: When you tell someone you'll send them something, send it. When you commit to deciding something, decide it on the timeline you set
Acknowledging their concerns: Show you understood their perspective, even if you didn't adopt it
One consistent action builds more trust than 10 grand gestures followed by flakiness. This matters for long-term alignment—the same stakeholders you're aligning with today you'll need aligned with six months from now.
Step 7: Map Concentric Circles of Communication
Different stakeholders need different information. Lulu Cheng Meservey's framework: concentric circles of communication.
Center circle (core stakeholders): Get full context, all options, all reasoning. Meet with them early, involve them in decision-making.
Second circle (affected stakeholders): Get the decision and how it affects them. Learn what they need to do.
Third circle (need to know): Get the basic decision and implications. Why it matters to the company.
Outer circle (nice to know): Get a simple summary. They can learn more if interested.
Don't try to communicate the same depth to everyone. Center circle gets the full strategy conversation. Outer circle gets "we decided to focus on X." This is more efficient and prevents information overload.
Step 8: Repeat Messages Relentlessly
Zoelle Egner's research: important messages need to appear in multiple places, multiple times, in slightly different forms. "I said it once" is not a strategy for making ideas stick.
Create a repetition plan:
First mention: Strategy conversation with center circle stakeholders (live conversation)
Second mention: Email documenting the decision and trade-offs (some people process better in writing)
Third mention: Team meeting where you explain implications for them (relevant to their work)
Fourth mention: Monthly all-hands where you reinforce strategic direction
Fifth mention: Follow-up email when something changes based on the decision
This isn't excessive repetition—it's how information spreads across different audiences and different processing styles. Some people will understand after hearing once in the right forum. Others need to hear it three times in different ways. By the fifth mention, even the person who was skeptical will have gradually shifted.
Step 9: Learn Their Business Constraints
Marty Cagan's research: The best product leaders understand the business constraints that shape decisions. Sales has a quota. Finance has a budget cycle. HR has hiring freezes. Operations has infrastructure limits.
When you understand constraints, you stop fighting them and start designing around them. "We can't hire more engineers" isn't an excuse—it's a constraint you plan within. "We can ship faster if we hire" is proposing to change the constraint, which is a different conversation.
Take time to understand:
How is each stakeholder measured?
What are their budget cycles?
What are their capacity constraints?
What are their risk tolerances?
What are their time horizons?
When you understand constraints, you can frame proposals around them. Instead of "we need three engineers," try "within our current headcount, here's how we can achieve the outcome."
Step 10: Frame Requests as Trade-offs
Wes Kao's insight: frame requests as trade-offs. "If we do this, we're choosing not to do that." This makes the opportunity cost visible and helps stakeholders make better decisions.
Instead of: "Can we add this feature?"
Try: "Adding this feature means we delay the integration work by 4 weeks. Is the feature worth that delay, or should we stick with the current roadmap?"
Trade-off framing does several things:
Makes the real cost visible (not hidden)
Acknowledges you're not asking for free gifts (you're asking to prioritize something)
Respects stakeholder decision-making by giving them the full picture
Builds trust because you're being transparent about costs
Output Format
Your stakeholder alignment strategy should include:
Stakeholder Map:
Who are the key stakeholders (center, second, third, outer circles)?
What's their role and what do they care about?
What are their constraints and incentives?
What's their mental model (how do they think)?
What's their past experience (what shaped their current thinking)?
Pre-Alignment Strategy:
What strategic frame do they need to agree on?
What questions to ask to understand their thinking?
What conversations to have before proposing tactics?
Alignment Messages:
Core message (the decision and why)
For each stakeholder group: what they need to know and why it matters to them
Trade-offs to make visible to each group
Communication Plan:
Center circle: direct conversation, timing, options to present
Second circle: how they'll be informed, what questions to anticipate
Third circle: how they'll be informed, level of detail needed
Outer circle: brief summary, where to learn more
Repetition Plan:
First mention: what format, with whom
Second mention: different format, different audience
Subsequent mentions: how to reinforce as you execute
Trust-Building Actions:
What will you do consistently to build trust?
How will you follow up on commitments?
How will you handle changes to the plan?
Measurement:
Is alignment holding or breaking down?
Are people making decisions as if they understood the trade-offs?
Are you seeing the behavior you expected?
Example
Scenario: Priya is SVP of Product at DataFlow, a B2B data platform. She's proposing a major shift: invest heavily in API stability for the next two quarters (delay feature work) because customer churn is being driven by API reliability issues. This requires alignment from:
CEO (controls investment dollars)
VP Sales (measured on new customer acquisition, worried about feature velocity)
VP Engineering (responsible for stability but also shipping roadmap items)
Head of Customer Success (sees the churn, supports the shift)
Step 1 - Understand How They Think:
Priya spends time understanding their thinking:
CEO: Has seen companies fail because they didn't invest in foundations. Also worries about growth slowing if feature velocity drops. Cares about both short-term growth and long-term health.
VP Sales: Had a deal blow up because customer hit API limits. Also has quota and needs new features to win deals. Worried that stability work = no new features = missing quota.
VP Engineering: Knows API is brittle and needs work. Also has team commitments. Worried that committing 2 quarters to stability = deprioritizing work that impacts multiple stakeholders.
Head of Customer Success: Sees retention impact daily. Frustrated by API limitations being customer-facing problems. Wants this fixed.
Step 2 - Get Pre-Alignment on Strategy:
Instead of proposing "invest two quarters in API stability," Priya first gets alignment on the strategic frame:
With CEO: "We're seeing early churn signals connected to infrastructure stability. If we don't address this now, I think we risk customer lifetime value. Does addressing churn feel like the right strategic priority right now?"
CEO agrees: "Yes, we can't grow our way out of churn. If it's a stability issue, we should fix it."
With VP Sales: "Here's what I'm hearing from customers: they want to expand with us but hit API limits first. If we fix the infrastructure, these customers expand. If we don't, they move to a competitor. Does that match what you're seeing?"
VP Sales: "Yeah, we've lost two customers to that issue."
With VP Engineering: "I think we should invest in API stability. It's foundational work that unblocks everything else. What would it take for your team to commit to this?"
VP Engineering: "If we're really committing, we need to deprioritize X and Y. That's the cost."
Now Priya has strategic alignment: everyone agrees "API stability matters."
Step 3 - Present Options with Recommendation:
Now Priya presents tactical options:
Option 1: Dedicate 1 engineer to stability improvements while maintaining current feature velocity. Pro: doesn't disrupt roadmap. Con: probably not fast enough to stop churn.
Option 2: Dedicate entire engineering team (2 quarters) to API stability. Pro: solves problem completely. Con: delays all feature work.
Option 3: Dedicated API team (3 engineers) for 4 quarters with rest of team continuing features. Pro: balances stability and momentum. Con: requires hiring or reorg.
Recommendation: "I think we do Option 2 for Q2-Q3. Here's why: the churn is happening now, and every quarter we delay costs us customers. Two quarters focused on stability is the fastest path to a reliable platform. We resume feature work in Q4 with a stronger foundation. Sales, I know this affects your roadmap. Here's what I think we can do to keep momentum [specific options for small features that don't touch core API]."
Step 4 - Distinguish Disagreement from Misunderstanding:
VP Sales says: "I can't support two quarters with no features. My customers expect feature velocity."
Instead of hearing this as disagreement, Priya asks:
"What exactly do you mean by 'no features'? I was thinking we could still do small items that don't touch the API. Would that help?"
"What would customers say is more important: new features or a reliable platform that doesn't have outages?"
"If we fixed API stability in Q2, would customers be happy even with lighter feature velocity?"
VP Sales: "Actually, if the API stops going down, customers would prefer that to new features. We just need to communicate it that way."
Disagreement resolved because it was misunderstanding.
Step 5 - Approach with Curiosity:
When VP Engineering expresses concern about the reorg required, Priya says: "I can tell this is complicated. Help me understand what makes this hard beyond the obvious." VP Engineering reveals: "My team has built expertise on the customer-facing side. Shifting to infrastructure work requires them to learn new systems. I'm worried about morale if they feel like they're being moved away from the work they built."
Priya: "That's a real concern. What if we structure this as 'we're building the foundation that the customer work sits on' instead of a deprioritization? And what if we bring in an infrastructure expert to lead so your team is learning, not just executing?"
Now they're solving the real concern, not just the stated one.
Step 6 - Build Trust Through Consistency:
Priya commits to:
Weekly updates on stability progress (so sales doesn't feel like the work disappeared)
Bi-weekly customer conversation review (so sales can tell customers what's being fixed)
Monthly engineering deep-dives (so engineering team feels the work is valued)
Quarterly business impact assessment (so everyone can see the churn impact of stability improvements)
She delivers on these consistently. When she commits to "I'll have the sizing data by Friday," she sends it Friday. When a customer issue emerges, she doesn't hide it—she surfaces it and explains how the stability work addresses it. This consistency builds trust that she's serious about the commitment.
Step 7 - Map Concentric Circles:
Center circle (CEO, VP Sales, VP Engineering, VP Customer Success): Full strategy conversation, trade-offs, options, business case. Month-long alignment process. Weekly updates once decided.
Second circle (Sales leadership, engineering team leads): The decision, what it means for their area, timeline. How it affects them directly.
Third circle (Full sales and engineering org): Basic decision and why. How their work might change. Quarterly updates on progress.
Outer circle (Marketing, finance, operations): Brief summary. It's a strategic priority. That's all they need to know.
Step 8 - Repeat Messages:
Week 1 (center circle): Live alignment meeting with options and trade-offs
Week 2 (second circle): Email documenting decision and implications for each team
Week 3 (all hands): Company meeting where Priya explains the strategic shift and impact on churn
Week 5 (sales and engineering meetings): Specific implications for their functions
Monthly (all-hands): Progress update on stability improvements and customer retention impact
When new people join: Stability project explained as part of onboarding
Step 9 - Learn Their Business Constraints:
Priya learns:
Sales is measured on ARR, not feature count
Engineering team has 2 planned initiatives for H1 that are deprioritized
CEO's bonus is tied to retention metrics
CFO has headcount budget constraints
With this knowledge, she frames the proposal around these constraints: "This helps us hit retention targets, which directly impacts the CEO's compensation. It doesn't require new headcount because we're reallocating. Sales, it impacts your feature velocity short-term but should unlock expansion from existing customers."
Step 10 - Frame as Trade-off:
Priya presents it as: "If we do API stability in Q2-Q3, we're trading feature velocity for retention. Every week we don't commit is another week customers are potentially churning. What's the trade-off acceptable to you?"
CEO: "Yes, retention matters more than new features right now."
Sales: "If it really drives expansion from existing customers, yes."
Engineering: "If we're committing, yes."
Everyone sees the trade-off and buys in.
Result: The proposal gets aligned buy-in because Priya understood how each stakeholder thought, got pre-alignment on strategy, presented clear trade-offs, distinguished disagreement from misunderstanding, and then built trust through consistent follow-up. The two-quarter stability initiative ships on schedule with strong team morale and customer retention improving visibly.
Edge Cases
A stakeholder won't align despite your best efforts: At some point, alignment attempts become theater. If someone fundamentally disagrees and won't move, you need a different conversation. "It seems like we see this differently and conversation isn't bridging the gap. I need to understand: can you support this decision, or is this something we need to escalate?" This forces clarity on whether they're actually blocking or just unhappy.
Multiple stakeholders want contradictory things: Map the trade-offs explicitly. "Sales wants new features. Engineering wants stability time. Both are right. We can't do both in Q2. Which matters more?" Force the prioritization conversation. This is where leadership decides, not where you find consensus.
You realize a stakeholder's concern is actually right: Excellent. Change direction. "I thought we should do X, but hearing your concern about Y, I think we should do Z instead." This builds trust way more than defending a bad decision. Good judgment includes knowing when you were wrong.
Politics enters the picture: Some disagreement isn't about the decision—it's about power or status. If you sense this, surface it gently. "I notice this conversation feels like it's about more than API stability. Can we talk about what's really going on?" If you can't surface it directly, escalate to a leader who can.
You need alignment fast: You can compress the timeline but not eliminate the work. Hit the CEO first to get her buy-in, then use her support to accelerate other stakeholder conversations. "The CEO agrees this is strategic. Here's the decision. How can we make it work for your area?"
Alignment breaks down after the decision: Trust eroded. Follow up on your commitments obsessively. If something changes, communicate it immediately before people hear through the grapevine. Rebuild trust through consistency.