如果产品经理不懂技术会发生什么事情？

被推荐中 @金泰宇 的回答XX到了，必须在这个问题下正视听。我不知道他那些粉丝和专业徽章哪儿来的，但是那个回答实在是过于“从基层视角定义行业岗位从而可能会误导他人”【根据知乎建议修改不友善内容，表述不太精确】，居然排名第一。

要我说，想当一个合格的、能落地、有产出的产品经理，你就必须得：开会时能说得明白业务路径，写文档时拎得清技术实现，画原型时交互逻辑表达清晰，追进度时知道谈判策略与优先级取舍。哪块不行，哪块就是你职业路径上的短板。没的说，想当产品就得上全套。 硬说其中某块不重要的，我默认你人在大厂，有人补位，不事生产，所以主升逼逼和PPT天赋去了。这么多年一线产品经历，我的体会是，产品cover不到全局，最后的交付必然会有问题。

这四件事情是很低端的需求分析师才要做的事情，如果产品经理有段位，这也就是新手村的要求。而这位答主对产品经理胜任力的描述，是看起来样样精通，实际上样样稀松。

强调自己懂技术的产品经理，一般都是因为技术出身，吃到了跟技术沟通的红利，于是就把自己当成了这个岗位的榜样，自己畸形的能力模型也就想当然以为是这个岗位的天花板。

我虽然是技术出身，写代码4年，做了11年的技术管理，做了4年的产品，但是我和 @马力在知群 的态度一样，有同样的一份时间，我希望产品经理放在学习业务上，而不是学习技术。

原因很简单，产品经理面对的是从行业到技术，大概七八个层次的知识，技术只是其中很小的一个领域，有更专业的人负责，不需要产品经理过多关注。但是能够在行业高度进行抽象的能力是产品经理这个岗位相对独特的能力，其他人不好弥补。一个公司在这方面薄弱，所有人都会比较难受。

最顶层，是战略层，考虑的是企业竞争力选择、规划和实现。

产品经理首先要解决的，是：

在这样的赛道里，行业如此的竞争态势下，企业的核心竞争力在产品上到底如何体现的问题。

这是最高层次，“竞争力的选择”、“企业级产品定位”，也是竞争战略。

其次，产品经理要说清楚：

在产品规划上，到底哪些特性是行业抽象，哪些是企业抽象，哪些是岗位抽象，哪些是个体抽象。

这是“行业抽象”，第一个最重要，其他的都次要。这是“竞争力的规划”。

再次，产品经理要说清楚：

这些抽象应当以何种模式塑造产品的核心竞争力，如何帮助客户达成其目标，如何在竞争对手面前取得优势，如何让投资人对产品的未来充满信心。

这是“竞争力的实现”。

这三个东西是产品经理的高端能力，由于绝大多数产品经理并不具备，所以很多时候是由行业中的业务专家来做的。

请问这里哪个是技术能力？懂技术到底能帮助你得到什么？

下一个层次的产品经理，应该对客户有很强的感知。

产品经理应当说清楚，自己产品的价值主张是什么，对于客户来说到底有什么价值。

产品经理应当说清楚，促使客户选择产品的关键逻辑是什么，客户的各个角色收益如何。

产品经理应当说清楚，客户对产品的完整使用场景是什么，产品在哪些方面帮助客户达成了什么目标。

产品经理应当说清楚，哪些链条是产品无法覆盖，但是客户必须的，应当由人力来补充。

产品经理应当说清楚，这些人力应当达到何种标准、如何组织才能配合产品满足客户要求，产品应如何为这些人力赋能。

这是业务层产品经理应当进行的规划。由于能够做到的产品经理太少了，这部分一般都是由公司的行业专家、业务专家一起设计。

然后是产品层。

产品经理应当说清楚，产品的总体规划如何，如何建设产品平台，如何划分子产品，分别对应何种客户场景。

产品经理应当说清楚，各个产品应当如何划分模块以支持用户场景，产品各个模块主责如何，如何协作。

这是产品规划，大多数产品经理也做不好，一般也是由高管团队辅助产品经理做。

再往下，是具体的功能设计，也就是这里描述的工作内容：

开会时能说得明白业务路径，写文档时拎得清技术实现，画原型时交互逻辑表达清晰，追进度时知道谈判策略与优先级取舍

