编辑导语：众所周知，产品经理是一个综合能力要求很强的岗位，需要了解很多方面的知识。那在技术方面呢？产品经理要不要懂技术的底层逻辑？本文就此问题，从六个方面来展开论述，逻辑清晰。推荐对产品经理感兴趣的盆友来阅读。

有产品的同学问我，他的领导让他懂一点技术以方便工作，但领导说的不明确，自己又不好意思继续追问，因此现在很困惑，问我作为产品经理要懂技术吗？

要回答这个问题，我们要把它拆开来回答，它包含了以下6个方面：

遇到哪些问题懂技术的目的懂到什么程度要懂哪些内容如何有效学习懂技术的好处

一、常见问题

案例一：

案例二：

开发：这个功能至少要开发2周。产品：啊，这么简单的功能要这么久啊？等上线了热度都过了。开发：是的…因为…算了，跟你说也不明白。产品：……

在日常工作中，产品经理可能有以下类似的烦恼：

提出的需求被开发觉得异想天开，需求被拒，经常返工；觉得开发评估时间过长，自己很无力；需求评审会被开发批的体无完肤、一无是处；听不懂开发说的内容，开会时云里雾里，安排任务效率低；不知道技术的优劣，做决策拖后腿；出了问题不知道找谁，开发相互推诿，用户的问题无法得到快速解决；对项目进度无法掌控，版本经常延期；上线跟打战一样，问题还特别多；开发的领导好难打交道，感觉很凶；……

网上讨论最多的就是案例中所描述两个的场景，很多人为之苦恼，感觉自己经常被开发忽悠，事情推进不了就算了，开发说的话还阴阳怪气，说话夹杂着嫌弃，眼神充满了鄙夷，非常的没面子。

二、找到问题本质

很多人认为之所以出现上面的情况，就是因为自己不懂技术，当产品经理懂技术之后，开发也就无法再忽悠，没有了鄙视和嫌弃，以上问题也能迎刃而解；即便没有解决，自己的技能树上又多了一个技能，总比只懂产品要强。

这种想法对吗？不一定。

这种想法实际上是在用战术上的勤奋来掩饰战略上的懒惰，开发是一个很看重实战的岗位，我们利用业余时间学习的一些皮毛，就想和在实战中厮杀多年的开发掰手腕，那就把开发岗位看太轻了，在他们眼里，我们和刚入行的开发没区别。

退一步说，哪怕你天赋不错，学到了一些技术，开发想忽悠你还是一样，因为你不了解实际的代码情况。

即使同样能力的开发，面对陌生的项目、不熟悉的框架和代码，在做评估的时候，都会选择保守，你也不能代替他们去开发，这种情况尤其以跨部门沟通时更加明显，因为你根本指挥不了他们。

开发说“做不了”，你说“可以做”，开发说“你来？”。

开发说“这个功能最少要3天”；你说“少唬我，我可是练过的，最多1天半就够了”；开发说“我就要3天”，接下来你有两个选择：

当场揭穿他，可能会上演全武行；向他领导告状，领导可能和颜悦色的告诉你，要相信专业的；也许领导这次帮你解决了，下次呢？

因此，懂技术不一定能解决“做不做“和“忽悠”的问题，或者说要解决以上的两个问题和懂技术不能划等号，那可以给以后找工作加分吗？

绝大多数情况不行，除非你在一个项目里即是产品，又是开发，而且项目完整跟完并上线运营，并且这个项目和这家公司类似（需要运气），这样的懂技术才可能成为加分项，否则很难。

因为我们面试的不是技术岗位，级别越高价值也越低；产研负责人岗可能有价值，但这时就不是加分项，而是必要条件。

有人不服气说，怎么就不是加分项，懂技术可以很好的和开发沟通，是的，可能，但这里的重点是沟通能力，技术只是其中的一小部分，也不能划等号，你是不是听过很多程序员都不擅长沟通的例子。

当然，以上的分析不是说懂技术没有价值，而是不希望将懂技术当成唯一的阻碍，产品做不好是因为开发不配合，开发不配合是因为我不懂技术，我很苦恼，我没有办法。

将问题推给环境，推给外在因素，没有思考对问题的本质，但是，产品经理恰恰是需要去思考问题本质的岗位。

懂技术可以辅助你把工作做的更好，但不懂也不是阻碍你推进产品进度的关键因素，绝大多数人面临推进难的问题，究其本质，在我看来就三块：

