| name | stakeholder-psychology |
| description | Psychological principles for making product briefs championing-ready. Covers the cascade principle, cognitive burden minimization, incentive alignment, psychological risk reduction, and championing language. Trigger keywords: stakeholder championing, psychological risk, incentive alignment, cascade principle, championing test, business outcome framing. |
Stakeholder Psychology
Use this skill to make product briefs psychologically optimized for stakeholder approval and internal championing, on top of analytic soundness.
The Core Insight
Technical quality alone does not drive organizational decisions. Stakeholders make decisions based on perception, relationships, and incomplete information. They reward people who make them feel confident about decisions.
A brilliant brief that stakeholders cannot easily champion internally will lose to a simpler brief they can.
The Cascade Principle
Your reader is not the final decision-maker. They must re-pitch your proposal to their own leadership. Every section of the brief must give them ammunition for that next conversation.
Design rules:
- Write as if your reader will present this in a meeting where you are not present
- The executive summary should work as a standalone verbal pitch
- Every major section needs at least one clear, repeatable statement the reader can use in their own meeting
- If a section requires domain expertise to explain, it will die in the cascade
The Cascade Test
After writing any section, ask: "Could my reader explain this to their boss in 30 seconds without referring back to the document?"
- If yes: the section passes
- If no: simplify the framing until a non-expert can confidently relay it
- If partly: extract the core business outcome into one lead sentence, move complexity to supporting detail
Psychological Risk Reduction
Stakeholders face different consequences than the brief author. They are measured on business outcomes and team perception, not technical delivery. Approving a proposal they cannot fully explain creates psychological risk with no clear reward.
Make "Yes" Feel Safe
- Lead with familiar business outcomes: reduced costs, faster delivery, happier customers, lower risk
- Frame the proposal so it aligns with what the stakeholder is already measured on
- Show that the recommended path has been de-risked (phased approach, reversibility, early validation)
- Make the cost of inaction concrete — not approving should feel riskier than approving
Make "No" Feel Costly
- Quantify the cost of delay or inaction in business terms the stakeholder owns
- Show what competitors or peers are doing (if relevant and evidence-backed)
- Connect inaction to metrics the stakeholder reports on
Anti-Patterns
- Presenting technical superiority without business context — asks the stakeholder to take risk without clear reward
- Detailed technical explanations that trigger anxiety about defending something they cannot fully grasp
- Framing that requires the reader to become a domain expert before they can advocate
Cognitive Burden Minimization
Complex information creates anxiety. The goal is not to dumb down the work but to reduce the cognitive effort required to reach a confident decision.
Rules:
- One core message per section — if a section makes three points, the reader remembers zero
- Use concrete numbers over abstract descriptions ("40% fewer tickets" not "significant efficiency improvement")
- Replace jargon with plain business language in lead sentences; technical precision can follow in supporting detail
- Prefer familiar analogies when introducing novel concepts
- Structure sections so the reader gets the conclusion first, evidence second
- Use short, neutral headings that label the topic — dramatic or editorializing headings add cognitive burden and trigger skepticism rather than confidence
Incentive Alignment
The brief must speak to what the stakeholder is measured on, not what the author is measured on.
| Author's Incentive | Stakeholder's Incentive | Brief Must Emphasize |
|---|
| Technical correctness | Business outcomes they report on | Revenue, cost, customer satisfaction, risk |
| Comprehensive analysis | Confident decision-making | Clear recommendation with bounded risk |
| Engineering elegance | Team perception and credibility | Proven approaches, phased delivery, peer validation |
| Feature completeness | Time-to-value | What ships first and what impact it delivers |
Translation Exercise
For every technical benefit, ask: "What business outcome does this create for the person reading this?"
- "Modular architecture" → "We can ship phase 1 in Q3 and iterate based on real usage data"
- "Improved test coverage" → "Lower risk of production incidents that disrupt customers"
- "Refactored permissions model" → "Admins can self-serve instead of filing 200 tickets per month"
Championing Language
Each major section should contain at least one statement that is:
- Memorable — concise enough to repeat from memory
- Business-outcome-focused — speaks to revenue, cost, risk, or customer impact
- Defensible — backed by evidence cited in the brief
- Repeatable — a stakeholder could say it in their own meeting without modification
Examples
| Weak (not championing-ready) | Strong (championing-ready) |
|---|
| "The proposed RBAC system addresses several administrative pain points in the current architecture" | "This eliminates 200 admin escalation tickets per month and unblocks self-service for 340 admins" |
| "We recommend a phased approach to implementation" | "Phase 1 ships in Q3 and pays for itself within 90 days through reduced support load" |
| "The solution aligns with our strategic technical direction" | "Three enterprise customers have flagged this as a blocker for renewal" |
Integration with Other Skills
- Executive Writing Style: The "so what?" test ensures decision-relevance; the championing test ensures relay-ability
- Decision Metrics Financials: Options tables should include stakeholder-friendly impact language, not just technical criteria
- Product Brief Framework: The executive summary serves double duty as the reader's championing script
Championing language is especially critical for Decision Ask and Recommendation closing types, where the reader must actively advocate. However, the cascade principle applies to all closing types — even informational briefs must give the reader repeatable statements for their own conversations.
