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

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

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

1. 遇到哪些问题
2. 懂技术的目的
3. 懂到什么程度
4. 要懂哪些内容
5. 如何有效学习
6. 懂技术的好处

一、常见问题

案例一：

• 开发：这个做不了。
• 产品：……

案例二：

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

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

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

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

二、找到问题本质

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

这种想法对吗？不一定。

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 甲方的优越感；
2. 能力的不自知；
3. 和开发之间的信任缺失。

1. 甲方的优越感

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

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

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

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

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

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. 如何有效学习

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

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

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

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

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

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

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

四、懂技术的好处

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

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

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

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

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

五、最后的话

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

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

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

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

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

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

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