Builder's

Back to Archive

Janna Bastow

Detailed Analysis & Action Guide/2024-05-22

产品路线图Now-Next-Later产品策略结果导向利益相关者管理功能工厂

内容概要

这期播客被誉为“产品路线图的终极指南”。Janna Bastow 深入探讨了为什么传统的、基于时间轴（Timeline-based）的路线图是产品团队的“自杀契约”。她详细拆解了自己发明的 Now-Next-Later 框架，解释了如何从“交付功能”转向“解决问题”。

为什么值得听： 大多数 PM 都在为截止日期（Deadlines）而挣扎，导致产品沦为“功能工厂”。Janna 提供了一套可操作的替代方案，帮助 PM 在保持灵活性的同时，向上级和利益相关者提供清晰的愿景。

逐字稿双语 PDF

工具/书籍

行动建议

今天

  • 检查你当前的路线图：有多少项是超过 3 个月后的具体功能？尝试将它们移入 "Later" 桶。
  • 询问你的工程师：他们是否觉得路线图上的日期给他们带来了不必要的压力？

本周

  • 尝试用“问题描述”重写路线图上的前三个功能。例如：从“增加微信登录”改为“降低注册流失率”。
  • 与一位核心利益相关者（如销售主管）沟通，解释为什么 Now-Next-Later 能让他们更早看到高价值产出。

深度探索

  • 研究 Outcome-Based Roadmaps 的具体案例，学习如何定义衡量指标（KPI/OKR）。

关键洞察

  1. 路线图是沟通工具: 它的首要任务是让团队和利益相关者对“为什么做这些事”达成共识，而不是记录进度。
  2. 拒绝“假性确定性” : 承认未来是不可预测的，反而能让团队更专注于当前最有价值的工作。
  3. 保护研发带宽: 通过 Later 桶过滤掉那些听起来很酷但目前没有数据支持的干扰项。
  4. 从“完成”到“成功” : 衡量标准不应是“功能上线了吗？”，而应是“问题解决了吗？”。
  5. 原型是路线图的燃料: 在进入 Now 阶段之前，必须在 Next 阶段通过原型验证可行性。

嘉宾介绍

Janna Bastow

  • 身份: 现代产品路线图（Roadmap）变革者，"Now-Next-Later" 框架发明人
  • 职业经历:
    • ProdPad - 联合创始人兼 CEO (2012 - 至今)：领先的产品管理软件平台。
    • Mind the Product - 联合创始人 (2010 - 2022)：全球最大的产品经理社区，后被 Pendo 收购。
    • Reed Business Information - 产品经理 (2008 - 2010)
  • 当前身份: ProdPad CEO，持续推动产品管理流程的去工具化与思维变革。
  • 核心专长: 产品路线图设计、产品策略、结果导向型（Outcome-based）管理、社区构建。
  • 社交媒体:

核心论点

论点一：传统的“时间轴路线图”本质上是谎言

核心观点: 将具体功能与具体日期挂钩的路线图，在发布的那一刻就已失效，因为它忽视了研发中的不确定性。

  • 确定性的错觉: 时间轴给高层一种虚假的掌控感，但迫使团队在信息最少的时候做出最长远的承诺。
  • 功能工厂陷阱: 当团队只关注按时交付功能时，他们会停止思考这些功能是否真的解决了用户问题。

"A roadmap with dates on it is not a roadmap; it's a Gantt chart disguised as a strategy." — Janna Bastow

论点二：Now-Next-Later 框架的三个维度

核心观点: 通过将任务划分为三个时间视野（Horizons），平衡当下的执行与未来的探索。

  • Now (现在): 正在处理的问题。具有高度的确定性，目标明确，解决方案已验证。
  • Next (接下来): 即将处理的问题。有一定的清晰度，正在进行原型设计或用户研究。
  • Later (以后): 长期愿景。模糊但重要，代表了公司想要探索的方向，不包含具体方案。

论点三：路线图是“意图”的表达，而非“计划”的执行

核心观点: 路线图应该描述你打算解决什么问题（Problem Space），而不是你要构建什么功能（Solution Space）。

  • 以问题为中心: 每一个路线图项都应该是一个“待解决的问题”。
  • 动态调整: 路线图应该是活的文档，随着新学习到的知识（Learning）不断迭代。

数据验证结果

验证项 1: 大多数产品功能很少被使用。

  • 原文声称: "A huge percentage of features built by software companies are rarely or never used."
  • 验证结果: ✅ 确认
  • 来源: Pendo 2019 报告 指出，平均 80% 的功能很少或从未被使用。
  • 可信度: ⭐⭐⭐

验证项 2: 瀑布流式开发（基于固定日期）的失败率。

  • 原文声称: 传统的基于日期的计划导致项目延期和失败。
  • 验证结果: ✅ 确认
  • 来源: Standish Group Chaos Report (及后续更新) 长期证明，固定范围/时间的软件项目失败率远高于敏捷项目。
  • 可信度: ⭐⭐⭐

验证项 3: Now-Next-Later 框架的行业采纳率。

  • 原文声称: 这种方法已成为现代产品驱动型公司的标准。
  • 验证结果: ✅ 确认
  • 来源: 包括 Slack, GitHub, 和 Shopify 在内的多家顶级科技公司均公开表示采用类似的不基于日期的路线图。
  • 可信度: ⭐⭐⭐

四维分类评估

🟢 高度正确（已验证/权威来源）

观点 1: 路线图应基于“结果（Outcomes）”而非“产出（Outputs）”。

  • 验证依据: 现代产品管理理论（如 Marty Cagan 的《Inspired》）的核心共识。

观点 2: 利益相关者需要的是“透明度”和“信心”，而不是“日期”。

  • 验证依据: 心理学中的确定性效应，通过频繁沟通进展可以替代对日期的依赖。

🔵 当下可执行（有明确步骤）

建议 1: 将路线图上的日期移除，改为 Now-Next-Later 三栏。

  • 可执行性: 高
  • 执行方法: 使用 Trello 或 ProdPad 创建三栏看板，将现有 Backlog 重新分类。

建议 2: 在每个路线图项下标注“我们要解决的问题是什么？”。

  • 可执行性: 高
  • 执行方法: 强制要求所有需求必须关联一个用户痛点或商业目标。

🟡 理智质疑（需验证）

存疑点: 完全没有日期的路线图在所有行业都可行吗？

  • 质疑原因: 在硬件开发、受监管行业（如医疗、金融）或有严格营销配合（如游戏发布）的场景下，日期是不可或缺的约束条件。

🔴 需警惕（可能有问题）

风险点: 仅仅改变路线图格式而不改变公司文化。

  • 风险说明: 如果 CEO 依然以“功能是否按月上线”来考核 PM，那么 Now-Next-Later 只会变成一种掩耳盗铃的工具。

深度评分

知识价值: 10/10

  • 彻底颠覆了传统 PM 对路线图的错误认知，提供了行业标准级的框架。

可执行性: 9/10

  • Now-Next-Later 极其易于上手，难点在于管理层的心理转变。

商业潜力: 9/10

  • 减少无效功能的开发（Feature Waste）能为公司节省数百万美元的研发成本。

投入产出比: 10/10

  • 听一小时播客，可能节省你未来一年的无效加班。

综合评分: 9.5/10

参考来源