产品经理需要懂技术吗？ 可能大部分同行觉得有必要，因为可以和开发平等对话，但是真正了解技术后会这样吗？ 不懂技术就没有优势吗？ 本文是根据我的经验和遇到的问题整理的，感谢阅读。

月初和一个产品朋友聊天，提到产品发帖是不是需要懂技术。 网上也有很多意见，有的偏激，有的温和。

因为我的大学专业是软件工程，虽然通过了很多科目，但是在实习的过程中也混了两个小项目的经历。 之后无论是测试还是预售，一直徘徊在技术圈的边缘。 所以我应该属于懂一点技术的产品同行。

理解技术在我的日常工作中给我带来了很多帮助，但也给我后续（包括现在）造成了一些瓶颈和内耗。

今天我就结合自己的理解和日常工作经验谈谈自己的看法，希望对各位产品同仁有所帮助。

01 为什么会有这样的问题？

或许是因为多年前“人人都是产品经理”这句话的影响，或者是因为很多人觉得产品岗位的进入门槛低，所以才层出不穷跨界转型的产品人. 然而，到目前为止，很少有大学设立产品经理。 班级。

尽管市面上有很多产品培训、知识星球等，但大多都是从底层思维、行业知识、产品方法论等入手。

因此，对于大多数产品人来说，技术、软件工程等相关理论很难学，也没有机会学。

但是在实际工作中，技术同学应该是处理的最多的（一些具体行业和具体职位不在讨论范围内），不管是前端还是后端，不管公司的架构还是开发语言是，只要我们想把产品设计的提升，最终还是离不开和技术同学的对接。

尤其是当我们的技术同学说我们不行的时候，或者跟他们讨论解决方案的时候，或者出现一些奇怪的bug分析问题的时候，不懂技术的我们只能一脸茫然。 听，或假装不解，或假装点头。

所以大家自然而然会想到一个问题：我该不该学技术，至少能和开发平等对话。

02 几位小伙伴的统一诉求

包括我这边，团队里的四个产品合伙人。

7月份，我们制定了新的个人短期成长计划楼宇自控售前技术规范最新版，他们都把“懂技术，能正常对接开发”的能力定为下半年的学习目标。

团队的四名成员中，转型为英语专业的小姐姐被“培养”到了技术达人的行列。 在来公司之前，我在之前的工作中已经掌握了数据库的基本操作。 在公司这几年，我整天都在和开发打交道，整天讨论方案，审查设计。 我已经能够在技术审查期间指出许多过程和结构问题。

03 这么多技术，从何入手？

如果你想了解技术，我个人的建议是从这几个方面入手（以下建议仅供你自己认知，偏向于常规系统，很多新兴行业的系统和技术，或者技术专长强的企业，你需要你自己学习）。

之前买了一本入门书《向产品经理传授技术》，看了目录，又看了几章。 可能是当时没有良好的阅读习惯，也可能是后来没有在工作中应用，过一段时间就忘记了。 但是，偶尔遇到一些技术问题，我会自己去挖掘学习。

这就是我想告诉你的。 我们要想了解技术，一定要“用到哪里，学到哪里”，尽量不要系统地学习。 因为在系统学习的过程中，很多知识点在工作中用不上，迟早会忘记，可能没有那么多时间进行系统学习。

比如现在推荐给产品的一些数据分析课程都是用英文或者其他语言写的。 如果只对工作感兴趣而没有实际应用，经过一段时间的学习，很有可能会因为实际操作的难度而“从入门到放弃”。 ，怪异的失败经历再次+1。

产品本身底层能力的增长和行业知识的增长，已经需要我们花费大量的精力。

其次，我们可以学习一些几乎每个系统/产品都会涉及到的一些基础的，或者技术的工具。 比如我给组员的建议是：先学习基本的sql语句，再学习阅读服务器日志。

这样至少我们可以通过工具来检查业务处理逻辑是否合理，或者在后续的迭代中，针对复杂的业务场景进行流程设计和开发。 正如我在之前关于提高测试效率的推文中提到的，我们日常遇到的很多系统问题都是由于业务处理不合理导致的功能性问题。 而不是性能和技术平台选择造成的技术困难。

当我们能够通过系统日志将主进程的处理逻辑转换成流程图的时候就足够了，之后我们就可以通过不断的练习和实践来熟悉它了。 半年之内，跟开发的沟通和讨论会顺畅很多。 下图是我们的一位测试人员刚入职时查看日志并结合数据库整理出来的平台业务流程和处理逻辑。 一共40页，太棒了！

另一方面，我们需要了解一些基本概念。 比如【接口】，【加密】，【数据字典】，【认证任务】，【前后端分离】，常见的架构概念。

