product-roadmap

产品路线图

概述

产品路线图是你对要开发什么以及何时开发的规划。对于个体创业者而言，路线图可以防止范围蔓延，让你专注于高影响力的工作，并帮助你对干扰说不。本指南将展示如何制定一份推动业务成果、而非只增加臃肿功能的路线图。

---

第 1 步：了解什么是路线图（以及不是什么）

路线图是：

• 按优先级排列的待解决问题或待实现成果清单
• 未来 3-12 个月的计划
• 向客户和利益相关者传达方向的工具
• 灵活的——会随着你的认知不断调整

路线图不是：

• 一项承诺（“我们会在 Y 日期发布 X”）
• 你曾收到的所有功能请求的清单
• 一成不变的——要做好每季度修订的准备

**核心原则：**路线图关注的是成果，而非功能。不要说“构建一个仪表盘”，而要说“帮助用户一目了然地了解数据”。

---

第 2 步：收集输入（功能创意的来源）

在确定优先级之前，先收集所有输入。创意来自多个来源：

输入来源：

1. 客户反馈（支持工单、功能请求、用户访谈）
2. 你的愿景（你希望产品长期发展到什么方向）
3. 竞争差距（竞争对手有、而你没有的功能）
4. 数据/分析（使用模式、流失节点、采用率低的功能）
5. 业务目标（实现收入/增长目标需要做到什么？）

收集方式：

• 创建一个待办列表（持续收集所有创意）。可以使用 Notion、Trello、Linear，甚至 Google Sheet。
• 对每个创意，记录：来源、要解决的问题、提出者，以及粗略估算（小/中/大）。

**规则：**收集时不要确定优先级。先把所有内容都记录下来。

---

第 3 步：使用框架确定优先级

你不可能把所有事情都做完。确定优先级，就是选择哪些事情不做。

框架：RICE 评分

RICE = 覆盖范围 × 影响力 × 信心度 ÷ 投入

为每项功能或项目评分：

**覆盖范围：**在给定时间段内，会影响多少用户？

• 示例：每月 100 位用户 = 100

**影响力：**这会对这些用户产生多大影响？

• 巨大 = 3，高 = 2，中 = 1，低 = 0.5，极小 = 0.25

**信心度：**你对覆盖范围和影响力估算有多大把握？

• 高 = 100%，中 = 80%，低 = 50%

**投入：**需要多少人周？

• 示例：2 周 = 2

RICE 评分 =（覆盖范围 × 影响力 × 信心度）/ 投入

示例：

Feature: "Add bulk export"
Reach: 200 users/month
Impact: 2 (high)
Confidence: 80%
Effort: 1 week

RICE = (200 × 2 × 0.8) / 1 = 320

按 RICE 评分对待办列表排序。评分最高 = 优先级最高。

替代框架：价值与投入矩阵

比 RICE 更简单。将每项功能放到 2×2 网格中：

        High Value
            |
  Quick Wins | Big Bets
------------|------------
 Time Sinks | Low Priority
            |
        Low Value

• 快速见效项（高价值、低投入）→ 优先完成
• 重大投入项（高价值、高投入）→ 快速见效项之后再做
• 时间黑洞（低价值、高投入）→ 永远不要做
• 低优先级项（低价值、低投入）→ 有空余精力时再做（通常没有）

如何选择：

• 当你掌握覆盖范围和影响力的数据时，使用 RICE
• 当你还处于早期阶段、估算较粗略时，使用价值与投入矩阵

---

第 4 步：规划路线图结构

按时间跨度组织路线图。个体创业者应该按季度规划，而非按月规划（变化太快，月度路线图很难保持准确）。

路线图结构：

