[吐槽] 到底是“先有项目还是先有产品”？高层战略=空气，产品经理=许愿池？

各位 V 友，我最近在思考困扰了好久的问题，想和大家探讨一下：“到底是先有项目还是先有产品？”，以及“大家都想做产品，是不是招个产品经理就能有产品了？”

当高层战略模糊，方向不明时；总有人拎不清，想当然地对产品经理说：“去搞个新产品出来。” 仿佛这样就万事大吉了（锅甩出去了）。

这画面真的很迷。一个产品的诞生，难道不应该是市场有机会、高层定战略、业务提需求，然后 PM 来承接、规划和推动落地吗？

什么时候 PM 成了“无中生有”的魔法师了？

我司现在的逻辑变成了：

高层没想清楚 → 让 PM 自己“创造需求” → 研发跟着一起蒙眼狂奔 → 项目大概率烂尾 → 结论：这个 PM 不行。

这锅甩的，堪称天外飞仙。PM 是需求的翻译官和资源的协调器，不是“从空气中抓取一个商业模式”的魔法师。

这个问题在 B 端和 C 端体现得尤其不同，我想分开聊聊：

对于 B 端：到底是先有项目，还是先有产品？

很多 B 端业务的起点，确实是一个深度定制，几乎是“保姆式”开发的项目，但又如何？为了服务好这个客户，大家一起努力，产品经理在其中努力做好客户和研发之间的桥梁。

当然，有些研发通情达理、做事尽心尽责，有些研发觉得自己生来是做 ”产品“的人而怠惰应付。

健康的模式是： 以项目为切入点，验证市场需求和技术可行性。项目成功后，公司有意识地投入资源，让 PM 和团队把项目中的通用需求抽象出来，剥离定制化部分，打磨成一个可以复制给 10 个、100 个客户的标准化“产品”。这是从 0 到 1 的关键一步。
糟糕的现状是： 公司一部分人（如我司的研发总监等）只把项目当成赚钱的工具。他们推崇的“快速交付风”（以交付导向的 KPI ），让团队不得不放弃思考架构的通用性和扩展性——结果就是苦了产品（桥梁）、苦了研发。

更让人哭笑不得的是，在没有正经事做的前提下，他又总想着空中楼阁、要做出一个傲人的产品而羡煞众人。最后把项目做成一个“外包集合体”，还自嘲”自己就是个外包“，永远在交付“一次性”的需求，毫无产品沉淀可言！更有甚者，将这种短视行为美其名曰“敏捷开发的真谛”。

最终，他们面对一堆无法复用的项目，执策而临之，曰："天下无马（产品）！"呜呼！其真无马邪（ yé）？其真不知马也。

对于 C 端：到底是先有产品，还是先有功能？

C 端产品很少有“为单一客户做项目”的机会，它的诞生必须基于高层对市场的洞察和战略决心。

健康的模式是： 高层基于市场分析和公司愿景，确定一个清晰的赛道和目标用户群，并愿意投入资源（人、钱、时间）去试错。PM 在这个战略框架内，通过用户研究、数据分析来定义具体的产品形态，小步快跑，持续验证。
糟糕的现状是： 高层看到竞品做了个功能，或者最近某个概念很火，就让 PM 去“抄一个”、“做一个”。没有战略目标，没有资源承诺，PM 只能带着研发去“碰运气”。最后做出来的东西，只是一个没有灵魂的功能堆砌，用户不买账，老板问“为什么没想清楚”，PM 百口莫辩。

总结一下我的观点：

无论 B 端还是 C 端，“产品”的诞生，源头必然是高层的战略意图和市场的真实需求。

B 端可以从“项目”起步，但必须有升级为“产品”的战略规划和资源投入。
C 端必须从“战略”起步，在清晰的赛道和目标下打磨“产品”。

指望 PM 在没有战略、没有资源、没有市场驱动的情况下凭空创造产品，这本身就是一种管理上的懒惰和责任转嫁。

以上是我的一些观察和吐槽，可能带有个人偏见。想借此地问问大家，听听不同的声音：

在你的公司（可以说明是 B 端/C 端），一个新产品的发起通常是谁在主导？是高层、市场/销售，还是 PM ？
你们经历过“项目”成功产品化，或者“项目”做死沦为外包的案例吗？可以分享一下其中的关键决策或转折点吗？是哪个角色（高层、市场、PM ）起了决定性作用？

Ketteiron

22 小时 2 分钟前

C 端肯定是先有项目才有产品，这个没必要讨论，反过来有 99.999%的概率是赚不到钱的。
产品经理在这里的定位，是要正确理解受众的需求，需求早已存在，不要重新发明，要把它找出来。

