@sillydaddy #4 感谢你的回复，你提出的几个问题非常到位，确实是我原文中没有展开讲清楚的地方，我详细说明一下。 **1. 关于“快速交付”与“抽取通用需求”的矛盾** 你问：“研发以敏捷开发的方式，快速交付，不正是你所希望的‘快速验证市场需求’吗？” 这是一个非常好的问题。我原文中批判的，并非敏捷开发所倡导的“快速交付价值”，而是一种**以牺牲长期价值为代价的“短期交付速度”**。 我理解的快速交付，不应是以牺牲代码的质量、团队其他成员的时间、客户的需求、项目的未来成长空间为前提。我举个例子：就拿 ASR （语音识别）相关的项目。我们现状是： - **技术上**：直接复制粘贴一套旧的、曾经能跑的代码，几乎不考虑因地制宜（不考虑不同用户端之间的区别），更不要说自己测试一下才提交，代码能跑起来就敢提交测试（期待发现问题之后再擦屁股，丝毫不想着提前请教团队大佬）——忘记了这里没有银弹，努力为埋下巨大的技术债添砖加瓦。 - **流程上**：这种交付方式把所有压力都转移给了产品和测试。PM 需要花大量时间为这种“技术捷径”导致的体验问题向客户解释，测试则在无穷无尽的回归测试中挣扎。 一句话说，按部就班地增加“屎山代码”，这应该谁来负责、谁来监督，全靠产品、测试？就如应付你的理发师一样，剪了就完事，不沟通、不用心。 --- **2. 关于“抽取通用需求”的责任归属：是 PM 还是研发总监？** 毫无疑问，定义需求、规划产品路径，毫无疑问是 PM 的核心职责。但抽取通用需求更是要建立领导的高瞻远瞩、优秀的项目交付、和若干相似的项目之上才能进行。 **公司高层没有为“从项目到产品”这条路设置正确的导航和激励**，压根走不到“抽取出产品的通用需求”这一步。 我认为，优秀的项目交付就如同好吃的料理一样，能赢来回头客——难道只靠金字招牌（老板的关系），一个饭馆就能成就百年口碑、做长久生意？ 但在我司的现实情况中，问题出在**战略缺位和组织目标错位**上。 - 第一，公司战略层面身体上不认可“项目产品化”。他们将项目视为一次性的“现金牛”，哪怕给客户多修一个隐藏 bug 都觉得亏了。 - 第二，我没有把抽取出产品的通用需求，看作是研发经理的锅。而是指责不用心交付项目（以伺候客户为耻）的现象。我司是研发总监平时叫得欢（好大喜功、多快好省、空中楼阁、好高骛远），一到夜里支持项目就尿遁。 - 第三，如果 KPI 是“项目交付速度和成本”，而不是“产品化贡献”或“技术资产沉淀”。在这种激励下，研发自然会选择最“省事”的方式——复制粘贴、快速结项。 总之，在我司没有严格的 KPI 的情况下，这种现象还出现，我觉得很诡异。

ToB 的是现有项目 ToC 的现有产品

@raydied #10 我从产品视角，反而觉得这个问题其实很简单，核心就是看团队里的成员有没有“以长线思维”作为核心价值观（这里的价值观是要践行在工作中，不是嘴上说说的）； 如果有： - 大家在考虑“是否应该做”的时候，会基于“一倍投入，多倍回报”的原则； - 做事情的时候践行“常思考，快推进”的节奏（这里是真的敏捷）； - 成员不会频繁扯皮，有问题便于在团队内部解决； 如果没有： - 多做一分就是亏，能不能遇到二期项目听天命，看运气； - 工作量是固定的，容易出现拍脑门的蔓延（容易出现只要做的快，就不能修改已经写好的代码）； - 频繁扯皮，拿着“客户说”和“老板说”的大旗瞎扯淡； 这个是人性和长期价值观与企业文化的果，kpi 只是中间衡量过程的工具，并不是其中的因。 即使 kpi 没有衡量约束和奖惩，但大家自己也会和团队的氛围对齐。

已经做出成绩、在行业/垂直领域有深厚积累的 toB ，是等需求上门，然后产品经理根据需求制定细节，直到客户满意，顺利地承接需求与产品之间的桥梁。客户也不会要求你搞什么快速交付，不会让你造一个百度/淘宝，只需要按部就班地实现合理的需求，一单的采购价足以养活公司好几年，这形成了一个对所有人有益的良性循环，产品越做越好，是大部分 toB 的最终幻想。 而没需求、没市场的 toB ，就得主动调研市场，上门推销，广撒网全都试一遍，有点苗头就快速出产第一个版本，这经常导致生产出一些奇形怪状的玩意。 所谓的快速交付、敏捷开发，是出资方承受不住高昂的用人成本，快进快出是很常见的模式，可以平摊风险。还有个常见模式是需求定下来扔给外包，中间商风险更低。混吃等死的小作坊则是瞎搞，碰运气做产品，碰运气找客户。想要做到健康的模式，内外阻力太大，市场没这么理想。 以上我都经历过，很多人把 toB 与外包画上约等号，挺合理，toB 出产垃圾的概率太高了。不过这也不是一个人或者几个人能改变的现状。

