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

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文档能看得明白，就可以了。并没有多难。

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

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

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