1. 甲方的优越感

说出来你可能不信，开发在公司里面其实是弱势群体，作为最下游的执行方，很多时候是很被动没有话语权的，甚至经常要背黑锅。

而产品经理作为甲方，习惯把开发当成纯执行者，听话就好别瞎BB。

优越感带来的第一个问题，是无法接受对方提出的修改意见和建议，觉得在挑战自己的专业，你一个开发懂什么？（这句话开发也经常对产品说，你啥也不懂），有时实在无法说服对方，就耍赖说“我不管，我就要，实现不了是你的能力问题，怎么实现是你们的事”。

优越感带来的第二个问题，是在需求被拒时挫败感很强，内心觉得被开发鄙视了，其实真的想多了，开发一般都比较单纯，不会因为某个人不懂技术而看不起他，绝大多数问题是因为某个人的态度导致。

所以解决问题第一步，端正态度，实现和开发平等对话，不是甲方乙方的关系，而是战友关系，将双方拉到统一战线。

2. 能力的不自知

需求来自来自用户的诉求、老板的想法，产品经理很容易成为传声筒，没有去思考逻辑和细节是否合理，绝大多数开发与产品间的争吵，都是因为产品需求逻辑的问题。

在需求评审会中，面对开发的疑问，无法在逻辑上讲通，产品经理很委屈，觉得这不是自己的错，明明是用户的需求，老板都答应了，开发怎么还这样呢？这不是刁难人吗？

面对开发的不配合，没有去思考自己的问题，而是怀疑开发在针对自己，给自己的错误找很多借口。

人与人之间的合作，不会因为对方不懂己方的专业而嘲笑，而是因为对方不自知、不虚心、不学习，才会让人看不起。

学会调整自己的心态，认识自己的不足和知识盲点，不明白的地方虚心请教，承认自己不足有时比去学习一项新技能更难，主动避险是人的天性，我们习惯为问题找外部原因，而忽略了对自己内心的建设。

3. 和研发之间的信任缺失

我们习惯用“怼”和“甩锅”来构建产品和开发之间的爱恨情仇，从内心就已经将产品和开发摆在了对立面，在双方划了一条信任鸿沟，需求评审会就变成了博弈游戏，认为对方是欺负自己不懂（当然也有可能是真的，但不常见）。

你觉得开发在偷奸耍滑，开发效率这么低，每天不知道在做什么，开发觉得你在异想天开，啥也不懂，脑子瓦特了。

懂技术似乎是一个构建信任关系的桥梁，但其实重点是如何和开发建立信任关系，而不是一定要去学习技术，其他方法可以尝试，如共同兴趣爱好，日常的交流关怀，都是不错的方法。

在自己领域足够强也能增加信任度，需求够专业，逻辑性够强，思考有深度，上线有结果等等，人性是对强者会有天然的崇拜感，做出成绩就是最好的信任背书，开发也不会因为你不懂技术而轻视你，因为相信你肯定能做好。

因此，合作的基础是信任你同部门的队友，双方不是你死我活的拉锯战，而是为了实现共同目标的攻坚战，通过统一目标也可以成为自己人，信任每个人在自己擅长的领域能做出最好的判断。

如果你做不到对每个人的信任，那可以招一个你信任的资深开发，让他来帮助你做判断也是一个有效的方法，没有了信任，你再懂技术也没有用。

倘若是跨部门，在对方的阵营中找到一个可信任的战友是有必要的，这个战友最好是团队中比较资深的那种，亦或者是有想法、责任感比较高，可以帮助你解决很多问题，时不时的请教，也能让你做事情事半功倍。

排除了以上三点问题，先认清自己，认清环境，找到关键因素，看看懂技术是不是真的是你遇到问题的解法。

三、懂技术的正确姿势1. 懂技术的目的

要不要懂技术，先要想清楚自己的目的，以终为始才能做到有的放矢，不同的目的，所需要学习的内容和程度会有所区别，但不管是什么目的，有一点可以肯定的是：

绝对不是去代替开发写代码！除非你是纯粹个人兴趣，除非你是创业者要控制成本，否则，千万不要本末倒置，将自己陷入开发的自嗨中不能自拔。

甚至有些人还说要懂技术架构、懂计算机底层，这是要飞天吗？