所以我说，这里说的就是新手村的内容。懂技术也就是在写文档和技术沟通的时候用得上，大概率，也就是类似：“这么个功能半天就干完了，为啥要两天”这种破事儿上撕逼。

而我上面写的东西，大概是这位仁兄嘴里“主升逼逼和PPT天赋”。他自己也说，“产品cover不到全局，最后的交付必然会有问题”。然而因为自己太基层，所以他眼里的全局里，技术居然是很大一块。

我自己作为公司高管，面对这样的产品经理，只能凑合用，天天骂是必然的。你可以只有这样的能力，但是你认为有这些能力就够了，那是眼界问题。

人的精力是有限的，不可能样样精通。“做一个既懂业务又懂技术的产品不香吗”，当然不香，你往上看看，有那么多事情要学习，你觉得你全照顾得过来？你在开什么玩笑。

当你就看到一篮子鸡蛋的时候，你肯定想都背上；你看到一集装箱，你就要做取舍。这是眼界问题。

我自己做了4年产品，自我评估的话，我认为我在战略层能够作为主力参与，在业务层能够负责领导和规划，在产品层能够指导，在功能层次就只能把把关了。

我的能力领域在宏观，不在微观，这些内容交给小朋友们会做得更好。但是小朋友要成长，往下兼容技术，价值不大，向上的价值和空间都更大。

归根结底，在我眼里，产品经理是对产品的最终负责人，作为一个产品经理，你应当是产品的大脑，而不是别人要什么你设计什么。

这也是为什么产品经理叫小CEO，而CEO自己永远是最终的那个产品经理。

【这里根据知乎建议，删除了不友善的内容，所以表述不再那么精确，大家意会吧】

@金泰宇 更新了自己的回答，挺好的【对！】，他说的每句话都在表达他的格局。

比如我说产品经理在业务层要感知客户，但是产品经理在这方面做不好，需要行业专家、业务专家辅助，你的反应是“要你何用”。

作为一个低级产品经理，你的反应很正常，公司的组织结构设计根本就没有给你这个职责，你本人的能力、意识也达不到突破这个岗位天花板的能力，自然你会觉得很委屈。

【一个委屈而愤怒的小基层】

但是假如你是一个行业专家转行做产品经理，他能说清楚这个，他不仅仅能设计产品，并且还能设计产品无法覆盖的地方，应当如何用业务人员补齐，那么他是不会有这个委屈的。

【摸着你的头安慰你的大哥】

你是一个被设计在这个岗位上的人，你不做不代表你不该做，而是因为你没能力做，也是因为公司不需要你做。但是你不要觉得行业里的产品经理就都不该做这个，尤其是ToB行业的产品经理，是要长在客户的KPI上，不仅要设计自己的业务，也要梳理客户的业务。

【至于这位的被迫害妄想之类，算了不评价了】

基本上能够在产品经理这个岗位上做到资深的，是断然不会瞧得起技术这点东西的。我做了这么多年技术，从前到后，从内部系统到SaaS平台，从金融系统到数据系统，啥技术没摸过。但是做产品经理的时候，我反而谨言慎行，不被询问，我是不会给出技术建议的。

因为你要尊重对方的专业性，不仅仅是不要不懂装懂，更要知道难得糊涂。

基层最大的问题是能力不足，信心不足，所以特别喜欢显摆能力，最害怕不被人认同。

这位基层产品经理的状态就是这样啦。

有一分显摆十分的是儿童，有一分说一分的是少年，有十分说一分的，欢迎来到成年人的世界。

不多说了。

另外，评论区有些小朋友说，这能力要求也太高了，这不是CEO吗，这不是CPO吗，这不是上帝吗？还有个小朋友说，这不得800万年薪，哈哈哈。

如果你自己开公司弄个一两百人管着，你就不会这么想了。如果你真的去招一个CPO来，你会发现你既不用给他800万年薪，我提到的东西他也大概率都会考虑到。

所谓术业有专攻，你真的是CEO，你没那么多时间思考这些具体的内容，顶多在战略层把关。你还要面对经营压力，你的销售团队还在天天哭喊，你还要面对下一轮融资，你的大客户们还需要你去跑，你的这些高层中层还需要你来管理。

