AI 时代,产品规划(Roadmap)该从路线图升级成学习系统(Learning System)

每到季度规划，产品团队都会进入一套很熟的动作。

需求池拉出来，优先级排一轮，老板意见收一轮，跨部门资源再磨一轮。

几轮会开完，终于得到一张看起来很完整的 Roadmap。

它通常也确实很完整。

只是这张图刚放进文档，现实已经在旁边改稿了。

模型能力变了，竞品节奏变了，用户预期变了，老板判断也变了。团队还拿着三个月前排好的功能表，去指挥一个按周变化的 AI 产品。

有点像拿纸质地图开自动驾驶。

地图没有错。

路况已经不听它的了。

我现在越来越明确的判断是：

AI 时代，有没有 Roadmap 不是分水岭。分水岭在于，团队还会不会把它当成一张功能承诺表。

更有效的规划，不能只靠把未来三个月的功能写得更满。它要把产品规划升级成一套 Product Learning System：目标清楚，假设可验证，原型跑得快，资源也能跟着重新分配。

听起来像一套方法论。

拆开看，其实很朴素。

AI 产品里，很多问题一开始就没人知道答案。规划的第一任务，是搭一套机制，让团队更快知道答案，而不是装作答案已经有了。

旧 Roadmap 最大的问题：它把不确定性包装成确定性

传统产品路线图默认了三个前提。

第一，你大概知道该做什么。

第二，功能做出来，价值大概率也就出来了。

第三，变化是例外，计划才是常态。

这三个前提，在很多 AI 产品里都站不太稳。

用户要的到底是一个 AI 助手，还是原流程里某一步更快？

一个能力应该独立做入口，还是藏进原来的工作流？

Demo 很惊艳，真实用户会不会连续用两周？

结果质量到什么程度，用户才愿意把工作交给它？

这类问题放进优先级表里也排不明白，它们先要被识别出来。

如果团队还用旧式 Roadmap 来管，就很容易出现一种假忙：功能越来越多，会议越来越满，版本越来越勤，核心问题却没被回答。

用户习惯没有形成。

业务结果没有变化。

团队只是把“不确定的问题”，排成了一张“看起来确定的表”。

这才是旧 Roadmap 让人不安的地方。它不会让团队停止规划，它会让团队误以为自己已经规划清楚了。

Slack 给的启发：原型要用来学习，不只是做小版本

Slack 工程团队写过一篇关于 Prototyping 的文章，里面有个点很适合拿来对照产品规划。

他们说，团队变大以后，很容易滑回 waterfall：先有想法，再研究，再设计，再开发。

流程看着规整。

速度往往慢下来。

Slack 没有只喊一句“更敏捷”，而是把原型当成学习和评估过程。大致三步：先提出假设，提前定义成功和失败；再用可以丢弃的原型快速执行；最后评估、记录，再决定下一步。

这里的重点不是“原型更快”。

重点是规划的对象变了。

以前规划写答案：我们要做 A、B、C。

现在规划先写问题：我们最需要验证什么？如果这个假设错了，后面哪些投入都不该发生？

这就是 AI 产品规划的分水岭。

好的规划，先把学习问题写清楚，再决定功能怎么排。

很多团队卡就卡在这里。

他们也做原型，但原型只是一个小号版本。没有成功标准，没有失败边界，也没有把结论沉淀下来。项目复盘时，大家只记得“我们试过”，但说不清“试出了什么”。

这很亏。

在不确定性高的产品里，学习结论本身就是组织资产。

新路线图先看 Outcome，再看 Output

Atlassian 在产品发现材料里反复区分 output 和 outcome。

Output 是交付了什么。

Outcome 是用户行为或业务结果发生了什么变化。

这句话放到 AI 产品里，尤其刺眼。

AI 功能很容易制造 output 幻觉：一个按钮上线了，一个助手接入了，一个工作流跑通了，一个 Demo 让内部评审很兴奋。

可产品负责人要追问的，是另一组问题：用户有没有更频繁地回来？任务有没有更快完成？错误有没有减少？销售、客服、运营或产品团队的某个关键环节，有没有真的被改写？

这些没动，功能上线只是一个漂亮的提交记录。

所以路线图第一层不该先写功能，而该先写目标。

这不是写给汇报看的 OKR。它必须能决定资源去哪里。

比如“提升 AI 助手留存”，不要急着翻译成“做历史对话、语气切换、推荐入口”。

先问几个更扎实的问题：

用户没有持续使用，是因为没有稳定场景，还是因为结果不可信？

首次激活低，是入口问题，还是任务选择问题？

复用率差，是能力不够，还是用户不知道什么时候该用？

问题一换，路线图的粒度就变了。

它不再是功能许愿单，而是围绕 outcome 的假设清单。

Opportunity Solution Tree：先验证问题，再验证方案

Teresa Torres 的 Opportunity Solution Tree，很适合拿来改造 AI 产品规划。

