产品经理

需求文档、工单、验收标准、发给研发的那份文件,以及往上汇报的那份材料。

在同一周里对一位客户、一位高管和一位工程师说不,而且给的理由是他们各自能复述出来的。

和真正用这东西的人聊,并分辨他们说的哪些是真的、哪些只是客气、哪些其实是伪装成需求的解决方案。

研发、设计、销售、法务与客服都按同一个决定行动 —— 而他们没有一个向你汇报。

功能上线了,数字没动 —— 总要有人把这件事说出来,并决定接下来怎么办。

决定这个功能允许在哪些地方出错、哪些地方必须给出依据、哪些必须拒绝,以及它在客户面前出错时会怎样。

你最先会被交派的活 —— 写工单和需求文档 —— 是暴露的那一半,而把它做好本身并不会让你成为一个产品经理。让这个岗位变成一份职业的,是你被信任去决定「什么不做」,而那份信任是靠先在小事上公开地判断正确挣来的。

如果你一周主要在写文档和同步进度,那是承压的那种配置 —— 而它也正是很多公司悄悄造出来的那种配置。如果你一周主要在做「你能为之辩护的拒绝」和「你自己拥有的决定」,暴露度就低。区别不在资历,在于这个岗位有没有带着一个决定。

保住并强化

确认这个岗位带着一个决定

这份工作暴露的那个版本,是「把别人做的决定写下来」。耐久的那个版本是「做决定」。你手上是哪一种,通常取决于公司,不取决于你的能力。

调整职责

把「AI 功能被允许做什么」接过来

每一个带生成式功能的产品,都需要有人决定它可以在哪儿出错、必须拒绝什么。那是一个产品决定,在多数团队里目前没人认领,而在若干市场里它正在变成需要留痕的义务。

相邻转岗

转到约束是真实的地方

受监管的产品、硬件、支付 —— 在这些领域里,「做错东西」的代价是具体的而不是名誉上的,因此那个决定必须由某个人扛着。

对这个岗位来说这是个错的问题,因为暴露度取决于你手上是哪一个版本的工作,不取决于时间。写需求文档与工单在很大程度上已经是机器的活。而「决定什么不做」、以及「为一次失败的押注答复」,完全没有动。一个你自己能核对的信号:你的团队最近上线的五件事里,有几件是你决定的,而不是你记录的。

能,而且写得不错 —— 这恰恰说明那份文档从来就不是这份工作。规格是一个决定的记录,而价值一直在「做决定」上:让哪个客户失望、把哪个季度花掉、哪个问题才是真正的问题。如果文档就是你所在的组织用来考核你的交付物,那这件事值得你重新认识一下这家组织。

够分得清「估算」和「猜」就行 —— 而这条线是移动了,不是抬高了。当生成让原型变便宜,有用的技术判断就从「什么难做」挪向了「什么难运维、什么难撤回」—— 而这些代价,已经不再体现在第一版要花多久上了。

「做」变便宜,让「决定」的后果更大而不是更小:当一个团队用过去做一件事的时间能做五件,做错五件的代价就是五倍。它真正改变的是:这个岗位不能再靠「协调开发」来证明自己的必要性了。它必须靠选择的质量来证明 —— 那是一条更高的线,也是一条更诚实的线。