每天挑选一期硅谷AI科技值得关注的播客，让你与前沿同频。如果你现在没空可以收藏进 晚点再听LaterCast，在通勤、走路或做家务时一篇篇轻松听完
"对我来说，理想的时间跨度是两到三个月。"
"真正的限制，是人们能否理解、能否消化你交给他们的东西。"
"如果已经完成了百分之九十九，最后却失败了，这种没有兑现的承诺反而更糟。"
OpenAI 的产品负责人留着一份专门记录自己预测错误的文档，用于提醒自己：想象中几年后的世界，常常并没有照着预期发生。可如果只按今天的模型能力做产品，又很容易在新能力出现时落后。
她给自己的规划期限是两到三个月。这段时间足够让团队提前准备，又不必把太多决定押在遥远的预测上。
在 Lenny and Friends Summit 的现场对谈中，Tara 与同在 OpenAI 负责产品的 Nan Yu 谈到，他们怎样在这种节奏下做产品。规划时间缩短之后，真正难做的判断仍然在：什么值得先推出去，用户能不能用起来，出了问题又该凭什么改。
规划多远，取决于什么正在变化
Tara 在 Stripe 工作过约七年。支付市场当然也有变化，但很多影响业务的因素是熟悉的，团队可以据此推演乐观、悲观和常规情形。换到 OpenAI，模型能力与市场变化交织在一起，她发现自己很难用同样的把握预测明年。
"如果你完全按照今天的情况来做产品，就会被甩在后面。所以我一直重复，往前看两到三个月。"
所以，她并没有建议所有公司取消年度规划。同样是在 Stripe，提前更久安排工作可能仍然合理。产品要规划到多远，得看它所依赖的市场和技术变化得有多快，不能因为 OpenAI 看未来九十天，就把所有业务都塞进同一个周期。
Tara Seshan 将两三个月的规划周期，与 OpenAI 所处市场的变化速度联系起来。
先让用户用起来，才能知道哪里想错了
缩短规划周期，也意味着不能把所有判断都留在上线之前。Tara 在 Stripe 时，习惯把细节反复想透，连代码里一个名字都要认真斟酌。到了 OpenAI，她需要更早看到用户到底怎么用。
"上线前你可以做很多推演，但没有什么能比得上亲眼看到用户尝试、使用，再据此迭代。"
她举的例子，是一个让用户切换使用方式的开关。这个入口不算理想，但它让团队能够先把能调用工具执行任务的 Agent 交到用户手里，又尽量不打断开发者已有的工作方式。以后也许连这个开关都不再需要，当下却不必因此一直等下去。
是否推出去，也不是只看速度。团队会先在内部使用：同事愿不愿意继续用，有没有值得保留的用途，是否发挥出了模型的新能力？这些反应，比上线前想象用户会喜欢什么更有说服力。
Nan 关心的是，后续再调整时，用户能不能理解为什么要变。一个临时设计可以被替换，但用户需要看得懂产品正在往哪里走，而不是每次打开都重新猜一遍。
模型能做很多，用户却可能不知道从哪开始
然而，把能力做出来，只完成了一部分工作。Tara 发现，许多企业客户还在把 ChatGPT 当成一问一答的聊天工具，团队却已经需要让他们接触可以执行任务的 Agent。发布得快，和客户学得会，是两件要同时处理的事。
Nan 因此更重视第一次使用。一个空输入框看似什么都能做，却把最难的一步留给了用户：我究竟该从哪里开始？如果人们不知道能拿它完成什么，再多的新功能也可能闲在那里。
他期待软件能更多地帮助用户开始任务，带着人做起来，而不是等人学会怎么提问。这也是他谈到未来软件时最看重的方向之一。
Tara 在给 OpenAI 的人力团队介绍新产品时，则体会到了语音的作用。直接说出想做的事，让一些人更容易上手。她看好语音，并不只是因为模型听得更准、回答更快，还因为说话本来就是人熟悉的表达方式。
助手越能干，越要讲清它代表谁
当用户开始让 Agent 代自己做事，产品还需要回答一个更难的问题：这些助手该怎么管？
是让用户面对一个能处理各种任务的助手，还是为每项工作配一个？Nan 用管理团队作比：大多数人很难同时跟进四十位直属员工，也很难同时盯住四十个助手。他观察到，许多人最终会设一个类似幕僚长的助手，让它去协调其他助手，自己主要与这一个沟通。
但把入口合成一个，并没有消除权限上的区别。同一个助手进入不同场景，可能需要使用不同账号，能看的资料也未必相同。Tara 尤其在意私密 Slack 频道这样的情形：助手在这里知道的事，到了别处该怎么处理？
"记忆应该怎么运作？它应该怎样和每个人交流？应该用这个人的凭证，还是用一套通用凭证？这些实际的产品问题太多了，具体使用场景非常重要。"
对用户来说，这些设计会影响信任。他需要知道助手可以看什么、正在代表谁做事，以及接下来大概会发生什么。Tara 认为，Agent 能自己行动的部分越多，这些事情就越不能让用户靠猜。
做到最后一步，才算完成用户的任务
用户愿意把事情交出去以后，还会遇到另一个落差：助手做了一大半，最后一步却卡住。Nan 认为，这种体验有时比一开始就做不了更糟。
"如果一开始就做不了，你可以自己做，或者换一种办法。但如果已经完成了百分之九十九，最后却失败了，这种没有兑现的承诺反而更糟。"
这也是 Tara 描述平台设计时，为什么会考虑给任务准备不止一条路径。会议资料可能在一个应用里，后续操作又要到另一个应用完成；有现成工具和接口，就调用它们，接不通时，再考虑让 AI 操作电脑界面。
Nan 对电脑操作的期待，正是它能补上这段空缺，代价可能是更慢、消耗更多模型调用资源。访谈没有给出它的成功率，但他对产品的要求是明确的：用户交付的是一件要完成的事，不能只把中间几个步骤做好，就当作已经兑现了承诺。
Nan Yu 讨论任务卡在最后一步时，为什么会让用户更加失望。
把用户的抱怨变成可以改进的依据
那么，团队怎么知道该改什么？“不好用”还不够，产品经理得找出用户具体在哪一步遇到了什么。
主持人 Claire Vo 经常直接给 OpenAI 团队发反馈，有时是觉得 AI 回答时“态度不好”。Nan 说，这样的反馈往往要追问两三轮才有用：它究竟说了哪句话，前面是什么情境？自然语言里的问题很细，只有听见一句不满意，还不知道该怎么处理。
Tara 与研究团队合作时，同样需要这样的细节。她会带着使用记录去讨论：用户想完成什么，模型为什么没做到？如果某种提示和工具组合已经能得到理想结果，就可以进一步研究，怎样通过训练让模型更稳定地做到。
她也在学习写评测，把这些任务和判断标准整理成能够反复检查的案例。模型改过之后，团队才有办法确认问题是否真的改善，而不只是觉得新版看起来不错。
理解用户、了解系统、关注细节，这些仍然是产品工作。只是当模型变化得更快，团队需要更频繁地经历试用、发现问题和修改的过程，计划也要跟着这些新认识调整。
写在最后
下一次做产品规划时，可以先把最依赖模型能力的几项安排挑出来，问问两三个月后，它们的前提还可能成立吗？同时找一位真实用户，看他能否从第一次打开产品走到任务完成。长期方向依然需要，但近期该做什么，最好能由这些实际使用中的困难来校准。
内容来源："Stop planning for 2027: how OpenAI builds product 90 days at a time | Tara Sesha and Nan Yu (OpenAI)"丨Lenny's Podcast（嘉宾：Tara Seshan、Nan Yu；主持人 Claire Vo）
原视频：https://www.youtube.com/watch?v=-ciSTkEVy30
相关文章
《史上增长最快产品：ChatGPT团队如何运作丨Lenny’s Podcast》 《Brex CEO：当CEO先被AI改变，公司才会变丨YC》 《Amplitude创始人：为什么未来是全自动软件开发？丨Delphi》
如果你现在没空，可以收藏进晚点再听，通勤、走路或做家务时一次性听完⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