在一些以 B 端为主的低水平开发团队中，产品经理被要求凭空变出来一个项目是很常见的事。
他们会被上面的人要求：
"接下来我们要做一个 OA/ERP/MES 系统，功能你看着办吧，先做第一版试看看，不要让开发闲下来"
"把之前项目 A 和 B 合一下，优化一下不合理的地方"
"上次的项目 C 客户反馈有点臃肿了，你看看把没用的砍了，再加点新东西进去"
"最近大屏有点火，你参考一下别人的产品，和设计讨论下先给几个页面看看"
此时下一个客户还未出现，也许还未出生，销售在千里奔袭，实施在客户机房百度 linux 命令，人事在跟过了二面的砍工资，开发在旧屎山上拉新屎，产品经理背负着全公司的希望输入 seed 执行 random() :)

这间接导致了世界上存在很多不合理、怪异、意义不明、反人类、不应存在于这个世界的软件，因为它们逆转了需求->产品的方向，近乎是随机生产出来的。时间和人力成本决定了无法被需求匹配的它们无法返工，幸运的话它们会以相对廉价的价格被倒霉蛋买走，安静地在一些中小工厂、商户、个人的电脑上运行至今。

软件脱胎于产品原型，产品决定了软件能达到的上限，而设计、开发朝着这个上限努力，产品的重要性应该是排第一的。但产品无法凭空变出来，产品经理不是魔法师，就算是普通人眼中无所不能的 LLM ，也需要一段 prompt 。

B 端的痛点是，需求并非平稳连续、可预知的，忙的时候加班到死，闲的时候会有空窗期。
标准且低级的资本主义思想是尽量让所有人员继续运转，即使是在无意义的空转。
于是产品开始施展 random 魔法，设计、销售、前端、后端、甚至运维跟在后面瞎忙活，他们就像凌晨一点刚看完小说的我一样空洞且迷茫。

1. 我司 B/C 都有，通常由 PM 主导，PM 是开发转过去的。
2. 项目基本都是成功的，主要我们这个方向的竞品大多不堪一击，页面和功能看着 10 年没迭代过了。市场难以预知，决策不重要，运气成分占比太高，个人甚至团队的努力与风口相比不值一提。决定性的作用是任何一方都没有拖后腿。

Samuel021

13 小时 12 分钟前

好久没有见到和产品相关的帖子了，产品从业者来聊聊我的观点：

Q1：在你的公司（可以说明是 B 端/C 端），一个新产品的发起通常是谁在主导？是高层、市场/销售，还是 PM ？

历史上经历的公司比较多，一般来说发起新产品的主要来源都是高层（老板，vp ），而源自市场与销售的同事往往会采用给老板施加压力的方式来影响老板决策，下发对应的新功能或新产品的发起。理论上来说过程中始终都会花费公司的资源来完成开发，这些人天成本在进行“新产品”维度的设计开发都需要做投入产出的计算；

但是 B 端产品大体上很难见到 0-1 的过程，大多数时候都是在早期做了一些外包或者小规模实验后，高层领导决定把这部分的业务内容独立出来。但由于对于这个细节的考虑需要花费比较多的时间，老板在面对“自己的决策可能是失败”的现实情况可能缺少勇气，我还真的没见过哪一个项目是公司层面官宣失败的，基本最后都是拖了很久很久，找了一个理由不去继续维护。

产品在这个过程中因为手里的权限和责任天然不对等，很多时候都可能面临屎上雕花的困境，如果是一线的产品人员确实会很容易尴尬，而中高层因为手里都会同时负责一堆项目，因为注意力稀缺就更容易关注自己觉得容易出成绩的项目。

---

Q2：你们经历过“项目”成功产品化，或者“项目”做死沦为外包的案例吗？可以分享一下其中的关键决策或转折点吗？是哪个角色（高层、市场、PM ）起了决定性作用？

大多数时候都是一个 key person 来顶着压力持续投入资源，因为过程里需要有能力确认花费的成本有多少，有能力说服上层领导持续投入资源（比如按照人天的成本是 800 来算，前端后端产品测试的 5 人团队，一天的成本就是 4000 ，一个月仅投入研发的新成本就是 8.7w 了，考虑到这些人如果不能承担已有的老需求和老项目，这个成本乘 2 ，就是 17.4w 了），普通一线的产品研发都没有这样的能力说服领导，所以大多数时候也只有领导可以在其中作为决策的唯一责任人。

但确实那句话“人人都是产品经理”就像是一个诅咒，有太多太多的“名义上”的产品经理其实不具备项目跟踪与关注的能力，又有太多太多“有工作年限但不具备产品能力”的人觉得“产品不难”，不具备产品岗位的尊重能力。考虑到从事互联网 it 的公司的庞大基数，我觉得能遇到烂的公司，烂的团队，也很正常。

大多数公司的现状也都是一两个成功的项目或产品给一堆烂项目产品输血，很正常。

raydied

12 小时 38 分钟前

