role-switch

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Role Switch

角色切换法

Purpose

目的

Role Switch helps uncover blind spots, align stakeholders, and make better decisions by systematically analyzing from multiple perspectives. It transforms single-viewpoint analysis into multi-stakeholder synthesis with explicit tradeoffs and alignment paths.

角色切换法通过系统地从多视角分析，帮助发现盲区、对齐利益相关者并做出更优决策。它将单一视角的分析转化为包含明确取舍和对齐路径的多利益相关者共识成果。

When to Use

适用场景

Invoke this skill when you need to:

Align stakeholders with conflicting priorities (eng vs PM vs sales vs legal)
Uncover blind spots in decisions by viewing from multiple angles
Pressure-test proposals before presenting to diverse audiences
Build empathy for perspectives different from your own
Navigate cross-functional tradeoffs (cost vs quality, speed vs thoroughness)
Evaluate decisions with multi-dimensional impact (technical, business, user, regulatory)
Find consensus paths when positions seem incompatible
Validate assumptions by seeing what different roles would challenge

User phrases that trigger this skill:

"What would [stakeholder] think about this?"
"How do we get alignment across teams?"
"I'm worried we're missing something"
"See this from their perspective"
"Conflicting priorities between X and Y"
"Stakeholder buy-in strategy"

当你需要以下操作时，调用本方法：

让优先级冲突的利益相关者（开发 vs PM vs 销售 vs 法务）达成共识
从多维度视角发现决策中的盲区
在向多元受众展示前对提案进行压力测试
培养对不同立场的共情能力
处理跨职能取舍（成本 vs 质量、速度 vs 严谨性）
评估具有多维度影响的决策（技术、业务、用户、合规层面）
在立场看似对立时寻找共识路径
通过不同角色的质疑验证假设

触发本方法的用户表述：

“[某利益相关者]会怎么看待这件事？”
“我们如何让各团队达成共识？”
“我担心我们遗漏了某些信息”
“站在他们的角度看这件事”
“X和Y之间的优先级冲突”
“利益相关者认同策略”

What Is It

方法概述

A structured analysis that:

Identifies relevant roles (stakeholders with different goals, constraints, incentives)
Adopts each perspective (inhabits mindset, priorities, success criteria of that role)
Articulates viewpoint (what this role cares about, fears, values, measures)
Surfaces tensions (where perspectives conflict, tradeoffs emerge)
Synthesizes alignment (finds common ground, proposes resolutions, sequences decisions)

Quick example (API versioning decision):

Engineer: "Deprecate v1 now—maintaining two versions doubles complexity and slows new features"
Product Manager: "Keep v1 for 12 months—customers need migration time or we risk churn"
Customer Success: "Offer v1→v2 migration service—customers value hand-holding over self-service docs"
Finance: "Charge for extended v1 support—converts maintenance burden into revenue stream"
Synthesis: Deprecate v1 in 12 months with 6-month free support + paid extended support option, PM owns migration docs + webinars, CS offers premium service

这是一种结构化分析方法，步骤如下：

识别相关角色（具有不同目标、约束、激励机制的利益相关者）
代入各角色视角（进入该角色的思维模式、优先级、成功标准）
明确立场观点（该角色关注什么、担忧什么、重视什么、如何衡量成果）
梳理矛盾冲突（找出视角冲突、取舍显现的环节）
合成共识方案（寻找共同点、提出解决方案、规划决策推进顺序）

快速示例（API版本决策）：

开发人员：“立即弃用v1版本——维护两个版本会让复杂度翻倍，拖慢新功能开发”
产品经理：“保留v1版本12个月——客户需要迁移时间，否则我们会面临用户流失风险”
客户成功：“提供v1→v2迁移服务——相比自助文档，客户更看重人工协助”
财务人员：“对v1的延长支持收费——将维护负担转化为收入来源”
共识方案：12个月后弃用v1版本，提供6个月免费支持+付费延长支持选项；PM负责迁移文档和线上研讨会；客户成功团队提供 premium 服务

Workflow

工作流程

Copy this checklist and track your progress:

Role Switch Progress:
- [ ] Step 1: Frame the decision or situation
- [ ] Step 2: Select relevant roles
- [ ] Step 3: Inhabit each role's perspective
- [ ] Step 4: Surface tensions and tradeoffs
- [ ] Step 5: Synthesize alignment and path forward

Step 1: Frame the decision or situation

Clarify what's being decided, key constraints (time, budget, scope), and why alignment matters. See Common Patterns for decision framing by type.

Step 2: Select relevant roles