一层有一层的风景，如果有兴趣，我找个机会开个回答，给大家介绍一下高一点的风景。眼界打开了，你自然知道自己该往哪个方向努力，不要十年后回头想起来后悔，早知道年轻时多学点这个就好了之类。

3.10更新了第4件事，我忽然有种预感：这会是一个要用一辈子更新的答案。。。

==============================================

说三个真实故事：

1. 一键同步用户本地的资料

一个工作3年的产品提了一个一句话需求：把用户在客户端的资料一键进行上传下载的同步，多客户端都可以不联网进行修改，等有网了再同步。

我问产品，如果两个客户端上的修改有冲突了，怎么处理和展示？这确实是我们平时在使用 git 或者云笔记的时候经常遇到的问题。产品对我说，这是技术问题，他不懂。。。

好吧，我忍了，一起讨论吧。

我们拉会讨论了一下可能遇到的所有情况，最后评估实现这个功能需要用 5pd 的时间。产品当场吐槽“我就设计了一个按钮，你们居然要用那么久的时间”。

我忍不住举起了折椅。。。

2. 人与人之间差距怎么那么大

一个产品跟我和程序员 A 提了需求，都是增加两三个字段展示的需求。

区别在于： A 同学的字段是他数据库里面都有的，直接在 select 语句中多加几个字段就可以，再加上前端的调整 1 天就上线了。

而我的几个字段是来自外部团队的，需要协调人家帮我们开发接口和联调，我这边再启动心跳去抓数据和更新，还要爬取实时汇率进行计算，所以足足3天后才上线。

晚饭时候我偶然路过产品工位，无意间听到他跟同事吐槽：同样加两个字段，有些人1天就能上，有些人自己不会弄还得让其他部门帮着弄3天才做完，人与人之间差距怎么那么大。

我实在忍不住，拉群开喷。。。

3. 我们为什么不自己做个地图呢

我们讨论需求的时候，说有的地图本地化不好，有的地图收费太高，需要领导做个权衡。

这时，有个PM妹纸说：我们要是自己做一个地图不就本地化也好了，也不用付费了吗？需要多长时间技术能评估下吗？

当时没有一个人理她。。。

其实产品经理不懂技术本身没有太大问题，只要做到两点：

1. 不懂技术就不要评估技术的难度，或者给技术什么指导，技术的问题听程序员的就好。这句话对程序员同样适用；
2. 有些问题程序员认为是业务问题，产品经理却认为是技术问题。各向前努力一步就好，都多了解学习下，一起商讨怎么解决问题；

===============================

更新：

4. 被安排得明明白白

就刚刚的事，一群产品经理开了个会，讨论得热火朝天，技术没有参加。

回头发我会议纪要，我点开之后都震惊了：我的工作被一项一项安排得明明白白，甚至精确到要开发哪个接口。

被安排也就罢了，还有个需求是让我提供个接口，修改她系统里面的数据——这臣妾实在做不到啊！

我就找 PM 说，这个接口不应该是我提供，应该是你的系统提供接口，我来调用；她说，谁做都可以吧，就看工作量排期了。

姐啊，我要是有这能力直接提供个修改银行系统的接口多好啊，还用得着成天上班跟你在这 BBBB 么？

推荐我的这篇文章：

其中提到的一个案例，我方合伙人实际上是懂计算机技术的，但不懂客户工厂的生产管理技术。

其结果，就是他之前往客户公司跑了十几趟，耗费了好几个月，但项目还是陷入泥潭，没有半点进展。

我这人好奇心重，什么都想知道，也什么都知道一点——熟悉我的都知道，混各大论坛写科普文还是有点三脚猫功底的。

客户工厂我也是第一次进，他们的机器我也是第一次见。

但基于对机械原理、操控界面设计思路的熟悉，我几乎是听到机器的名字、看到它的面板的第一瞬间，就明白了这种机器是拿来做什么的、有多少功能多少工序、该如何操作、工人会如何在它面前忙碌……

甚至于，基于修理缝纫机摩托车以及各种家电的经验，我甚至能猜出这些机器大概的工作原理是什么、有哪些活动件、可能会出什么故障——然后，问题自然就来了：“这些机器可能会出现哪些故障？不同故障如何报修？比如断线这种故障肯定工人自己解决；但复杂一些的故障呢？”