我嘞个天！ 如果你是产品经理，遇到这种情况，你难道不应该是笑疯吗？？？？？？ 我很多年前服务过一家餐饮企业 老板是深圳一个搞实业的，卖了企业给欧美巨头后，有了一大笔钱，就搞了一个团队做市场研究，各个行业一番调研后，投资成立了这家餐饮企业。 老板当时的目标是改变游戏规则：当时中国的餐饮企业、要么是一两个店规模；要么是开一个店、赚够钱了再开下一个的发展连锁，而他，准一次性投资 5 亿元，先开 4 家工厂、然后在工厂辐射区内迅速开店、1 年搞个 50 家的速度、然后上市割韭菜。 于是老板从当时各个著名餐饮企业中挖来各个岗位的人，在唐山、东莞、上海、成都建立了 4 家工厂，然后在北京、深圳、广州、上海、成都陆续开店。 结果：工厂建起来了、门店也建起来了、才发现一个重要问题 —— 门店的人员培养跟不上 —— 传统的一家店一家店开店的模式、一方面是积累资金、另一方面其实是在为新店培养人员。老板没做过餐饮、挖来的人又是不同企业出来、流程体系都在磨合中、竟然也没人提出，结果就是门店装修完了，才发现除了几个店长有人选外，店里的其他员工都不够、标准化就更不要提了。 老板没办法，就让各个店长在各地大量招人，然后统一送到东莞厂，在东莞厂内修了一家内部店，让来的员工在这里集中培训。 最后，工厂搞起来了、店也开了十多家、反响也还不错，但老板意兴阑珊了，于是关了工厂、卖了门店，解散了团队。 让我记忆深刻的是，吃散伙饭时，老板敬酒说：我一共投了 5 亿，已经用掉了一个多亿，这个学费我交了、以后大家在工作中一定要记住这段经历、工作开始前先真正调研清楚，别再像我一样犯错了。 所以，如果你是一个有追求的产品经理，遇到这种别人交学费、自己赚经验、万一成了有巨大回报、失败了影响不大的事儿，不正是锻炼自己能力的好机会吗？ 当然，如果你就是一个循规蹈矩、按部就班、喜欢稳定的人，那可能确实是灾难。

需求的模糊性

@lswlray 有个点存在差异: 是否已经发现问题所在. 已经发现问题所在的情况下, 再继续去做"错"的事, 本身就是一种煎熬. 时间浪费了, 成果没出来, 锅还得背身上 如果锅不是自己的, 只是以你说的这种"旁观者"角度去看一个故事, 那确实没问题啊, 吸取别人的经验肯定是好事

最近看了一本书《作对产品》,可以解决我的疑惑，产品方向决定了产品的成功和失败。 需求/市场不明确的话：高层，市场，产品经理都是的一群焦虑者，能做的就是忙起来，给失眠的老板提供一些正向的情绪价值

@lswlray #14 前提是有钱给你造啊。 举个例子，原本我们在按部就班迭代一套面向香港市场智慧工地场景的 saas 软件。后来，因为智慧工地没有新客户签单了，研发经理提议讲迭代计划就停止了，领导同意了——似乎只有我发表意见，大家都不 care 船往哪里开。目前就靠存量客户的需求为驱动——实在没办法了，屁股才往前挪一挪。 当初 0-1 的热情全都抛在脑后——也怪不得研发经理，他不在这个产品的迭代计划中。 为啥卡了，领导说要转型，要做 ai 大模型的相关项目。研发被调走后，一顿输出，不了了之。最后，两边全停摆了。现在的状态是团队以做大模型相关的 demo 自娱自乐——自己捏造或市场看一个需求，完成一个 demo 。 好容易有个大模型相关的项目——旧客服系统升级为智能客服，也不认真做；会的都做不精。对提出的一些迭代方向（诸如自动化解析文档内容、rag 的质量评估等等），这些极其重要的基础能力，也不想研究和优化。原因是这个项目就给了这么点儿钱，不能浪费时间在这上面。 问题都已经暴露了，研发经理也不去审核审核代码，整天问项目怎么还没结束？好像发现一个 bug 是现在最大的错误。