一个开发经过多年的打拼，多个项目线上实操，没日没夜的解决各种性能瓶颈，才能成为一个合格的架构师，才敢说自己懂技术架构。

一个工作5年以上的老码农，如果没看过一些技术的源码，只敢谦虚的说自己知道原理和怎么用，底层如何实现还需要研究。

咱就看了几个名词解释，安装了环境输出了Hello World，开发了一些简单的增删改查就大言不惭的说我懂技术架构，懂技术底层，只能是班门弄斧。

技术是一个需要持续学习的领域，每隔几个月就会有新的技术诞生，永远也学不完。

只有清楚自己的目的，才能清楚学习边界，才能在有限的时间内快速掌握所需要的知识，并在实际工作中使用产生价值，任何不能对你的目的产生帮助的都是鸡肋，要及时止损。

你是想减少原型的返工次数？出需求时考虑的更加全面？还是想更好的和开发打成一片？推进工作时更加高效？还是想对产品迭代掌控力更强？更快的出结果？还是想有没有更优的解决方案？提高用户体验？还是想在产品的商业决策更自如？决策效率更高？

2. 懂到什么程度

列出自己的目的，才能知道自己要学习到什么程度，以及学习哪些内容，并不是要所有的都要学，所有的都要懂。

想要和开发交流时跟上节奏，那就要懂一些行业内的专业名词或技术专业名词。

因为技术讨论方案时基本上的内容是“关键词+逻辑”，逻辑我相信大家能听懂，只是夹杂着关键词会出现断层的情况。

因此理解了关键词的含义，就能明白开发所表达的意思，才能切入解决方案讨论，接下来他们各自的分工和估时，能有效提出个人见解。

想要减少需求的返工几率，推进需求开发效率，要了解现行技术边界，公司研发能力边界，清楚哪些能做哪些不能做。

清楚岗位的分工、职责，和完整的产品开发流程，大概知道什么样的问题应该去找谁解决。

了解一些不同岗位用到的软件、工具、技术名词、专业术语等，时不时能请教下开发，这种好学的求知欲能让开发认为你是自己人，也乐于去做一回老师。

既能和开发打成一片，也能在提出需求时考虑到实现难度，自己能提前进行规避。

想要对产品迭代掌控力更强，那就要掌握一定的项目管理知识，包括流程和管理工具，清楚团队中每个人的开发能力和效率，学会拆解开发任务，掌握正确的估时方法，对常见功能估时心里有底，掌握日常跟进内容，具备风控能力，并在出现延期时进行有效决策。

想要了解更优的产品解决方案，提高用户体验，那要熟悉产品所在的技术生态，看生态内开放了哪些接口和能力（如公众号和小程序生态，可以看开放平台），关注行业技术升级动态，找到能提高产品体验的结合点。

清楚行业内的技术栈能解决什么问题，优缺点是什么。

想要找到产品突破点，提高决策效率，要对数据埋点技术有所了解，清楚不同的数据收集方式的应用场景，掌握数据库的基础知识，比如表、字段、视图等，学会使用sql查询语句，或者一些BI工具，这样可以根据自己的想法去拉取想要的数据，不需要每次求助开发，让决策更高效。

产品经理对于技术的懂，只要做到知道是什么，有什么用即可，至于怎么用，好不好用，可以让技术来把握。

如果你是一个创业者，觉得研发总是拖后腿，产品节奏跟不上，自己从头学技术肯定不是最好的方案，要不就找一个技术合伙人，要不找一个信任的外包团队长期合作，还可以使用低代码开发平台，也能满足80%的标准化需求，把自己不擅长的剥离出去，创业更要聚焦。

如果你负责工具类的产品，尤其像给技术人员使用的，比如数据中台、无代码开发平台、可视化平台、云平台等，是必须要精通这个行业的技术的，请无视上面的内容。

3. 要懂哪些内容

根据上面所描述的程度，列出了以下相关技术内容。

大家根据自己的目的，选择有帮助的内容去了解，一些关键词自己去查，可以采用联想词学习法扩充知识点，按照自己的理解做笔记，印象会更加深刻。

