创业公司三段式路线图
使用场景: 创始人或早期 PM，在没有固定日期的情况下传达产品方向
现在：核心 MVP 功能——认证、创建、分享
现在：关键 Bug 修复和性能优化
接下来：协作功能——评论、@提及
接下来：与前三名工具集成
以后：移动端 App
以后：企业级 SSO 和管理控制
这样组织的原因: 三段式路线图在团队还在摸索用户需求时避免了按季度排日期的虚假精确——它传达优先级和顺序，但不承诺一个会滑坡的 DDL。
产品路线图示例
下面这些案例展示了不同公司阶段和受众的产品经理如何结构化产品计划。每个案例对应一种真实的路线图场景——从创业公司的三段式到企业级季度计划——找最接近你产品和团队的那个直接调整。
真实案例
SaaS 季度路线图
使用场景: 产品经理，向 B2B SaaS 的研发和管理层汇报
Q1 主题：激活——让用户更快达到首次价值
Q1 计划：引导向导、空状态改版
Q2 主题：扩展——向上进攻团队客户
Q2 计划：角色权限、审计日志、SSO
Q3 主题：留存——月流失率降至 2% 以下
Q3 计划：健康度评分、主动触达、CS 仪表盘
这样组织的原因: 用目标主题而不是功能列表命名每个季度，向管理层表明团队理解业务目标——这也让在同一主题内增减功能变得更自然，不需要改变整体战略。
移动 App 路线图
使用场景: 移动端 PM，规划 iOS 和 Android 三个季度的版本发布
Q1：与 Web 端功能对齐（iOS 和 Android）
Q1 里程碑：App Store 上线
Q2：离线模式和数据同步
Q2：Push 通知和用户激活流程
Q3：社交功能——关注、分享、个人主页
Q3 里程碑：10 万下载目标
这样组织的原因: 移动端路线图需要明确标出 App Store 里程碑，因为审核提交需要提前规划时间——把里程碑放在路线图上，让研发截止日期在实际日期前几周就变得可见。
B2B 平台路线图（面向销售团队）
使用场景: PM，制作与销售和客户成功团队共享的路线图
Q1：API v2（解锁企业集成需求）
Q1：批量导入/导出（12 个客户的需求）
Q2：高级权限管理（企业级合同要求）
Q2：SOC 2 Type II 认证（里程碑）
Q3：自定义品牌（增购机会）
Q3：独立基础设施选项（大型企业）
这样组织的原因: 面向销售团队的路线图应该包含每个计划对应的客户原因——"12 个客户有需求"给销售提供了可以在谈单中使用的上下文，而不需要过度承诺。
上线后迭代路线图
使用场景: PM，管理有活跃用户的产品在发布后的持续迭代
第 1 个月：关键 Bug 修复（来自上线反馈）
第 2 个月：性能优化（p99 延迟）
第 3 个月：最高票需求功能 #1（高级用户群体）
第 3 个月：引导体验改善（来自激活数据）
第 4 个月：最高票需求功能 #2
第 4 个月：定价页 A/B 测试
这样组织的原因: 上线后路线图应该在前几个月明确包含 Bug 修复和性能工作——不写进去会向研发传递稳定性不如新功能重要的信号，而这通常是错误的。
内部工具路线图
使用场景: 研发或 IT 团队，构建和维护内部系统
Q1：迁移老旧管理后台到新技术栈
Q1：用户自助管理（减少 IT 工单）
Q2：运营团队报表仪表盘
Q2：自动化入职工作流
Q3：所有工具的单点登录
Q3：审计和合规日志
这样组织的原因: 内部工具路线图在每个计划对应可量化的减少工单数量、手动工作或耗时时，更容易获得批准——量化业务影响证明了研发投入的价值。
使用技巧
- 用主题或目标作为行标题，而不是功能名称——干系人围绕目标对齐，而不是实现细节。
- 按受众制作不同版本：研发需要任务级细节，高管需要目标级主题，销售需要面向客户的利益点。
- 把事项标注为已承诺、很可能做、探索中，让读者知道哪些是确定的、哪些可能会变。
- 每六到八周回顾和更新一次路线图——从不更新的路线图会失去信任，最终被所有人忽视。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=product-roadmap
使用这个模板