prioritization-advisor

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Purpose

目的

Guide product managers in choosing the right prioritization framework by asking adaptive questions about product stage, team context, decision-making needs, and stakeholder dynamics. Use this to avoid "framework whiplash" (switching frameworks constantly) or applying the wrong framework (e.g., using RICE for strategic bets or ICE for data-driven decisions). Outputs a recommended framework with implementation guidance tailored to your context.

This is not a scoring calculator—it's a decision guide that matches prioritization frameworks to your specific situation.

指导产品经理选择合适的优先级框架，通过询问关于产品阶段、团队背景、决策需求和利益相关者动态的适应性问题。使用本工具可避免"框架摇摆"（频繁切换框架）或应用错误的框架（例如，将RICE用于战略赌注或将ICE用于数据驱动的决策）。输出根据你的具体情况量身定制的推荐框架及实施指南。

这不是一个评分计算器——而是一个将优先级框架与你的特定情况相匹配的决策指南。

Key Concepts

核心概念

The Prioritization Framework Landscape

优先级框架全景

Common frameworks and when to use them:

Scoring frameworks:

RICE (Reach, Impact, Confidence, Effort) — Data-driven, requires metrics
ICE (Impact, Confidence, Ease) — Lightweight, gut-check scoring
Value vs. Effort (2x2 matrix) — Quick wins vs. strategic bets
Weighted Scoring — Custom criteria with stakeholder input

Strategic frameworks:

Kano Model — Classify features by customer delight (basic, performance, delight)
Opportunity Scoring — Rate importance vs. satisfaction gap
Buy-a-Feature — Customer budget allocation exercise
Moscow (Must, Should, Could, Won't) — Forcing function for hard choices

Contextual frameworks:

Cost of Delay — Urgency-based (time-sensitive features)
Impact Mapping — Goal-driven (tie features to outcomes)
Story Mapping — User journey-based (narrative flow)

常见框架及其适用场景：

评分类框架：

RICE（Reach、Impact、Confidence、Effort）—— 数据驱动，需要指标支撑
ICE（Impact、Confidence、Ease）—— 轻量级，凭直觉评分
价值 vs. 投入（2x2矩阵）—— 快速制胜 vs. 战略赌注
加权评分—— 结合利益相关者输入的自定义标准

战略类框架：

Kano Model—— 根据客户满意度对功能分类（基础型、绩效型、愉悦型）
机会评分—— 评估重要性与满意度差距
购买功能—— 客户预算分配练习
MoSCoW（Must、Should、Could、Won't）—— 用于艰难抉择的强制决策法

场景类框架：

延迟成本—— 基于紧迫性（时间敏感型功能）
影响映射—— 目标导向（将功能与成果挂钩）
故事映射—— 基于用户旅程（叙事流程）

Why This Works

为何有效

Context-aware: Matches framework to product stage, team maturity, data availability
Anti-dogmatic: No single "best" framework—it depends on your situation
Actionable: Provides implementation steps, not just framework names

场景感知：根据产品阶段、团队成熟度、数据可用性匹配框架
反教条：没有单一的"最佳"框架——取决于你的具体情况
可操作：提供实施步骤，而非仅给出框架名称

Anti-Patterns (What This Is NOT)

反模式（本工具不适用的情况）

Not a universal ranking: Frameworks aren't "better" or "worse"—they fit different contexts
Not a replacement for strategy: Frameworks execute strategy; they don't create it
Not set-it-and-forget-it: Reassess frameworks as your product matures

不是通用排名：框架没有"优劣"之分——它们适配不同场景
不能替代战略：框架是执行战略的工具，而非制定战略
不是一劳永逸：随着产品成熟，需重新评估框架

When to Use This

何时使用本工具

Choosing a prioritization framework for the first time
Switching frameworks (current one isn't working)
Aligning stakeholders on prioritization process
Onboarding new PMs to team practices

首次选择优先级框架时
当前框架失效，需要切换时
就优先级流程与利益相关者达成一致时
向新PM介绍团队实践时

When NOT to Use This

何时不使用本工具

When you already have a working framework (don't fix what isn't broken)
For one-off decisions (frameworks are for recurring prioritization)
As a substitute for strategic vision (frameworks can't tell you what to build)

你已有一套运行良好的框架时（不要修复未损坏的东西）
用于一次性决策时（框架适用于重复的优先级排序）
作为战略愿景的替代品时（框架无法告诉你要构建什么）

Facilitation Source of Truth

引导实施的权威依据

Use

workshop-facilitation

as the default interaction protocol for this skill.

It defines:

session heads-up + entry mode (Guided, Context dump, Best guess)
one-question turns with plain-language prompts
progress labels (for example, Context Qx/8 and Scoring Qx/5)
interruption handling and pause/resume behavior
numbered recommendations at decision points
quick-select numbered response options for regular questions (include
```
Other (specify)
```
when useful)

This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.

使用

workshop-facilitation

作为本技能的默认交互协议。

它定义了：

会话提醒 + 进入模式（引导式、上下文转储、最佳猜测）
单轮提问，使用通俗易懂的提示语
进度标签（例如，Context Qx/8 和 Scoring Qx/5）
中断处理和暂停/恢复行为
决策点的编号建议
常规问题的快速选择编号选项（必要时包含
```
Other (specify)
```
）

本文件定义了特定领域的评估内容。若存在冲突，遵循本文件的领域逻辑。

Application

应用

This interactive skill asks up to 4 adaptive questions, offering 3-4 enumerated options at each step.

本交互式技能最多会提出4个适应性问题，每个步骤提供3-4个编号选项。

Question 1: Product Stage

问题1：产品阶段

Agent asks: "What stage is your product in?"

Offer 4 enumerated options:

Pre-product/market fit — "Searching for PMF; experimenting rapidly; unclear what customers want" (High uncertainty, need speed)
Early PMF, scaling — "Found initial PMF; growing fast; adding features to retain/expand" (Moderate uncertainty, balancing speed + quality)
Mature product, optimization — "Established market; incremental improvements; competing on quality/features" (Low uncertainty, data-driven decisions)
Multiple products/platform — "Portfolio of products; cross-product dependencies; complex stakeholder needs" (Coordination complexity)

Or describe your product stage (new idea, growth mode, established, etc.).

User response: [Selection or custom]

Agent提问： "你的产品处于哪个阶段？"

提供4个编号选项：

产品/市场契合前 —— "寻找PMF；快速试验；不清楚客户需求"（高度不确定性，需要速度）
早期PMF，规模化阶段 —— "找到初始PMF；快速增长；添加功能以留存/拓展用户"（中等不确定性，平衡速度与质量）
成熟产品，优化阶段 —— "市场地位稳固；增量改进；在质量/功能上竞争"（低不确定性，数据驱动决策）
多产品/平台 —— "产品组合；跨产品依赖；复杂的利益相关者需求"（协调复杂度高）

或描述你的产品阶段（新想法、增长模式、已确立等）。

用户回复： [选择或自定义内容]

Question 2: Team Context

问题2：团队背景

Agent asks: "What's your team and stakeholder environment like?"

Offer 4 enumerated options:

Small team, limited resources — "3-5 engineers, 1 PM, need to focus ruthlessly" (Need simple, fast framework)
Cross-functional team, aligned — "Product, design, engineering aligned; clear goals; good collaboration" (Can use data-driven frameworks)
Multiple stakeholders, misaligned — "Execs, sales, customers all have opinions; need transparent process" (Need consensus-building framework)
Large org, complex dependencies — "Multiple teams, shared roadmap, cross-team dependencies" (Need coordination framework)

Or describe your team/stakeholder context.

User response: [Selection or custom]

Agent提问： "你的团队和利益相关者环境如何？"

提供4个编号选项：

小型团队，资源有限 —— "3-5名工程师，1名PM；需要极其专注"（需要简单、快速的框架）
跨职能团队，目标一致 —— "产品、设计、工程团队对齐；目标明确；协作良好"（可使用数据驱动框架）
多个利益相关者，意见不一致 —— "高管、销售、客户各有意见；需要透明的流程"（需要共识构建框架）
大型组织，复杂依赖 —— "多个团队；共享路线图；跨团队依赖"（需要协调框架）

或描述你的团队/利益相关者背景。

用户回复： [选择或自定义内容]

Question 3: Decision-Making Needs

问题3：决策需求

Agent asks: "What's the primary challenge you're trying to solve with prioritization?"

Offer 4 enumerated options:

Too many ideas, unclear which to pursue — "Backlog is 100+ items; need to narrow to top 10" (Need filtering framework)
Stakeholders disagree on priorities — "Sales wants features, execs want strategic bets, engineering wants tech debt" (Need alignment framework)
Lack of data-driven decisions — "Prioritizing by gut feel; want metrics-based process" (Need scoring framework)
Hard tradeoffs between strategic bets vs. quick wins — "Balancing long-term vision vs. short-term customer needs" (Need value/effort framework)

Or describe your specific challenge.

User response: [Selection or custom]

Agent提问： "你通过优先级排序想要解决的主要挑战是什么？"

提供4个编号选项：

想法太多，不清楚该追求哪一个 —— "待办事项超过100项；需要缩小到前10项"（需要过滤框架）
利益相关者对优先级意见不一 —— "销售想要功能，高管想要战略赌注，工程想要处理技术债务"（需要对齐框架）
缺乏数据驱动的决策 —— "凭直觉优先级排序；想要基于指标的流程"（需要评分框架）
战略赌注与快速制胜之间的艰难权衡 —— "平衡长期愿景与短期客户需求"（需要价值/投入框架）

或描述你的具体挑战。

用户回复： [选择或自定义内容]

Question 4: Data Availability

问题4：数据可用性

Agent asks: "How much data do you have to inform prioritization?"

Offer 3 enumerated options:

Minimal data — "New product, no usage metrics, few customers to survey" (Gut-based frameworks)
Some data — "Basic analytics, customer feedback, but no rigorous data collection" (Lightweight scoring frameworks)
Rich data — "Usage metrics, A/B tests, customer surveys, clear success metrics" (Data-driven frameworks)

Or describe your data situation.

User response: [Selection or custom]

Agent提问： "你有多少数据可用于指导优先级排序？"

提供3个编号选项：

数据极少 —— "新产品，无使用指标，可供调研的客户很少"（基于直觉的框架）
部分数据 —— "基础分析、客户反馈，但没有严格的数据收集"（轻量级评分框架）
丰富数据 —— "使用指标、A/B测试、客户调研、明确的成功指标"（数据驱动框架）

或描述你的数据情况。

用户回复： [选择或自定义内容]

Output: Recommend Prioritization Framework

输出：推荐优先级框架

After collecting responses, the agent recommends a framework:

markdown

undefined

收集回复后，Agent会推荐一个框架：

markdown

undefined

Prioritization Framework Recommendation

Based on your context:

Product Stage: [From Q1]
Team Context: [From Q2]
Decision-Making Need: [From Q3]
Data Availability: [From Q4]

Based on your context:

Product Stage: [From Q1]
Team Context: [From Q2]
Decision-Making Need: [From Q3]
Data Availability: [From Q4]

Recommended Framework: [Framework Name]

Why this framework fits:

[Rationale 1 based on Q1-Q4]
[Rationale 2]
[Rationale 3]

When to use it:

[Context where this framework excels]

When NOT to use it:

[Limitations or contexts where it fails]

Why this framework fits:

[Rationale 1 based on Q1-Q4]
[Rationale 2]
[Rationale 3]

When to use it:

[Context where this framework excels]

When NOT to use it:

[Limitations or contexts where it fails]

How to Implement

Step 1: [First implementation step]

[Detailed guidance]
[Example: "Define scoring criteria: Reach, Impact, Confidence, Effort"]

[Detailed guidance]
[Example: "Define scoring criteria: Reach, Impact, Confidence, Effort"]

Step 2: [Second step]

[Detailed guidance]
[Example: "Score each feature on 1-10 scale"]

[Detailed guidance]
[Example: "Score each feature on 1-10 scale"]

Step 3: [Third step]

[Detailed guidance]
[Example: "Calculate RICE score: (Reach × Impact × Confidence) / Effort"]

[Detailed guidance]
[Example: "Calculate RICE score: (Reach × Impact × Confidence) / Effort"]

Step 4: [Fourth step]

[Detailed guidance]
[Example: "Rank by score; review top 10 with stakeholders"]

[Detailed guidance]
[Example: "Rank by score; review top 10 with stakeholders"]

Example Scoring Template

[Provide a concrete example of how to use the framework]

Example (if RICE):

Feature	Reach (users/month)	Impact (1-3)	Confidence (%)	Effort (person-months)	RICE Score
Feature A	10,000	3 (massive)	80%	2	12,000
Feature B	5,000	2 (high)	70%	1	7,000
Feature C	2,000	1 (medium)	50%	0.5	2,000

Priority: Feature A > Feature B > Feature C

[Provide a concrete example of how to use the framework]

Example (if RICE):

Feature	Reach (users/month)	Impact (1-3)	Confidence (%)	Effort (person-months)	RICE Score
Feature A	10,000	3 (massive)	80%	2	12,000
Feature B	5,000	2 (high)	70%	1	7,000
Feature C	2,000	1 (medium)	50%	0.5	2,000

Priority: Feature A > Feature B > Feature C

Alternative Framework (Second Choice)

If the recommended framework doesn't fit, consider: [Alternative framework name]

Why this might work:

[Rationale]

Tradeoffs:

[What you gain vs. what you lose]

If the recommended framework doesn't fit, consider: [Alternative framework name]

Why this might work:

[Rationale]

Tradeoffs:

[What you gain vs. what you lose]

Common Pitfalls with This Framework

[Pitfall 1] — [Description and how to avoid]
[Pitfall 2] — [Description and how to avoid]
[Pitfall 3] — [Description and how to avoid]

[Pitfall 1] — [Description and how to avoid]
[Pitfall 2] — [Description and how to avoid]
[Pitfall 3] — [Description and how to avoid]

Reassess When

Product stage changes (e.g., PMF → scaling)
Team grows or reorganizes
Stakeholder dynamics shift
Current framework feels broken (e.g., too slow, ignoring important factors)

Would you like implementation templates or examples for this framework?

---

Product stage changes (e.g., PMF → scaling)
Team grows or reorganizes
Stakeholder dynamics shift
Current framework feels broken (e.g., too slow, ignoring important factors)

Would you like implementation templates or examples for this framework?

---

Examples

示例

Example 1: Good Framework Match (Early PMF, RICE)

示例1：框架匹配良好（早期PMF + RICE）

Q1 Response: "Early PMF, scaling — Found initial PMF; growing fast; adding features to retain/expand"

Q2 Response: "Cross-functional team, aligned — Product, design, engineering aligned; clear goals"

Q3 Response: "Lack of data-driven decisions — Prioritizing by gut feel; want metrics-based process"

Q4 Response: "Some data — Basic analytics, customer feedback, but no rigorous data collection"

Recommended Framework: RICE (Reach, Impact, Confidence, Effort)

Why this fits:

You have some data (analytics, customer feedback) to estimate Reach and Impact
Cross-functional team alignment means you can agree on scoring criteria
Transitioning from gut feel to data-driven = RICE provides structure without overwhelming complexity
Early PMF stage = need speed, but also need to prioritize high-impact features for retention/expansion

When to use it:

Quarterly or monthly roadmap planning
When backlog exceeds 20-30 items
When stakeholders debate priorities

When NOT to use it:

For strategic, multi-quarter bets (RICE favors incremental wins)
When you lack basic metrics (Reach requires usage data)
For single-feature decisions (overkill)

Implementation:

Q1回复： "早期PMF，规模化阶段——找到初始PMF；快速增长；添加功能以留存/拓展用户"

Q2回复： "跨职能团队，目标一致——产品、设计、工程团队对齐；目标明确"

Q3回复： "缺乏数据驱动的决策——凭直觉优先级排序；想要基于指标的流程"

Q4回复： "部分数据——基础分析、客户反馈，但没有严格的数据收集"

推荐框架：RICE（Reach、Impact、Confidence、Effort）

为何适配：

你有部分数据（分析、客户反馈）可用于估算Reach和Impact
跨职能团队对齐意味着你们可以就评分标准达成一致
从直觉决策转向数据驱动 = RICE提供结构化方法，同时不会过于复杂
早期PMF阶段 = 需要速度，但也需要优先考虑高影响力功能以留存/拓展用户

何时使用：

季度或月度路线图规划
待办事项超过20-30项时
利益相关者对优先级有争议时

何时不使用：

用于战略性、跨季度赌注时（RICE更倾向于增量制胜）
缺乏基础指标时（Reach需要使用数据支撑）
用于单一功能决策时（大材小用）

实施步骤：

Step 1: Define Scoring Criteria

步骤1：定义评分标准

Reach: How many users will this feature affect per month/quarter?
Impact: How much will it improve their experience? (1 = minimal, 2 = high, 3 = massive)
Confidence: How confident are you in your Reach/Impact estimates? (50% = low data, 80% = good data, 100% = certain)
Effort: How many person-months to build? (Include design, engineering, QA)

Reach： 该功能每月/每季度会影响多少用户？
Impact： 它将在多大程度上改善用户体验？（1 = 极小，2 = 高，3 = 极大）
Confidence： 你对Reach/Impact的估算有多有信心？（50% = 数据不足，80% = 数据良好，100% = 确定）
Effort： 构建该功能需要多少人月？（包括设计、工程、QA）

Step 2: Score Each Feature

步骤2：为每个功能评分

Use a spreadsheet or Airtable
Involve PM, design, engineering in scoring (not just PM solo)
Be honest about Confidence (don't inflate scores)

使用电子表格或Airtable
让PM、设计、工程团队共同参与评分（而非仅PM独自完成）
如实评估Confidence（数据稀缺时，50%的信心是可以接受的）

Step 3: Calculate RICE Score

步骤3：计算RICE分数

Formula:

(Reach × Impact × Confidence) / Effort

Higher score = higher priority

公式：

(Reach × Impact × Confidence) / Effort

分数越高，优先级越高

Step 4: Review and Adjust

步骤4：审核与调整

Sort by RICE score
Review top 10-20 with stakeholders
Adjust for strategic priorities (RICE doesn't capture everything)

Example Scoring:

Feature	Reach	Impact	Confidence	Effort	RICE Score
Email reminders	5,000	2	70%	1	7,000
Mobile app	10,000	3	60%	6	3,000
Dark mode	8,000	1	90%	0.5	14,400

Priority: Dark mode > Email reminders > Mobile app (despite mobile app having high Reach/Impact, Effort is too high)

Alternative Framework: ICE (Impact, Confidence, Ease)

Why this might work:

Simpler than RICE (no Reach calculation)
Faster to score (good if you need quick decisions)

Tradeoffs:

Less data-driven (no Reach metric = can't compare features affecting different user bases)
More subjective (Impact/Ease are gut-feel, not metrics)

Common Pitfalls:

Overweighting Effort — Don't avoid hard problems just because they score low. Some strategic bets require high effort.
Inflating Confidence — Be honest. 50% confidence is okay if data is scarce.
Ignoring strategy — RICE doesn't capture strategic importance. Adjust for vision/goals.

按RICE分数排序
与利益相关者审核前10-20项
根据战略优先级进行调整（RICE无法涵盖所有因素）

评分示例：

功能	Reach	Impact	Confidence	Effort	RICE Score
邮件提醒	5,000	2	70%	1	7,000
移动应用	10,000	3	60%	6	3,000
深色模式	8,000	1	90%	0.5	14,400

优先级： 深色模式 > 邮件提醒 > 移动应用（尽管移动应用的Reach/Impact很高，但投入过大）

替代框架：ICE（Impact、Confidence、Ease）

为何适用：

比RICE更简单（无需计算Reach）
评分更快（适合需要快速决策的场景）

权衡：

数据驱动性较弱（无Reach指标 = 无法比较影响不同用户群体的功能）
主观性更强（Impact/Ease基于直觉，而非指标）

常见陷阱：

过度重视投入 —— 不要仅仅因为分数低就回避难题。一些战略赌注需要高投入。
高估信心 —— 如实评估。数据稀缺时，50%的信心是可以接受的。
忽略战略 —— RICE无法体现战略重要性。需根据愿景/目标进行调整。

Example 2: Bad Framework Match (Pre-PMF + RICE = Wrong Fit)

示例2：框架匹配不佳（Pre-PMF + RICE = 错误适配）

Q1 Response: "Pre-product/market fit — Searching for PMF; experimenting rapidly"

Q2 Response: "Small team, limited resources — 3 engineers, 1 PM"

Q3 Response: "Too many ideas, unclear which to pursue"

Q4 Response: "Minimal data — New product, no usage metrics"

Recommended Framework: ICE (Impact, Confidence, Ease) or Value/Effort Matrix

Why NOT RICE:

You don't have usage data to estimate Reach
Pre-PMF = you need speed, not rigorous scoring
Small team = overhead of RICE scoring is too heavy

Why ICE instead:

Lightweight, gut-check framework
Can score 20 ideas in 30 minutes
Good for rapid experimentation phase

Or Value/Effort Matrix:

Visual 2x2 matrix (high value/low effort = quick wins)
Even faster than ICE
Good for stakeholder alignment (visual, intuitive)

Q1回复： "产品/市场契合前——寻找PMF；快速试验"

Q2回复： "小型团队，资源有限——3名工程师，1名PM"

Q3回复： "想法太多，不清楚该追求哪一个"

Q4回复： "数据极少——新产品，无使用指标"

推荐框架：ICE（Impact、Confidence、Ease）或价值/投入矩阵

为何不选RICE：

你没有使用数据来估算Reach
Pre-PMF阶段 = 你需要速度，而非严格的评分
小型团队 = RICE评分的管理成本过高

为何选ICE：

轻量级，凭直觉评分的框架
30分钟内可完成20个想法的评分
适合快速试验阶段

或价值/投入矩阵：

可视化2x2矩阵（高价值/低投入 = 快速制胜）
比ICE更快
有助于与利益相关者对齐（直观、易懂）

Common Pitfalls

常见陷阱

Pitfall 1: Using the Wrong Framework for Your Stage

陷阱1：为错误阶段使用错误框架

Symptom: Pre-PMF startup using weighted scoring with 10 criteria

Consequence: Overhead kills speed. You need experiments, not rigorous scoring.

Fix: Match framework to stage. Pre-PMF = ICE or Value/Effort. Scaling = RICE. Mature = Opportunity Scoring or Kano.

症状： Pre-PMF初创公司使用包含10个标准的加权评分框架

后果： 管理成本扼杀了速度。你需要的是试验，而非严格的评分。

解决方法： 框架与阶段匹配。Pre-PMF = ICE或价值/投入矩阵。规模化 = RICE。成熟产品 = 机会评分或Kano Model。

Pitfall 2: Framework Whiplash

陷阱2：框架摇摆

Symptom: Switching frameworks every quarter

Consequence: Team confusion, lost time, no consistency.

Fix: Stick with one framework for 6-12 months. Reassess only when stage/context changes.

症状： 每季度切换框架

后果： 团队混乱、时间浪费、缺乏一致性。

解决方法： 坚持使用一个框架6-12个月。仅当阶段/场景变化时重新评估。

Pitfall 3: Treating Scores as Gospel

陷阱3：将分数视为绝对真理

Symptom: "Feature A scored 8,000, Feature B scored 7,999, so A wins"

Consequence: Ignores strategic context, judgment, and vision.

Fix: Use frameworks as input, not automation. PM judgment overrides scores when needed.

症状： "功能A得分8000，功能B得分7999，所以A胜出"

后果： 忽略了战略背景、判断和愿景。

解决方法： 将框架作为输入，而非自动化工具。必要时，PM的判断优先于分数。

Pitfall 4: Solo PM Scoring

陷阱4：PM独自评分

Symptom: PM scores features alone, presents to team

Consequence: Lack of buy-in, engineering/design don't trust scores.

Fix: Collaborative scoring sessions. PM, design, engineering score together.

症状： PM独自为功能评分，然后呈现给团队

后果： 缺乏认可度，工程/设计团队不信任评分。

解决方法： 协作评分会议。PM、设计、工程团队共同评分。

Pitfall 5: No Framework at All

陷阱5：完全没有框架

Symptom: "We prioritize by who shouts loudest"

Consequence: HiPPO (Highest Paid Person's Opinion) wins, not data or strategy.

Fix: Pick any framework. Even imperfect structure beats chaos.

症状： "我们谁喊得响就优先谁"

后果： HiPPO（最高薪资者的意见）胜出，而非数据或战略。

解决方法： 选择任意一个框架。即使是不完美的结构也比混乱好。

References

参考资料

Related Skills

External Frameworks

外部框架

Intercom, RICE Prioritization (2016) — Origin of RICE framework
Sean McBride, ICE Scoring (2012) — Lightweight prioritization
Luke Hohmann, Innovation Games (2006) — Buy-a-Feature and other collaborative methods
Noriaki Kano, Kano Model (1984) — Customer satisfaction framework

Intercom, RICE Prioritization (2016) —— RICE框架的起源
Sean McBride, ICE Scoring (2012) —— 轻量级优先级排序
Luke Hohmann, Innovation Games (2006) —— "购买功能"及其他协作方法
Noriaki Kano, Kano Model (1984) —— 客户满意度框架

Dean's Work

Dean的成果

[If Dean has prioritization resources, link here]

Skill type: Interactive Suggested filename:

prioritization-advisor.md

Suggested placement:

/skills/interactive/

Dependencies: None (standalone, but informs roadmap and backlog decisions)

[如果Dean有优先级排序相关资源，请在此链接]

技能类型： 交互式 建议文件名：

prioritization-advisor.md

建议存放位置：

/skills/interactive/

依赖： 无（独立工具，但会影响路线图和待办事项决策）