产品经理 · 任务逐条

把需求写下来

这是这个岗位最显眼的产出,也是生成做得最像样的一项 —— 从一段描述产出一份有结构的文档,几乎是理想情形。它同时也是外界评判这份工作时看到的大部分内容 —— 这就是为什么它的暴露感觉比实际更大。

为一件错的事写出一份漂亮的文档,比为一件对的事写一份粗糙的更糟。产出文档从来不是稀缺的那部分;知道该写哪一份才是。

决定不做什么

模型可以按给定的标准给需求池排序。它承担不了一次拒绝的政治代价,而拒绝本身就是那个决定 —— 一个团队没有做的每一件事,都是由那个愿意当「说不的人」的人决定的。

这是一条关于工作性质的判断,不是量出来的。这里没有任何东西说明组织对它的估值是正确的 —— 很多公司考核产品经理看的是产出,而不是他挡下了什么。

弄清楚到底哪里不对

工具现在能把访谈总结、把反馈聚类,做得不错,这有帮助。迁移不过去的是现场的判断 —— 注意到那一次迟疑、问出不在清单上的那个追问,以及知道某个人做的事和他刚说的话是矛盾的。

它没有说有多少产品经理真的在做这件事。在相当多的公司里,这个岗位从来不和用户说话 —— 对那些岗位来说,这项任务是理论上的。

让三个团队一起动起来

这是没有权力的影响力,发生在会议和走廊里,而且它构成了这份工作的大部分。这里没有任何东西可以被工具拿走,因为它的介质是别人的意愿。

这是对「工作落在哪儿」的描述,不是一次测量。它也没有说这件事做得好 —— 协调失败是产品延期最常见的原因之一。

在公开场合承认判断错了

为一次押注担责,是这个岗位的核心,而它没法委托给一个系统 —— 因为这件事的意义正在于「有一个人的判断被押上了」。当组织把这一条拿掉,这个岗位就退化成写工单 —— 而那恰恰是暴露的那一半。

它真不真实,完全取决于公司。很多产品经理有责任却没有让这份责任有意义的权力,而这一页没法告诉你某个具体岗位属于哪一种。

规定一个生成式功能可以对用户做什么

这是没有成型做法的新工作,而它落在产品而不是研发身上,因为这些问题问的是「可接受的伤害」与「用户的预期」,不是模型。在若干市场里,它同时正在从一种偏好变成一项需要留痕的义务。

新工作出现不等于新增编制,这里也没有任何东西说明公司在为它配人。在多数团队里,它目前是被「拥有这个功能的那个人」顺手接过去的。