技术人员的思维方式，知道如何和他们沟通。技术边界，包括公司内部人力和技术能力边界，知晓哪些能做哪些不能做。开发岗位分工和责任：产品、UI设计、前端、后端、测试、DBA、运维。完整的产品开发流程。开发人员的一般工作流程。开发说的“做不了”到底包含哪些信息，以及如何去推进。任务估时的常用步骤方法、任务估时参考。WEB技术：URL、TCP/IP、HTTP/HTTPS、SSL。前端技术：SDK、POST/GET、AJAX，COOKIE/SESSION、TOKEN、原生开发、混合开发、小程序。后端技术：长连接、短连接、同步、异步、回调、队列、栈。技术工具：Postman、Firebug、IDE。技术术语：搭环境、建表、写死、技术栈、架构、框架。API接口是什么，包含哪些内容。服务器、服务器系统、数据库、缓存、定时任务。沟通和提问的技巧。

4. 如何有效学习

快速掌握一个行业内所需要懂的知识，我觉得冯唐老师的《冯唐成事心法》中的方法非常值得借鉴：

先找到100个行业内的关键词，然后去查关键词的定义，我们只要知道是什么，以及有什么用即可，做完了这一步，基本上你就能和开发有共同话题了。总结出你不明白的点，找几个资深点的人深聊，看他们关注什么，看重什么，这是和公司的人建立关系的过程，不要怕问一些傻问题，对于一些有求知欲的人，很多人还是愿意当一回老师的。找几本行业内的专著，认真阅读做笔记，这步可选择性的做。

如果你还想对开发了解更深刻一些，掌握一些开发的基础能力，增加自己的逻辑思维能力，可以先学一些入门较为简单的语言，从HTML/CSS/SQL开始，能够自己做几个静态页，能够自己拉想要的数据。

之后可以尝试学习JavaScript/TypeScript，能做一些简单的交互或者小程序，这样对开发的工作和流程体会更深，前端语言所见即所得，有效的反馈能够快速获得成就感，不至于装个环境就让你从入门到放弃。

这个时候如果你觉得还挺有意思的，可以深入了解前端的框架如vue，或者选择一门服务端语言如PHP/GO/PYTHON/JAVA/C++，找一个实战的案例视频，实实在在的开发一个项目，基本上就算技术入门了。

想学更多的技术，可以去 W3cschool 技术学习社区菜鸟编程平台，里面已经涵盖了目前所有的流行技术，内容丰富，且大部分是免费的。

随着时间的推移，产品经理对某个领域的技术也会越来越熟悉，除非个人拒绝学习，否则在工作的压力之下，能学到很多技术方面的知识。

四、懂技术的好处

除了解决自己面临的一些问题，懂技术还有其他的好处。

可以和开发讨价还价，而对方不会认为你过界，不是外行指导内行，通过沟通中挖掘出最优的方案，你还可以勇敢的和开发一起做任务拆解，直到将每个人的每天做什么，安排的明明白白，并得到开发的认可。

其次，编写需求文档逻辑性更强，能考虑到一些产品的边际情况，产品的体验也更严谨，同时适当的考虑技术的实现难度，对产品逻辑进行优化，选择开发更高效的方法去实现同样的价值。

然后，能考虑到产品远期的发展对技术的影响，并认真和开发探讨，做好提前规划，不至于后期对技术架构进行大调整，开发也会认为你很懂他们，更愿意和你合作，相互信任和支持能够给产品经理带来强烈的自信。

最后，当你想去验证一个想法，能够想到快速实验的解决方案，并能和开发一起讨论得出最省成本的实现方法，没资源时，你能找到一定的方法把事办好，有资源时，能挖掘出资源的更大价值。

五、最后的话

俞军在《俞军产品方法论》中提到，产品经理的职责是要对产品的市场结果负责，要关注产品的“需求、生产、销售”三个环节，并“协调”公司不同分工下的不同职能，让大家共同完成目标。

这显然是从更高的角度去定义了产品经理的工作内容，产品经理是一个综合能力要求很强的岗位，你可能需要了解很多方面的知识，你可能会遇到很多困难。

但唯一不变的是产品价值目标的坚持，为了实现目标你会去寻找一切可能的解决方案，懂技术只是其中的一个解决方案，要与不要，就看能不能解决问题，能不能帮助到你。

很多认为自己做的事情很杂，似乎没有重点，那是我们对自己负责的产品理解还不深刻，还没有形成那份“感情”，做产品，就像谈恋爱，要有敬畏之心！

作者：周武，曾就职于腾讯、边锋，现在一家上市公司产品负责人；公众号：周武说

本文由@周武 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 pexels，基于CC0协议。