Choose 3-6 roles with different goals, incentives, or constraints. See Role Selection Patterns for stakeholder mapping. For complex multi-stakeholder decisions → Study resources/methodology.md for RACI + power-interest analysis.

Step 3: Inhabit each role's perspective

For each role, articulate: what they optimize for, what they fear, how they measure success, what constraints they face. Use resources/template.md for structured analysis. For realistic roleplay → See resources/methodology.md for cognitive empathy techniques.

Step 4: Surface tensions and tradeoffs

Identify where perspectives conflict, map incompatible goals, articulate explicit tradeoffs. See Synthesis Principles for tension analysis.

Step 5: Synthesize alignment and path forward

Find common ground, propose resolutions that address core concerns, sequence decisions to build momentum. Self-check using resources/evaluators/rubric_role_switch.json. Minimum standard: Average score ≥ 3.5.

复制以下清单并跟踪进度：

角色切换法进度跟踪：
- [ ] 步骤1：明确决策或场景框架
- [ ] 步骤2：选择相关角色
- [ ] 步骤3：代入各角色视角
- [ ] 步骤4：梳理矛盾与取舍
- [ ] 步骤5：合成共识与推进路径

步骤1：明确决策或场景框架

厘清需要决策的内容、关键约束（时间、预算、范围），以及达成共识的重要性。可参考常见应用模式中按决策类型划分的框架示例。

步骤2：选择相关角色

选择3-6个具有不同目标、激励机制或约束的角色。可参考角色选择模式进行利益相关者映射。对于复杂的多利益相关者决策→学习resources/methodology.md中的RACI+权力-利益分析方法。

步骤3：代入各角色视角

针对每个角色，明确：他们的优化目标、担忧点、成功衡量标准、面临的约束。使用resources/template.md进行结构化分析。若要实现更真实的角色代入→参考resources/methodology.md中的认知共情技巧。

步骤4：梳理矛盾与取舍

找出视角冲突的环节，映射对立目标，明确具体的取舍内容。可参考共识合成原则进行矛盾分析。

步骤5：合成共识与推进路径

寻找共同点，提出能解决核心顾虑的方案，规划决策顺序以推进落地。使用resources/evaluators/rubric_role_switch.json进行自我检查。最低标准：平均得分≥3.5。

Role Selection Patterns

角色选择模式

Classic product triad (most common):

Engineering: Feasibility, technical debt, system complexity, maintainability
Product: User value, roadmap prioritization, market timing, feature completeness
Design: User experience, accessibility, consistency, delight

Business decision quads:

Finance: Cost, ROI, cash flow, unit economics, margin
Sales: Customer acquisition, deal closure, competitive positioning, quota attainment
Marketing: Brand perception, customer lifetime value, positioning, conversion funnel
Operations: Scalability, process efficiency, risk management, resource utilization

Regulatory/compliance contexts:

Legal: Risk mitigation, liability, contract terms, IP protection
Compliance: Regulatory adherence, audit trail, policy enforcement, certification
Privacy/Security: Data protection, threat model, access control, incident response
Ethics: Fairness, transparency, stakeholder impact, values alignment

External stakeholders:

End Users: Usability, reliability, cost, privacy, delight
Customers (B2B): Integration ease, support quality, vendor stability, total cost of ownership
Partners: Revenue share, mutual value, integration burden, strategic alignment
Regulators: Public interest, safety, competition, transparency

经典产品三角（最常用）：

开发：可行性、技术债务、系统复杂度、可维护性
产品：用户价值、路线图优先级、市场时机、功能完整性
设计：用户体验、可访问性、一致性、使用愉悦感

商业决策四方：

财务：成本、投资回报率、现金流、单位经济效益、利润率
销售：客户获取、交易达成、竞争定位、配额完成率
营销：品牌认知、客户生命周期价值、市场定位、转化漏斗
运营：可扩展性、流程效率、风险管理、资源利用率

合规/监管场景：

法务：风险缓解、责任界定、合同条款、知识产权保护
合规：监管合规、审计追踪、政策执行、认证要求
隐私/安全：数据保护、威胁建模、访问控制、事件响应
伦理：公平性、透明度、利益相关者影响、价值观对齐

外部利益相关者：

终端用户：易用性、可靠性、成本、隐私、使用愉悦感
企业客户（B2B）：集成便捷性、支持质量、供应商稳定性、总拥有成本
合作伙伴：收入分成、共同价值、集成负担、战略对齐
监管机构：公共利益、安全、竞争、透明度

Synthesis Principles

共识合成原则

Finding common ground:

Shared goals: What do all roles ultimately want? (e.g., company success, customer satisfaction)
Compatible sub-goals: Where do objectives align even if paths differ?
Mutual fears: What do all roles want to avoid? (e.g., reputational damage, security breach)

Resolving conflicts:

Sequential decisions: "Do X first (satisfies role A), then Y (satisfies role B)" (e.g., pilot then scale)
Hybrid approaches: Combine elements from multiple perspectives (e.g., freemium = marketing + finance)
Constraints as creativity: Use one role's limits to sharpen another's solution (e.g., budget constraint forces prioritization)
Risk mitigation: Address fears with safeguards (e.g., eng fears tech debt → schedule refactoring sprint)

When perspectives are truly incompatible:

Escalate decision: Flag for leadership with clear tradeoff framing
Run experiment: Pilot to gather data, convert opinions to evidence
Decouple decisions: Split into multiple decisions with different owners
Accept tradeoff explicitly: Document the choice and reasoning for future reference

寻找共同点：

共同目标：所有角色最终的诉求是什么？（例如：公司成功、客户满意度）
兼容子目标：即使路径不同，哪些目标是对齐的？
共同担忧：所有角色都想要避免什么？（例如：声誉受损、安全漏洞）

解决冲突：

顺序决策：“先做X（满足角色A），再做Y（满足角色B）”（例如：先试点再推广）
混合方案：结合多视角的元素（例如：免费增值模式=营销+财务视角结合）
以约束促创新：利用某角色的限制优化另一角色的方案（例如：预算约束倒逼优先级排序）
风险缓解：通过保障措施消除担忧（例如：开发担心技术债务→安排重构迭代）

当视角完全对立时：

升级决策：向领导层上报，明确说明取舍框架
开展实验：通过试点收集数据，将观点转化为证据
拆分决策：将决策拆分为多个子决策，由不同负责人推进
明确接受取舍：记录选择及理由，供未来参考

Common Patterns

常见应用模式

Pattern 1: Build vs Buy Decisions

Roles: Engineering (control, customization), Finance (TCO), Product (time-to-market), Legal (vendor risk), Operations (support burden)
Typical tensions: Eng wants control, Finance sees build cost underestimation, PM sees opportunity cost of delay
Synthesis paths: Pilot buy option with build fallback, build core/buy periphery, time-box build with buy backstop

Pattern 2: Feature Prioritization