以目前流行的微服务架构为例，注册中心、配置中心、通信网关、日志收集、协议转换等概念，可以从网上大量的文章中了解到。 前提是，公司的产品用的是哪一套技术架构，我们就去寻找哪一套。

第三步，如果产品涉及到第三方系统的对接合作，可以看懂第三方API文档，在之前的技术理解的基础上，分析产品各个模块之间的关系和相互影响策略第三方合作系统，最终输出业务架构图，或者系统间的业务流程图，数据流图基本超越了业内很多产品同行。

当然，很多中后端产品经理，或者网络层、数据层、硬件相关行业的产品人，入行后或多或少可以掌握很多专业技术知识，跟着产品走迭代，有些甚至可能转变为建筑师。 . 不过这些都是专业性很强的，还有很多高效但不通用的方法，这里就不展开讨论了（我当然不会）。

其实我也很想看到一些产品同事总结分享一下我是如何在工作中从0技术一步步学习成长的。 可惜我没有这种经历，写不出来。

04 懂技术，然后呢？

当我们真正了解了基础技术，了解了开发者之后，我们就会面临一个严重的问题：用技术思维设计产品，或者因为技术思维影响产品设计。

因为我在这两年的产品工作中一直面临着这个问题，也陷入了“挣扎”和“内耗”之中。

当我们在功能设计完成后回顾或与研发交流时，会不自觉地被技术同事代入到“这个功能很难做”“这个功能要花很长时间”的思维圈。 最后，可能是出于同理心等原因，我主动简化了功能，尤其是在日程已经确定的情况下。

周而复始，在后续的迭代过程中，会有意识地砍掉一些技术上的难点或者较大的逻辑改动，逐渐让迭代方案从功能层面上越来越弱。

本来，懂技术是好事。 我们可以识别设计风险，与技术一起提出更好的解决方案，或者在技术同事“敷衍”或“夸大难度”时做出合理识别。 但随着时间的推移，我们原本重视的产品思维和对设计体验的极端要求的比例会不断下降。

当我发现这个问题的时候，虽然我在后续的设计中还是会考虑解决方案的难度，但我会刻意提醒自己：我是对用户负责的，也是对产品的体验和价值负责的。

这也是很多技术改造产品过程中不可避免会遇到的问题。 当我们对产品有更高的要求时，技术思维也会让我们陷入瓶颈。

于是出现了这个阶段的辩证关系：城外的人想进来，城内的人想出去。

05 不懂技术有优势吗？

其实我还是挺羡慕交互设计和UI设计的，但也可能是因为不懂。 事实上，他们在推广新规范、新体验的时候，必然会遇到技术上的障碍。

但真正的灵感，或者说真正好的功能和体验，更可能来自于这些不懂技术的产品人。 因为他们更专注，目标更明确。

在缺乏创新的今天，只有真正去观察用户，观察竞品，体验自己的产品，才能真正想出一些能够切中用户痛点的【微创新】功能，并且能够建立在现有版本的基础上。 打造更极致的互联网交互，设计更温馨的功能。 而这些都需要花时间摸索，不要用技术思维去摸索。

当我们真正有一个创新的想法时，我们更愿意让想法落地，坚持技术，坚持不妥协地实现自己的计划。 当然，这个过程是艰难的。 当我们真正懂技术，却不精通技术时，我们自己可能就会吃亏。 . .

放弃~

所以我一直在刻意锻炼自己，不是想着就着陆。 但这也是相当困难的。 就像“明知故犯”一样，我知道这个设计不能做，或者我没时间做，那我还要继续考虑吗？

06 应该是什么？

说了这么多，这是我的看法：

刚入行的产品人不要以技术为首要目标，产品设计能力、逻辑能力、协作能力、行业知识等更重要。 当你在工作中遇到技术难题或想与研发进行平等对话时，可以选择“学以致用”的知识点快速突破。 同时，你可以参考我的建议，从数据库和日志层面快速上手。 但任何时候，都不要失去产品的核心思想和对用户体验的追求。当我们的能力达到更高的层次，或者当我们拥有更高的话语权时，我们还是要做一个“偏执”的产品人，毕竟产品经理可以改变世界[手动狗头]07写在最后

一款真正好的产品要问世，不仅要有好的产品设计，还要有严谨的技术支持。 两人应该齐心协力，共同为目标而努力。 产品和技术不应该对立。 我们要齐心协力，用十八般武艺，让理想逐渐照进现实。

学习技术是为了更好的工作； 不学习技术，你可以更好地工作； 吵架和纠纷肯定不会更好。

坚持设计理念和愿景，路要一步一步走。