@sillydaddy #4
感谢你的回复，你提出的几个问题非常到位，确实是我原文中没有展开讲清楚的地方，我详细说明一下。

**1. 关于“快速交付”与“抽取通用需求”的矛盾**
你问：“研发以敏捷开发的方式，快速交付，不正是你所希望的‘快速验证市场需求’吗？”
这是一个非常好的问题。我原文中批判的，并非敏捷开发所倡导的“快速交付价值”，而是一种**以牺牲长期价值为代价的“短期交付速度”**。

我理解的快速交付，不应是以牺牲代码的质量、团队其他成员的时间、客户的需求、项目的未来成长空间为前提。我举个例子：就拿 ASR （语音识别）相关的项目。我们现状是：

- **技术上**：直接复制粘贴一套旧的、曾经能跑的代码，几乎不考虑因地制宜（不考虑不同用户端之间的区别），更不要说自己测试一下才提交，代码能跑起来就敢提交测试（期待发现问题之后再擦屁股，丝毫不想着提前请教团队大佬）——忘记了这里没有银弹，努力为埋下巨大的技术债添砖加瓦。

- **流程上**：这种交付方式把所有压力都转移给了产品和测试。PM 需要花大量时间为这种“技术捷径”导致的体验问题向客户解释，测试则在无穷无尽的回归测试中挣扎。

一句话说，按部就班地增加“屎山代码”，这应该谁来负责、谁来监督，全靠产品、测试？就如应付你的理发师一样，剪了就完事，不沟通、不用心。

---

**2. 关于“抽取通用需求”的责任归属：是 PM 还是研发总监？**

毫无疑问，定义需求、规划产品路径，毫无疑问是 PM 的核心职责。但抽取通用需求更是要建立领导的高瞻远瞩、优秀的项目交付、和若干相似的项目之上才能进行。

**公司高层没有为“从项目到产品”这条路设置正确的导航和激励**，压根走不到“抽取出产品的通用需求”这一步。
我认为，优秀的项目交付就如同好吃的料理一样，能赢来回头客——难道只靠金字招牌（老板的关系），一个饭馆就能成就百年口碑、做长久生意？
但在我司的现实情况中，问题出在**战略缺位和组织目标错位**上。

- 第一，公司战略层面身体上不认可“项目产品化”。他们将项目视为一次性的“现金牛”，哪怕给客户多修一个隐藏 bug 都觉得亏了。

- 第二，我没有把抽取出产品的通用需求，看作是研发经理的锅。而是指责不用心交付项目（以伺候客户为耻）的现象。我司是研发总监平时叫得欢（好大喜功、多快好省、空中楼阁、好高骛远），一到夜里支持项目就尿遁。

- 第三，如果 KPI 是“项目交付速度和成本”，而不是“产品化贡献”或“技术资产沉淀”。在这种激励下，研发自然会选择最“省事”的方式——复制粘贴、快速结项。

总之，在我司没有严格的 KPI 的情况下，这种现象还出现，我觉得很诡异。

Ketteiron

11 小时 14 分钟前

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

lswlray

11 小时 3 分钟前

我嘞个天！
如果你是产品经理，遇到这种情况，你难道不应该是笑疯吗？？？？？？

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

所以，如果你是一个有追求的产品经理，遇到这种别人交学费、自己赚经验、万一成了有巨大回报、失败了影响不大的事儿，不正是锻炼自己能力的好机会吗？
当然，如果你就是一个循规蹈矩、按部就班、喜欢稳定的人，那可能确实是灾难。

raydied

8 小时 29 分钟前

@lswlray #14 前提是有钱给你造啊。

举个例子，原本我们在按部就班迭代一套面向香港市场智慧工地场景的 saas 软件。后来，因为智慧工地没有新客户签单了，研发经理提议讲迭代计划就停止了，领导同意了——似乎只有我发表意见，大家都不 care 船往哪里开。目前就靠存量客户的需求为驱动——实在没办法了，屁股才往前挪一挪。
当初 0-1 的热情全都抛在脑后——也怪不得研发经理，他不在这个产品的迭代计划中。

为啥卡了，领导说要转型，要做 ai 大模型的相关项目。研发被调走后，一顿输出，不了了之。最后，两边全停摆了。现在的状态是团队以做大模型相关的 demo 自娱自乐——自己捏造或市场看一个需求，完成一个 demo 。

好容易有个大模型相关的项目——旧客服系统升级为智能客服，也不认真做；会的都做不精。对提出的一些迭代方向（诸如自动化解析文档内容、rag 的质量评估等等），这些极其重要的基础能力，也不想研究和优化。原因是这个项目就给了这么点儿钱，不能浪费时间在这上面。

问题都已经暴露了，研发经理也不去审核审核代码，整天问项目怎么还没结束？好像发现一个 bug 是现在最大的错误。