Roles: PM (roadmap vision), Engineering (technical feasibility), Design (UX quality), Sales (customer requests), Users (actual need)
Typical tensions: Sales wants everything promised, Eng sees scope creep, Users want simplicity, PM balances all
Synthesis paths: MoSCoW prioritization (must/should/could/won't), release in phases, v1 vs v2 scoping

Pattern 3: Pricing Strategy

Roles: Finance (margin), Marketing (positioning), Sales (close rate), Customers (value perception), Product (feature gating)
Typical tensions: Finance wants premium, Sales wants competitive, Marketing wants simple, Product wants value-based tiers
Synthesis paths: Tiered pricing (serves multiple segments), usage-based (aligns value), anchoring (premium + standard)

Pattern 4: Organizational Change (e.g., return-to-office)

Roles: Leadership (collaboration), Employees (flexibility), HR (retention), Finance (real estate cost), Managers (productivity)
Typical tensions: Leadership sees serendipity loss, Employees see autonomy loss, Finance sees sunk cost, HR sees turnover
Synthesis paths: Hybrid model (balance), role-based policy (nuance), trial periods (data-driven), opt-in incentives (voluntary)

Pattern 5: Technical Migration

Roles: Engineering (technical improvement), PM (feature freeze), Users (potential downtime), DevOps (operational risk), Finance (ROI)
Typical tensions: Eng sees long-term benefit, PM sees short-term cost, Users fear disruption, Finance wants ROI proof
Synthesis paths: Incremental migration (reduce risk), feature parity first (minimize disruption), ROI projection (justify investment)

模式1：自研 vs 采购决策

涉及角色：开发（控制权、定制化）、财务（总拥有成本）、产品（上市时间）、法务（供应商风险）、运营（维护负担）
典型矛盾：开发想要控制权，财务认为自研成本被低估，产品担心延迟带来的机会成本
共识路径：先试点采购方案并保留自研备选，自研核心模块+采购外围模块，为自研设定时间上限并保留采购兜底

模式2：功能优先级决策

涉及角色：PM（路线图愿景）、开发（技术可行性）、设计（UX质量）、销售（客户需求）、用户（实际需求）
典型矛盾：销售想要兑现所有承诺，开发担心范围蔓延，用户想要简洁，PM需要平衡各方
共识路径：MoSCoW优先级划分（必须/应该/可以/不会做）、分阶段发布、v1与v2范围界定

模式3：定价策略决策

涉及角色：财务（利润率）、营销（市场定位）、销售（成交率）、客户（价值感知）、产品（功能分层）
典型矛盾：财务想要溢价，销售想要有竞争力的价格，营销想要简洁，产品想要基于价值的分层
共识路径：分层定价（覆盖多用户群体）、基于使用量定价（与价值对齐）、锚定定价（高端版+标准版）

模式4：组织变革（如返回办公室）

涉及角色：管理层（协作效率）、员工（灵活性）、HR（留存率）、财务（办公成本）、经理（生产力）
典型矛盾：管理层担心协作减少，员工担心自主权丧失，财务担心沉没成本，HR担心人员流失
共识路径：混合模式（平衡双方需求）、基于角色的政策（差异化管理）、试行期（数据驱动）、自愿参与激励

模式5：技术迁移决策

涉及角色：开发（技术优化）、PM（功能冻结）、用户（潜在停机）、DevOps（运营风险）、财务（投资回报率）
典型矛盾：开发看重长期收益，PM担心短期成本，用户害怕服务中断，财务想要投资回报证明
共识路径：增量迁移（降低风险）、先实现功能 parity（减少干扰）、投资回报率测算（证明价值）

Guardrails

注意事项

Avoid strawman perspectives:

Don't caricature roles (e.g., "Finance only cares about cost cutting")
Inhabit perspective charitably—what's the strongest version of this viewpoint?
Seek conflicting evidence to your own bias

Distinguish position from interest:

Position: What they say they want (surface demand)
Interest: Why they want it (underlying need)
Example: "I want this feature" (position) because "customers are churning" (interest = retention)
Synthesis works at interest level, not position level

Acknowledge information asymmetry:

Some roles have context others lack (e.g., Legal sees confidential liability exposure)
Flag assumptions: "If Legal has info we don't, that could change this analysis"
Invite real stakeholders to validate your perspective-taking

Don't replace actual stakeholder input:

Role-switch is for preparing conversations, not replacing them
Use to pressure-test before presenting, not as substitute for gathering input
Best used when stakeholder access is limited or to refine proposals before socializing

Power dynamics matter:

Not all perspectives carry equal weight in decision-making (hierarchy, expertise, accountability)
Synthesis should acknowledge who has decision authority
Don't assume consensus is always possible or desirable

避免刻板印象视角：

不要丑化角色（例如：“财务只关心削减成本”）
善意代入视角——这个角色最有力的观点是什么？
寻找与自身偏见相反的证据

区分立场与诉求：

立场：他们表面上想要什么（显性需求）
诉求：他们为什么想要这个（潜在需求）
示例：“我想要这个功能”（立场）是因为“客户正在流失”（诉求=留存用户）
共识需要从诉求层面切入，而非立场层面

承认信息不对称：

有些角色掌握其他角色不知道的信息（例如：法务了解未公开的责任风险）
标注假设：“如果法务掌握我们不知道的信息，可能会改变本次分析”
邀请真实利益相关者验证你的视角分析

不要替代真实利益相关者的输入：

角色切换法用于准备沟通，而非替代沟通
用于展示前的压力测试，而非替代收集真实反馈
最适合利益相关者接触有限，或在提案推广前优化方案的场景

权力动态很重要：

并非所有视角在决策中的权重相同（层级、专业度、问责制）
共识方案应明确谁拥有决策权
不要假设共识总是可能或必要的

Quick Reference

快速参考

Resources:

Quick analysis: resources/template.md
Complex stakeholder mapping: resources/methodology.md
Quality rubric: resources/evaluators/rubric_role_switch.json

5-Step Process: Frame Decision → Select Roles → Inhabit Perspectives → Surface Tensions → Synthesize Alignment

Role selection: Choose 3-6 roles with different goals, incentives, constraints

Synthesis principles: Find shared goals, resolve conflicts (sequential, hybrid, constraints as creativity), escalate when incompatible

Avoid: Strawman perspectives, position vs interest confusion, replacing actual stakeholder input

资源：

快速分析模板：resources/template.md
复杂利益相关者映射：resources/methodology.md
质量评估标准：resources/evaluators/rubric_role_switch.json

5步流程：明确决策框架→选择角色→代入视角→梳理矛盾→合成共识

角色选择：选择3-6个具有不同目标、激励机制、约束的角色

共识合成原则：寻找共同目标、解决冲突（顺序决策、混合方案、以约束促创新）、对立时升级决策

避免事项：刻板印象视角、混淆立场与诉求、替代真实利益相关者输入