这些，都是软件设计时，必须事先做好准备的东西。

一圈走下来，我学会了操作机器；再加上我本身对于管理学略有了解，不是完全的外行：看完机器，他们的工序/流水线配置，他们从上到下大部分人的日常工作，我就猜中七八成了。

其结果，就是一周后第二次去，也是第一次见到客户方总负责人，我就在一次会议上用一个多小时时间，彻底把需求了解了个通透。

知道了客户要做什么，结合我的计算机专业水准，我立刻就知道程序应该怎样写、该怎样配合客户方上至领导下至车间工人，知道该给他们设计一个怎样的概念。

于是，我在会议上当场给出方案，向客户方提出了一系列流程上的疑难点，谈妥了哪里需要折衷、折衷方案如何；哪里需要改变他们旧有的管理思路，如何改变；哪里又需要在软件上做好准备——比如，某些功能可能涉及工人的绩效，这些功能就可能被人钻空子甚至破坏性使用。这些自然就要从一开始就做好预防措施。

两个周末的下午，去了一趟车间，开了一个会议，项目成功了。

软件做出来后，客户掏钱掏的特别痛快。当年合伙人就买了辆宝马SUV。

很显然：

1、如果产品经理不懂机械、搞不懂客户的日常工作是什么，那么他就不可能做出满足客户需求的设计。

2、如果产品经理不懂管理，那他就不会知道软件的某些功能的利益相关方都有哪些、都可能遭遇到哪些钻空子甚至对抗性、破坏性使用的场景，就不可能事先做出设计——结果，被用户破坏性使用弄出问题，黑锅就得你公司背。

3、如果产品经理不懂软件技术，那他就不知道哪些功能可以实现、如何实现；极端情况下，就可能搞出“根据手机壳颜色更改桌面主题”这种飞机。这对客户、对公司、对开发团队，都是一个沉重的打击。

当然，这些都可以通过种种措施加以弥补。

比如，知道自己不懂机械，找个懂机械的工程师随行，随时听取建议；知道自己不懂管理，找个管过人的随行，多开碰头会；知道自己不懂软件开发技术，找个好一些的程序员随行，发言前听听行家建议……

当然，如此一来，效率就会有些低。因为你们四个的沟通就需要不少时间，沟通完了再和客户沟通，客户说一句话，你们四个又要讨论半天——懂机械懂管理的想尽办法把你和程序员科普到位，让你们懂；然后你和程序员再基于自己的知识讨论一番，达成共识；然后再把共识传达给机械专家和管理专家，请他们帮忙确认这个共识是否正确……

总之，花费九牛二虎之力达成共识之后，你再和客户方沟通，想办法科普给他，听他回话后，你们四个继续开会、继续想办法理解客户的意思、达成共识，然后继续沟通客户……

你看，旷日持久。

还不仅仅是旷日持久。

这个过程中，因为彼此都对对方领域陌生，因此你们一定会闹出无数的误解。

这些误解有些可能会被行家敏锐的发现、尽快解决掉；但还有很多误解会漏过去、扎下根，变成棘手的bug，甚至导致项目失败。

因此，我方合伙人虽然软件开发比较内行，但就是不能正确理解客户意图，几个月了，一直在低水平问题里面打转转……

而我呢，虽然机械、管理都是业余水平，但起码准确理解相关话题不成问题。

一个人，同时理解了问题涉及的所有相关领域，那么自然就不需要反复咨询、确认、消除误解；于是议题在对方领导出口的瞬间，我这边就完成了分析、消化工作。

不仅如此，基于软件设计方面的专业水准，一旦我完成了客户需求的分析、消化工作，那么脑海里甚至已经浮现出了详尽准确的模块设计/接口设计方案。

我会马上在脑海中“跑一跑”软件逻辑，并把这个软件交给客户方工人、中层领导、高层领导后，他们的工作流程想一想，看看有没有疏漏、看看人机交互是否别扭、看看被软件定死的流程是否会妨碍客户工作中罕见的突发情况的解决……

