roadmap-prioritization-planning
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseRoadmap & Prioritization Skill
路线图与优先级排序技能
Master the art of saying "no". Create focused roadmaps that align your organization, drive strategic outcomes, and maximize impact with limited resources.
掌握说“不”的艺术。制定聚焦的路线图，让组织协同一致，推动战略落地，在有限资源下实现价值最大化。
RICE Scoring System (Complete)
RICE评分系统（完整版）
Formula
计算公式
RICE Score = (Reach × Impact × Confidence) / Effort
Reach: How many users affected? (1-100+)
- 10+ = 10
- 100+ = 100
- 1000+ = 1000
Impact: Per-user impact (3, 2, 1, 0.5)
- 3 = Massive (10x improvement)
- 2 = High (significant improvement)
- 1 = Medium (noticeable improvement)
- 0.5 = Low (minor improvement)
Confidence: How confident? (0.25-1.0)
- 1.0 = High (research backed)
- 0.8 = Medium (some validation)
- 0.5 = Low (minimal validation)
- 0.25 = Very low (assumption)
Effort: Engineer-weeks needed (1-20+)RICE Score = (Reach × Impact × Confidence) / Effort
Reach: How many users affected? (1-100+)
- 10+ = 10
- 100+ = 100
- 1000+ = 1000
Impact: Per-user impact (3, 2, 1, 0.5)
- 3 = Massive (10x improvement)
- 2 = High (significant improvement)
- 1 = Medium (noticeable improvement)
- 0.5 = Low (minor improvement)
Confidence: How confident? (0.25-1.0)
- 1.0 = High (research backed)
- 0.8 = Medium (some validation)
- 0.5 = Low (minimal validation)
- 0.25 = Very low (assumption)
Effort: Engineer-weeks needed (1-20+)Scoring Example Matrix
评分示例矩阵
Feature Reach Impact Confidence Effort RICE Score
────────────────────────────────────────────────────────
User Onboarding 50 3 0.8 8 (50×3×0.8)/8 = 15.0
Dark Mode 200 1 0.9 4 (200×1×0.9)/4 = 45.0
API Limits 500 2 0.7 10 (500×2×0.7)/10 = 70.0
Performance Fix 1000 0.5 1.0 5 (1000×0.5×1)/5 = 100.0
Custom Fields 30 3 0.6 12 (30×3×0.6)/12 = 4.5
PRIORITIZE: Performance > API Limits > Dark Mode > Onboarding > Custom FieldsFeature Reach Impact Confidence Effort RICE Score
────────────────────────────────────────────────────────
User Onboarding 50 3 0.8 8 (50×3×0.8)/8 = 15.0
Dark Mode 200 1 0.9 4 (200×1×0.9)/4 = 45.0
API Limits 500 2 0.7 10 (500×2×0.7)/10 = 70.0
Performance Fix 1000 0.5 1.0 5 (1000×0.5×1)/5 = 100.0
Custom Fields 30 3 0.6 12 (30×3×0.6)/12 = 4.5
PRIORITIZE: Performance > API Limits > Dark Mode > Onboarding > Custom FieldsRICE Confidence Levels
RICE置信度等级
High (1.0) - Research-backed
- Customer interviews conducted
- Data from analytics
- Customer support tickets confirming
- Clear customer demand
Medium (0.8) - Some validation
- Logical assumption
- One or two customers requesting
- Industry trends suggest it
- Similar features successful elsewhere
Low (0.5) - Minimal validation
- Educated guess
- Competitive pressure (they have it)
- Opportunity emerged
- Needs deeper validation
Very Low (0.25) - Pure assumption
- "Seems like good idea"
- No customer feedback
- No validation whatsoever
- High risk of waste
高置信度（1.0）- 有研究支撑
- 已开展客户访谈
- 有分析数据支持
- 客户支持工单确认需求
- 客户需求明确
中置信度（0.8）- 部分验证
- 逻辑合理的假设
- 1-2位客户提出需求
- 行业趋势指向该需求
- 同类功能在其他场景成功落地
低置信度（0.5）- 少量验证
- 有依据的猜测
- 竞品已推出该功能（竞争压力）
- 出现新的机会点
- 需要进一步验证
极低置信度（0.25）- 纯假设
- “看起来是个好主意”
- 无任何客户反馈
- 未做任何验证
- 资源浪费风险高
Alternative Prioritization Methods
其他优先级排序方法
Value vs Effort Matrix
价值-投入矩阵
Low Effort High Effort
High Value QUICK WINS STRATEGIC
(Do first) (Plan carefully)
Low Value FILL-INS AVOID
(If time) (Skip)Quick Wins: High value, low effort
- Implement first for momentum
- Build confidence
- Show stakeholders progress
- Examples: Bug fixes, small features
Strategic: High value, high effort
- Long-term competitive advantage
- Requires planning and resources
- Examples: New platform, architecture
Fill-Ins: Low value, low effort
- Polish features
- Technical debt
- Do when capacity available
Avoid: Low value, high effort
- Waste of resources
- Say "no" clearly
Low Effort High Effort
High Value QUICK WINS STRATEGIC
(Do first) (Plan carefully)
Low Value FILL-INS AVOID
(If time) (Skip)快速制胜项： 高价值、低投入
- 优先落地以积累动力
- 建立团队信心
- 向相关方展示进展
- 示例：Bug修复、小型功能
战略项： 高价值、高投入
- 带来长期竞争优势
- 需要详细规划和资源支持
- 示例：新平台搭建、架构升级
填充项： 低价值、低投入
- 功能优化
- 技术债务清理
- 有空闲资源时再处理
规避项： 低价值、高投入
- 浪费资源
- 明确说“不”
MoSCoW Method (Simpler)
MoSCoW方法（简化版）
Must Have (Non-negotiable for launch)
- Core functionality
- Without these: launch doesn't happen
- Usually 40% of work
Should Have (Important but deferrable)
- Significant value
- Could launch without but less attractive
- Usually 30% of work
Could Have (Nice to have)
- Polish, nice features
- Do if budget/time allows
- Usually 20% of work
Won't Have (Explicitly out of scope)
- Clearly deferred
- Helps stakeholders understand priorities
- Usually 10% of work
必须具备（Must Have）（上线必备，不可协商）
- 核心功能
- 缺少则无法上线
- 通常占工作量的40%
应该具备（Should Have）（重要但可延期）
- 价值显著
- 没有也能上线，但吸引力下降
- 通常占工作量的30%
可以具备（Could Have）（锦上添花）
- 功能优化、特色功能
- 预算/时间充足时再做
- 通常占工作量的20%
不会具备（Won't Have）（明确排除在当前范围外）
- 明确延期至未来版本
- 帮助相关方理解优先级
- 通常占工作量的10%
Kano Model (Customer Satisfaction)
卡诺模型（客户满意度导向）
Three feature categories:
Basic Factors (Threshold)
- Expected to be present
- Absence = very dissatisfied
- Presence = satisfied (not delighted)
- Example: Core app functionality
- No competitive advantage
Performance Factors (Linear)
- More = more satisfaction
- Less = less satisfaction
- Competitive advantage
- Examples: Speed, customization options
- Scales continuously
Delighters (Excitement)
- Unexpected features
- Presence = delighted
- Absence = neutral
- High competitive advantage
- Examples: Surprising UX, hidden features
Strategy: Must haves first, then performance, then delighters for differentiation
三类功能：
基础型需求（Basic Factors）（门槛项）
- 用户默认应该存在的功能
- 缺失会导致用户极度不满
- 存在仅能让用户满意（不会惊喜）
- 示例：应用核心功能
- 无竞争优势
期望型需求（Performance Factors）（线性关联）
- 功能越好，用户满意度越高
- 功能越差，用户满意度越低
- 能带来竞争优势
- 示例：速度、自定义选项
- 满意度随功能提升持续增长
兴奋型需求（Delighters）（惊喜项）
- 用户未预期的功能
- 存在会让用户惊喜
- 缺失用户也不会不满
- 高竞争优势
- 示例：超出预期的UX设计、隐藏功能
策略： 先满足基础型需求，再处理期望型需求，最后通过兴奋型需求实现差异化
Roadmap Planning Process
路线图规划流程
12-Month Strategic Roadmap
12个月战略路线图
Structure:
Q1 2025: Initiative Theme
├─ Goal: Business outcome
├─ Key Features: 2-3 major features
├─ Success Metrics: How you measure
└─ Resource: Team size needed
Q2 2025: Initiative Theme
Q3 2025: Initiative Theme
Q4 2025: Initiative Theme结构：
Q1 2025: Initiative Theme
├─ Goal: Business outcome
├─ Key Features: 2-3 major features
├─ Success Metrics: How you measure
└─ Resource: Team size needed
Q2 2025: Initiative Theme
Q3 2025: Initiative Theme
Q4 2025: Initiative ThemeQuarterly Planning Process
季度规划流程
Timeline: Plan month before quarter starts
Week 1: Data Gathering
- Customer feedback from last quarter
- Support tickets and issues
- Competitive landscape changes
- Team retrospective learnings
- Metrics review vs targets
Week 2: Prioritization
- Apply RICE scoring
- Consider strategic goals
- Assess resource availability
- Get engineering estimates
- Map dependencies
Week 3: Planning
- Break stories into sprints
- Allocate resources
- Identify risks
- Plan communication
Week 4: Alignment & Launch
- Present roadmap to stakeholders
- Engineering team commitment
- Executive buy-in
- All hands announcement
时间线： 季度开始前1个月启动规划
第1周：数据收集
- 上一季度的客户反馈
- 支持工单与问题
- 竞争格局变化
- 团队回顾总结的经验
- 指标与目标对比复盘
第2周：优先级排序
- 应用RICE评分
- 结合战略目标
- 评估资源可用性
- 获取开发团队的估算
- 梳理依赖关系
第3周：详细规划
- 将需求拆解为迭代任务
- 分配资源
- 识别风险
- 规划沟通方案
第4周：对齐与启动
- 向相关方展示路线图
- 开发团队确认承诺
- 管理层认可
- 全员会议宣布
Sprint Planning (Weekly)
迭代规划（每周）
Monday: Planning
- Pick features for sprint
- Break into user stories
- Estimate effort
- Assign owners
- Identify blockers
Daily: Standups
- What did you do?
- What's blocking you?
- What's next?
- 15 minutes max
Friday: Retrospective
- What went well?
- What needs improvement?
- Velocity tracking
- Plan adjustments for next sprint
周一：规划会议
- 选择本次迭代的功能
- 拆解为用户故事
- 估算工作量
- 分配负责人
- 识别阻塞点
日常：站会
- 已完成工作
- 当前阻塞问题
- 下一步计划
- 时长不超过15分钟
周五：回顾会议
- 哪些工作进展顺利？
- 哪些需要改进？
- 跟踪团队交付速度
- 规划下一次迭代的调整方案
Resource Allocation
资源分配
Team Capacity Planning
团队容量规划
Team Size: 5 engineers
Sprint Length: 2 weeks
Typical Capacity: 40-50 story points
Planning Reality:
- 50% unplanned work (bugs, interrupts)
- 20% operational tasks
- 30% feature development
Result: 50 points × 30% = 15 points for features
→ Add MUST have items first
→ Fill remaining capacity with SHOULD/COULDTeam Size: 5 engineers
Sprint Length: 2 weeks
Typical Capacity: 40-50 story points
Planning Reality:
- 50% unplanned work (bugs, interrupts)
- 20% operational tasks
- 30% feature development
Result: 50 points × 30% = 15 points for features
→ Add MUST have items first
→ Fill remaining capacity with SHOULD/COULDResource Distribution
资源分配比例
Engineering Team:
- 60-70% new features (roadmap)
- 20-30% bug fixes & optimization
- 10-15% technical debt
- 5-10% operations/support
Product Manager:
- 60% planning and discovery
- 20% communication and alignment
- 10% analysis and metrics
- 10% team leadership
Design Team:
- 70% feature design
- 15% design system maintenance
- 15% research and testing
开发团队：
- 60-70% 新功能开发（路线图项）
- 20-30% Bug修复与优化
- 10-15% 技术债务清理
- 5-10% 运维/支持工作
产品经理：
- 60% 规划与需求探索
- 20% 沟通与对齐
- 10% 分析与指标跟踪
- 10% 团队管理
设计团队：
- 70% 功能设计
- 15% 设计系统维护
- 15% 研究与测试
Dependencies & Sequencing
依赖项与排序
Dependency Types
依赖类型
Hard Dependency
- Feature B can't start until Feature A done
- Example: Payment system before subscription plans
- Impacts timeline significantly
Soft Dependency
- Feature B better if Feature A done first
- Example: Mobile app after web fully tested
- Flexible on timing
Cross-Team Dependency
- Requires other team completion
- Longest lead time
- Must surface early
强依赖
- 功能B必须在功能A完成后才能启动
- 示例：支付系统搭建完成后才能开发订阅功能
- 对时间线影响显著
弱依赖
- 功能B在功能A完成后启动更佳
- 示例：移动端应用在网页版充分测试后再开发
- 时间线灵活
跨团队依赖
- 需要其他团队完成相关工作
- 前置时间最长
- 必须尽早识别
Risk Management
风险管理
Common Risks:
-
Scope Creep
- Mitigation: Say "no" often, defer to future
- Owner: Product Manager
- Plan: Weekly scope review
-
Key Person Leaves
- Mitigation: Cross-training, documentation
- Owner: Engineering Manager
- Plan: Onboarding process
-
Timeline Pressure
- Mitigation: Plan with buffer, manage expectations
- Owner: Product Manager
- Plan: Transparent communication
-
Technical Challenges Emerge
- Mitigation: Spike time, proof of concepts
- Owner: Engineering Lead
- Plan: 20% contingency in estimates
常见风险：
-
范围蔓延
- 缓解方案：经常说“不”，将需求延期至未来版本
- 负责人：产品经理
- 计划：每周进行范围评审
-
核心人员离职
- 缓解方案：交叉培训、完善文档
- 负责人：开发经理
- 计划：建立标准化入职流程
-
时间线压力
- 缓解方案：规划时预留缓冲、管理预期
- 负责人：产品经理
- 计划：保持沟通透明
-
技术难题出现
- 缓解方案：预留研究时间、制作概念验证原型
- 负责人：技术负责人
- 计划：估算时预留20%的应急时间
Roadmap Communication
路线图沟通
For Executives
面向管理层
- Focus on business outcomes
- Show how each quarter builds toward vision
- Highlight competitive differentiation
- Revenue/growth impact
- 聚焦业务成果
- 展示各季度如何推进愿景落地
- 突出竞争差异化
- 强调收入/增长影响
For Engineering
面向开发团队
- Detailed specs and requirements
- Technical complexity and dependencies
- Effort estimates and risks
- Resource needs
- 提供详细的规格与需求
- 说明技术复杂度与依赖关系
- 工作量估算与风险
- 资源需求
For Customers
面向客户
- User-focused benefits
- Timeline (quarter, not date)
- Most-requested features highlighted
- Under-promise, over-deliver
- 聚焦用户价值
- 提供大致时间范围（按季度，而非具体日期）
- 突出用户呼声最高的功能
- 留有余地，超预期交付
For Sales
面向销售团队
- "Coming soon" messaging
- What they can sell against
- Customer feedback incorporated
- Competitive differentiation
- “即将推出”的沟通话术
- 可用于销售的卖点
- 说明已纳入客户反馈
- 竞争差异化优势
Roadmap Review & Adjustment
路线图评审与调整
Weekly: Sprint progress
Monthly: Quarterly progress vs plan
Quarterly: Full roadmap refresh
Annually: Strategic direction review
Triggers for Reprioritization:
- Major customer churn
- Competitive threat
- Market shift
- Unexpected technical blocker
- Resource availability change
每周： 迭代进度跟踪
每月： 季度进度与计划对比
每季度： 全面更新路线图
每年： 战略方向评审
触发重新优先级排序的场景：
- 大量客户流失
- 竞品威胁
- 市场变化
- 突发技术阻塞
- 资源可用性变化
Troubleshooting
问题排查
Yaygın Hatalar & Çözümler
常见错误与解决方案
| Hata | Olası Sebep | Çözüm |
|---|---|---|
| Roadmap sürekli kayıyor | Unrealistic estimates | 30% buffer ekle |
| Priority debates | Unclear criteria | RICE workshop |
| Resource contention | Over-commitment | Capacity planning |
| Dependencies blocking | Late identification | Sprint 0 mapping |
| 错误 | 可能原因 | 解决方案 |
|---|---|---|
| 路线图不断延期 | 估算不切实际 | 增加30%的缓冲时间 |
| 优先级争议 | 标准不明确 | 开展RICE评分工作坊 |
| 资源冲突 | 过度承诺 | 进行容量规划 |
| 依赖项阻塞 | 识别过晚 | 在Sprint 0阶段梳理依赖 |
Debug Checklist
调试检查清单
[ ] RICE scoring consistent mi?
[ ] Capacity realistic mi? (20% buffer)
[ ] Dependencies mapped mi?
[ ] Stakeholder alignment var mı?
[ ] Risk mitigation planı var mı?[ ] RICE评分是否一致？
[ ] 容量估算是否合理？（预留20%缓冲）
[ ] 依赖项是否已梳理？
[ ] 是否已与相关方达成一致？
[ ] 是否有风险缓解计划？Recovery Procedures
恢复流程
- Roadmap Slip → Re-prioritize, cut scope
- Resource Conflict → Trade-off matrix
- Priority Disagreement → Data-driven RICE
Master prioritization and create roadmaps that drive real outcomes!
- 路线图延期 → 重新排序优先级，削减范围
- 资源冲突 → 使用权衡矩阵决策
- 优先级分歧 → 基于数据的RICE评分
掌握优先级排序，制定能带来实际成果的路线图！