2 篇博文 含有标签「product-roadmap」

你画了一个包含六个季度的 AI 路线图。模型切换、新数据源、多语言发布，以及现在提供建议的提示词，在甘特图上各占一行，并根据工程量的大小确定了尺寸。接着，第一次发布推迟了四周，而复盘报告在三个不同的章节里重复了三次同样的话：“正在等待法务。”路线图原本假设工程能力是关键限制。而实际的瓶颈约束是一堆法务审查队列，每个审查都有自己三到六周的 SLA，且彼此互不知晓，最终全都压在仅有的两名产品法务身上。

错误并不在于任何一项单独的审查。每一项都是有理有据的。错误在于将四个并行功能视为四个并行的时间线，而它们的法务依赖却通过同一个上游资源进行串行处理。到第二次延期时，组织了解了问题的轮廓。到第四次时，它学会了针对此进行规划。那些能够以可预测节奏发布 AI 功能的团队，已经不再将法务吞吐量视为外部的意外，而是开始将其视为与人力和基础设施容量同等地位的规划输入。

一位产品经理拉出了下个季度的路线图。其中三个功能被标记为“依赖下一代模型”。没人问如果下一代模型延期、比演示版本缩水 20%、或者发布的版本仅限你的客户没有资格使用的企业级层级，会发生什么。六个月后，这三种情况都发生了，团队现在正在针对实际发布的模型重建两个季度的架构——而这个模型的形态与他们当初计划的完全不同。

这就是“每周模型路线图”：将尚未发布的能力声明视为确定性的依赖。这是将 12 个月的计划变成 30 个月计划最可靠的方法之一。而在当时，这看起来几乎没有风险，因为每个厂商的演示都让人觉得大势所趋。计划的破坏是隐形的，直到延期产生复合影响。