一旦我的“脑中虚拟工厂”在“软件上线”后出现了问题，我就会马上找客户方确认：“如果软件这样写的话，遇到某某情况你们怎么办？是软件方面不要考虑，你们自己开特例呢；还是要改一改我们的设计？啊，我已经有了三个方案，分别是如此如此和如此。其中第一个方案可能带来什么问题、第二个方案会钻什么牛角尖……第三个方案个人觉得最完美，但我毕竟不熟悉你们的工作管理流程，而这个方案擅自修改了某某流程……”

大多数情况下，客户方会同意第三个方案：“信息化肯定是要优化和改变旧有流程的。”

也可能是：“啊……不要改，因为这个涉及另一个问题。我们过去是这样处理的……”

甚至，做另一个项目时，我还遇到个心直口快的：“高！这事困扰我们好些年了，大家都这么凑活过的。没想到你一下子就找到了解决方案……”

你看，在我面前，需求是不是一下子被挖的特别深、特别透？

如果不懂技术，可能一下子就挖到这种程度吗？

——我经常说自己“一年只出1个bug”“2000行代码的小程序，经常敲出来就是0 bug”：原因很简单，无论是我自己做需求还是从别人那里领任务，我都能三言两语把一切细枝末节弄明白。

——注意“三言两语”和“把一切细枝末节都弄明白”并不矛盾。

你能问到点上，这三言两语就是牛顿三定律，剩下一切的一切都可以轻易推理出来；反过来说也对：当你脑子里有一百个一千个问号时，不要逐一拿出来问别人。

相反，你要先问自己：这个东西究竟是怎么一回事啊？它要解决什么问题？为什么要这么扭来扭去的解决？哦，直线行不通啊……好了，一百多个问题消失了。让我再考察一次……啊啊，人性啊……那么另外三十个问题就有着落了……

你看，当你事先整理好思路、试图从总体上把握问题时，绝大多数问题都不需要问了——那是你过去十几年求学经验的积淀，别人可没耐心也没能力帮你补上中小学的课。

类似的，我经常提到，部门会议上，有些同事就显得特别机灵，经常我绞尽脑汁想出来的“绝妙设计”，才提了一个关键字人家就明白了：“啊，这个思路不错。不过XX问题你是怎么解决的？”

并不是他事先也想过类似问题。就好像我看到“合象式测距仪”这“合像式”这三个字，立马就把这个设备的里里外外想了个通透一样：我知道测距的原理，也知道测距的难点/麻烦之处；而“合像”二字马上就让我想到了几何光路、想到了几何学关于角度相等的那些证明思路（也是设计思路）；再加上基线长度已知，再配上熟悉的机械转动-刻度盘……那么这件设备应该是什么样子，还需要费劲巴拉的科普吗？

你看，内行之间，两三个字就足以传递从几何学、近代物理、材料学再到它们的灵活运用这样需要写成几本甚至十几本书、刻苦研读很多年才能弄明白的知识——以及它们的天才组合。

类似的，熟悉飞机的工程师哪怕远远看一眼先进战机的剪影、或者瞥一眼进气道的轮廓，他马上就能给出一些靠谱的判断、甚至受其启发攻克技术难题……

这就是所谓的“技术积淀”。

如果没有这个积淀，很多对内行来说非常简单的问题，你可能努力十年才能理解；没有这个积淀，别人看来直截了当的解决思路，在你看来只是“玄学”：

综上。如果产品经理不懂技术：

1、如果产品经理有自知之明，那么他每次开会需要带好几个不同方面的专家、会导致需求调研阶段占用更多时间；当团队沟通不畅时，需求常常难以做的更深更透，甚至隐藏错误、给公司带来损失。

2、如果产品经理没有自知之明，那么他可能就会：“我只管提要求，你给我实现。（识别手机壳颜色改主题这件事）上级已经批了，你不干有的是人干！”

相反，如果他比较懂技术——包括软硬件领域的技术和客户领域的技术——那么自然的，需求调研效率高、挖的深、挖的透，可以一下子做到让客户满意。

————2021.10.30更新————
一直觉得在知乎有分歧不可怕，讲道理摆事实就好。但实在看不上 @上官人 这种上来就骑脸的。但要真能给干货，我也认。可看完一遍，发现水得不行，框架一套一套，看细节都是漏洞，真是啥也不懂，就把吵架当流量密码了？？

还有，马力你暗搓搓改什么答案，你倒是坚持自己的“产品经理不需要懂技术”的立场啊。改回答+找人骑脸+抱团点反对，啧啧。偷摸改prd的天赋点的挺溜。