NOW (Current Quarter)
  Theme: [What's the focus this quarter?]
  Features/Projects:
    1. [Highest priority item from Step 3]
    2. [Second highest priority]
    3. [Third highest — only if capacity allows]

NEXT (Next Quarter)
  Theme: [What's the likely focus?]
  Features/Projects:
    - [Top 3-5 candidates, but not committed]

LATER (6-12 months out)
  Theme: [Strategic direction]
  Features/Projects:
    - [High-level goals, not specific features]

**主题为何重要：**主题能让你的季度目标更加聚焦。“提升留存率”就是一个主题。它能帮助你判断某项功能请求是否符合当前优先事项，还是应该暂缓。

**每季度安排多少项功能？**对于独立开发者：2-4 项有意义的功能或项目。不要过度承诺。预计最终只有计划的 60-70% 能够发布——Bug、客户问题和生活中的突发状况都会发生。

---

第 5 步：沟通路线图

只放在脑海里的路线图毫无用处。与客户和利益相关者分享它。

分享渠道：

• 公开路线图（Trello、Notion，或 Canny、ProductBoard 等专用路线图工具）
• 产品内（从应用的菜单或帮助部分链接到路线图）
• 电子邮件更新（每季度向客户发送邮件：“以下是我们接下来要开发的内容”）
• 社交媒体（分享进展更新，庆祝已发布的功能）

公开分享与私下分享的内容：

• **公开：**主题、优先级最高的事项、大致时间安排（第 1 季度、第 2 季度，而非具体日期）
• **私下（仅限内部）：**详细规格、技术决策、被否决的想法

路线图事项的表述方式：

• 不要说：“我们将在 3 月 15 日发布 X”
• 而要说：“我们计划在第 1 季度发布 X。时间安排可能会根据后续发现有所调整。”

**重要原因：**承诺过多却交付不足会摧毁信任。少承诺、多交付则能建立信任。

---

第 6 步：整合客户反馈

客户会提出功能需求。有些请求很有价值，大多数则只是噪声。你的工作是筛选。

如何处理功能请求：

1. 确认收到并表示感谢。“感谢你的建议！我们会跟进这项需求。”
2. 提出澄清问题。“你希望通过这项功能解决什么问题？”（通常，客户请求的功能并不是解决其实际问题的最佳方案。）
3. **将其记录到待办列表中。**不要承诺一定会开发，但要跟踪记录。
4. **寻找规律。**如果有 10 个人提出相同需求，这就是需求信号。如果只有 1 个人提出，可能只是噪声（也可能是边缘情况）。

何时优先处理某项请求：

• 多位客户提出该请求（说明存在需求）
• 它符合你的产品愿景和业务目标
• 它在 RICE 或价值与工作量比较中得分较高

何时拒绝：

• 这是个别请求，没有明显规律
• 它会让你偏离主题或战略重点
• 它只惠及极少数人，却损害大多数人的利益
• 它会增加不值得其价值的复杂性

如何拒绝：

"Thanks for the suggestion! We're focused on [current theme] right now, so this
won't make it into the next few months. We'll keep it on the radar and revisit
as priorities evolve."

**原则：**每一个“是”，都意味着对其他某件事说“不”。坚决守住你的路线图。

---

第 7 步：每季度审查并调整

路线图是不断演进的文档。每季度都要审查并更新。

季度路线图审查（60-90 分钟）：

1. **回顾：**本季度发布了什么？哪些没有发布？为什么？
2. **衡量影响：**我们发布的功能是否推动了我们关注的指标？（留存率、收入、激活率等）
3. **收集新的输入：**收到了哪些反馈？市场发生了什么变化？我们学到了什么？
4. **重新确定优先级：**对待办列表重新运行优先级评估框架。下个季度有哪些事项应该进入“现在”？
5. **确定主题：**下个季度的重点是什么？
6. **沟通：**与客户分享更新后的路线图。

需要留意的危险信号：

• 你发布了大量功能，却没有任何功能推动关键指标（说明你做错了方向）
• 你的路线图 6 个月都没有变化（说明你没有学习或调整）
• 你总是在响应声音最大的客户（说明你已经失去了战略方向）

---

第 8 步：平衡快速迭代与战略愿景

作为一名独立创业者，你可以比大公司行动得更快。善用这一优势。

如何保持敏捷：

• 小步发布，快速测试。不要等 3 个月才推出“完美”的功能。用 2 周发布一个小版本，学习并迭代。
• 在承诺开发完整版本之前，先构建新功能的 MVP。
• 使用功能开关或 Beta 访问权限，在向所有人推出之前先与一小部分用户测试。

如何保持战略定力：

• 不要追逐每个新奇事物。坚持每季度的主题，除非发生重大变化。
• 留出 20-30% 的时间用于基础工作（重构、性能、UX 打磨）。这些内容不会出现在面向客户的路线图中，但很重要。

**平衡：**70% 的时间用于执行路线图，30% 用于探索和学习。

---

应避免的产品路线图错误

• 构建客户要求的所有功能。 你不是功能工厂。专注于解决问题，而不是堆砌功能。
• 不懂得说不。 每次答应，都意味着拒绝其他事情。学会拒绝那些与你的愿景不符的功能请求。
• 过早承诺具体日期。 路线图是计划，不是承诺。给出季度，而非具体日期。
• 发布后不衡量影响。 如果不检查某项功能是否产生了明显效果，你就会不断构建影响力低的东西。
• 对路线图保密。 客户欣赏透明度。分享你正在做的事情（概述即可）。
• 让路线图过时。 如果超过 6 个月没有更新，它就毫无用处。每季度审查一次。