它的顺序很简单：先有 outcome，再找机会，再拆方案，再设计实验。

这个顺序不能乱。

很多团队习惯反过来：先想方案，再给方案找目标，最后给目标配指标。

看起来也能凑成闭环。

但那是倒着长出来的闭环。

AI 产品最怕这个。因为 AI 太容易生成“看起来很先进”的方案。助手、Agent、自动总结、智能推荐、知识库问答，随便拿一个都像能写进季度规划。

问题是，它解决的是哪个机会？对应哪个 outcome？最大风险假设在哪里？

这里有一句很朴素的话：

探索项不要按交付项来管。

探索项最该交付的，往往不是一个完整功能，而是一个清楚结论：

这个问题是否存在？

这个方案是否有效？

这个方向是否值得加码？

产品负责人如果能把探索项的交付物从“功能上线”改成“学习结论”，团队的规划质量会马上变一个层级。

所以 AI 产品路线图里，每个探索项都应该写清楚四件事：

• • 目标是什么
• • 核心假设是什么
• • 成功和失败标准是什么
• • 最多投入多少资源、跑多久

这四件事写不出来，说明它还不适合进入路线图。

最多适合进入愿望池。

愿望池可以热闹。

路线图不能。

McKinsey 提醒我们：资源要跟着学习动

很多团队以为路线图是排期工具。

越往后看，它越像资源配置工具。

McKinsey 长期研究动态资源配置，结论很直接：能持续跑出来的组织，通常不会把资源平均铺开，而是会根据机会变化重新配置资源。

这放到 AI 产品里，就是一个很现实的问题：

你愿不愿意让 Roadmap 里的资源动起来？

很多团队嘴上说敏捷，但季度一开始，人力已经分完，项目已经坐实，所有方向看起来都要走完全程。

这不叫规划。

这叫开局把自己锁死。

更合理的做法，是把路线图分成三类：

核心交付项：目标清楚、路径明确，必须稳交付。

验证探索项：方向重要、路径不明，先小团队试。

防守响应项：客户、竞品、老板带来的必要动作，控制范围处理。

这三类项目，不应该用同一套管理方式。

核心交付项，看进度。

验证探索项，看学习。

防守响应项，看边界。

这一步做不出来，前面的学习都会打折。

因为团队就算学到了一个更好的机会，也没有资源去接。一个方向已经被证伪，也很难从路线图里退出。

最后，Roadmap 还是回到老样子：开局怎么排，年底怎么背。

中国团队落地，不用一上来改天换地

这套东西如果直接搬到很多中国公司，容易水土不服。

因为我们的现实很具体。

老板要确定性。

跨部门要承诺。

客户要排期。

销售要说法。

研发要边界。

所以我不建议一上来就说“以后不做功能路线图了”。

这句话很容易把自己送进会议室冷场区，空气突然安静。

更好的做法，是先在现有 Roadmap 上加三层信息。

第一层，把每个项目标注为核心交付、验证探索、防守响应。

不要让探索项背上稳定交付项的 KPI，也不要让防守响应项无限膨胀成战略项目。

第二层，每个验证探索项补四个字段。

目标、假设、成功/失败标准、资源上限。

这不是为了做表格，是为了防止项目中途变成“再给一点资源就快成了”的无底洞。

第三层，规划会换一组问题。

不要只问做不做、排第几、谁来做、什么时候上线。还要问：

• • 这个方向最大的不确定性是什么？
• • 哪条假设不验证清楚，大投入就很危险？
• • 这一轮原型到底要学到什么？
• • 如果结果超预期，资源从哪里来？
• • 如果结果不成立，谁有权停止？

这些问题听起来没有“功能排期”那么爽。

但它们更接近真实经营。

产品负责人要交付的，正在从一张图变成一套机制

过去，一个好的产品负责人要能交付一张清楚的路线图。

现在，他还要交付一套能持续变聪明的机制。

目标能做取舍，假设能被说清，原型能快速学习，资源能重新分配。

把这四件事连起来，你会发现 Roadmap 还在。

只是它不再是一张“我们已经决定好了”的表，而是一套记录当前下注、继续学习、及时改判的系统。

AI 时代的产品规划，最该升级的就是这里。

最后，给正在做季度规划的团队三个问题。

• • 这张路线图里，哪些项目是在交付确定性，哪些项目是在探索不确定性？
• • 每个 AI 探索项，有没有写清楚失败标准？
• • 有没有给学习结果预留资源机动位？

这三个问题答不清，Roadmap 大概率还是一张排期表。它可能很完整，但不一定能帮团队变聪明。

AI 时代，最好的路线图不是最稳定的那张。

更好的路线图，是一套能让团队更快识别机会、验证判断、把资源押到真机会上的机制。

产品规划，正在从 Roadmap 变成 Product Learning System。

谁先把这件事想清楚，谁就不只是会排计划。

他才是真的会下注。