我就奇怪了：

• 我说互联网产品经理要懂点技术怎么了？
• 互联网算不算科技产业？
• 产品经理是不是互联网公司的核心岗位？？
• 那科技公司里的核心岗位为什么不懂技术却理所当然？？？
• 连写科幻小说的都要懂点技术，为什么在你眼里产品经理懂技术就这么违和？？？

懒得逐条反驳了，简单呵呵一下吧：

1. 看到“需求分析师”，我就笑了，感兴趣的可以搜一下，看看哪些公司单独开放这种职位，反正我是不招的。
2. 看到“战略层”，我又笑了。洗稿也用点新知识吧，“用户体验五要素”这种过时的框架，还是少用吧。但既然你说到顶层设计了，我就问一句，做一个互联网公司的竞争战略分析，你当真不考虑技术？？
3. 看到“一般由公司的行业专家、业务专家一起设计”我无语了。麻烦别人做业务访谈、行业调研就算了，还要别人出产品方案，最后KPI还算你的，这还要你何用啊，要你何用！
4. 看到“高管团队辅助产品经理做”，我笑疯了。哈哈哈哈哈哈哈哈哈哈哈。真当产品经理是CEO啊，还高管，还团队，还辅助？？？现在营销号都这样吹牛不打草稿吗？
5. 另外，我回答里说的“产品经理落地时要做到四件事”只是及格线，不知道怎么会被你理解为上限。只要真的从0到1做过项目的，都不会觉得有问题吧。业务思考在PDCA的P里，是费时费心的前置工作，但到落地环节，关注点就需要变化
6. 最后，“产品经理是对产品的最终负责人”这句我是赞同的，但要补一句：但不要做个眼高手低的负责人。
7. 题外：一定要小心把这两句挂嘴边的人：“人人都是产品经理”，“产品经理是未来的CEO”。不解释，懂得都懂。

最后，那个奇葩答案防删截图存最后了，感兴趣可以围观

————以下原回答————

马力的那个高赞答案看得我是一脸懵逼。懂业务和懂技术并不矛盾吧。

懂业务是看得准，让需求落地不跑偏。懂技术则是摸得清，让需求落地路径更清晰。这是互补的事情，非要一拉一踩，我就看不懂了。

只想懂业务，你咋不去做运营？并不是在diss运营同学啊。运营是顶在一线打仗的，懂业务、知市场就行了，懂技术带来的帮助并不大，但产品不一样。

要我说，想当一个合格的、能落地、有产出的产品经理，你就必须得：开会时能说得明白业务路径，写文档时拎得清技术实现，画原型时交互逻辑表达清晰，追进度时知道谈判策略与优先级取舍。哪块不行，哪块就是你职业路径上的短板。没的说，想当产品就得上全套。

硬说其中某块不重要的，我默认你人在大厂，有人补位，不事生产，所以主升逼逼和PPT天赋去了。这么多年一线产品经历，我的体会是，产品cover不到全局，最后的交付必然会有问题。

所以，请不要没有CEO的命，却犯了CEO的病。整天战略、规划、路径、业务、打法、策略… 身为产品经理的你得先知道能不能做得出来。你得最快速度地推着项目去迭代、优化、演进；而不是在需求丰满与实现骨感的落差中反复摇摆。假设你真懂业务，那懂技术就是你的剑，帮你及公司砍掉那些技术试错与无效口舌的时间。时间就是生命。所以，懂业务和懂技术两者都很重要、不矛盾，真的。

说产品经理要懂技术，并不是要求你能review代码、上手能写。知晓程序的触发判定逻辑，算法的运行规则，前后端的数据交互方式，数据的落库，就差不多了。涉及三方服务的，对方提供的SDK文档能看得明白，就可以了。并没有多难。

这样的你，在面对老板和运营时，知道对哪些想法进行讨论才是有效且能落地；在面对开发时，明白如何描述需求才能避免歧义，达成实质的共识。这不挺好的吗。

做一个既懂业务又懂技术的产品不香吗，总比自诩业务精通却天天和老板吹牛，跟开发吵架，对运营甩锅的要强吧。

————最后是上官人的原回答截图留档，没啥营养————