📅 产品路线图规划

🔹 第一步：明确产品愿景和目标

• 定义产品使命和长期愿景
• 设定核心业务目标（收入、用户增长、市场份额）
• 明确成功标准和关键指标

🔹 第二步：收集和分析需求

• 用户需求收集（用户调研、反馈分析）
• 市场趋势分析（竞品动态、技术发展）
• 内部需求（业务战略、技术架构）

🔹 第三步：需求优先级排序

• MoSCoW方法：Must-have（必须）、Should-have（应该）、Could-have（可以）、Won't-have（不做）
• RICE评分：影响力(Reach)、影响度(Impact)、置信度(Confidence)、投入(Effort)
• KANO模型：基本型需求、期望型需求、兴奋型需求

🔹 第四步：规划版本和里程碑

• 确定版本周期（通常4-12周）
• 分配功能到各个版本
• 定义每个版本的核心目标和交付物

🔹 时间导向型路线图

按时间顺序展示产品发展，适合向管理层和外部 stakeholders 展示长期规划。

🔹 目标导向型路线图

围绕核心目标组织功能，强调"为什么"而非"何时"，适合敏捷团队。

🔹 功能导向型路线图

以功能模块为核心，展示各功能的开发计划，适合技术团队。

🔹 MoSCoW 方法

• Must-have（必须有）：不做则产品不成立，如合规要求、核心功能
• Should-have（应该有）：重要但可延后，缺失会造成明显不满
• Could-have（可以有）：锦上添花，资源允许时纳入
• Won't-have（本次不做）：明确排除，避免范围蔓延

🔹 RICE 评分

得分 = Reach（覆盖人数） × Impact（影响程度） × Confidence（置信度） ÷ Effort（投入工作量）。
适合对大量需求做量化排序。关键是要统一各维度的评分标准，否则不同人打分不可比。

🔹 KANO 模型

• 基本型需求：不满足会强烈不满，满足了也没感觉——必须做到
• 期望型需求：做得越好越满意——竞争的正面战场
• 兴奋型需求：超出预期，带来惊喜——差异化的来源

🔹 不同对象看不同版本

• 对管理层：目标导向型，强调业务目标与里程碑，弱化具体日期
• 对研发团队：功能导向型，明确版本范围与技术依赖
• 对销售与客户：时间导向型，但需标注「计划，可能调整」，避免过度承诺

🔹 对齐机制

• 季度规划会：跨部门共同评审路线图，确认优先级与资源
• 月度检视：检查进度与前提假设是否变化
• 变更告知：路线图调整时主动说明原因，而非只发新版本——这决定了团队对路线图的信任度

🔹 把路线图做成功能清单

只罗列功能，未说明为什么做与成功标准。后果是团队只关注交付功能，不关注是否达成目标。

🔹 过度承诺时间点

为满足外部期望承诺具体日期，一旦延期损失信任。建议：对内用时间范围（如 Q3），对外用「计划中」并说明不确定性。

🔹 范围蔓延

不断加入新需求却不移除旧需求，导致所有版本都延期。建议：遵循「进一个出一个」原则，新增需求必须替换掉同等工作量的既有需求。

🔹 制定后不再更新

路线图长期不修订，逐渐与实际脱节，最终无人再看。建议：至少每季度正式更新一次。