产品经理需要的技能简历怎么写(产品经理考什么证书)

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

月初和一位产品朋友聊天，提到了产品岗是否需要懂技术的问题，网上也有很多观点，有的极端、有的中庸。

因为我大学专业是软件工程，虽然挂了很多科，但实习的时候也正儿八经混了两个小项目经验。之后无论是做测试，还是做售前，也一直在技术圈子的边缘游离。所以我应该属于在产品同行中略懂一点技术的。

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

今天根据自己的理解和日常工作经验谈谈看法，希望能对各位产品同仁有点帮助。

也许是因为多年前一句“人人都是产品经理”的影响，也许是很多人感觉产品岗的入行门槛低，于是乎很多跨行业转型的产品人层出不穷，然而至今都很少有大学专门设立产品课。

即便市场上出现了很多产品培训、知识星球等等，但更多也都是从底层思维、行业知识、产品方法论等方面展开。

所以对于大部分产品人来说，技术、软件工程等相关的理论，不好学、也没机会学。

但在实际工作中，打交道最多的应该就是技术同学了（某些特定行业、特定岗位不在讨论范围内），无论前端、后端，无论公司的架构、开发语言是哪种，只要我们想把产品设计推进落地，终究离不开与技术同学对接。

尤其是当我们提的需求，技术同学说做不了的时候，或者和他们讨论方案的时候，亦或是出现了一些奇怪的bug来分析问题的时候，不懂技术的我们只能一脸茫然的听着，或佯装疑惑、或佯装点头。

所以大家很自然的会想到一个问题：我要不要学一下技术，起码能和开发平等对话呢。

包括在我身边，团队中的四位产品小伙伴。

七月份我们新制定了个人中短期成长规划，他们也都把“了解技术、能和开发正常对接”之类的能力提升，作为下半年的学习目标。

团队四人中，英语专业转型的小姐姐已经被“磨炼”到懂技术的行列了。来公司前就已经在之前的工作中掌握了数据库基本操作，在公司这几年，整日与开发battle，讨论方案、评审设计，已经能在技术评审时指出很多流程与结构方面的问题。

如果要了解技术，我的个人建议是从这几个方面来入手（以下建议仅针对自己的认知，偏向常规系统，很多新兴行业的系统与技术，或技术专业性较强的业务，就需要大家自己学习啦）。

之前我买过一本《给产品经理讲技术》的入门书，看了目录，然后针对性看了几个章节。也许是当时自己没有良好的读书习惯，也许是之后工作中没有应用的场景，所以没过多久也都忘了。不过当自己偶尔遇到一些技术问题时，还会再翻出来学习一下。

这也是我想和大家说的，我们如果想了解技术，一定要“用哪里、学哪里”，尽量不要体系化学习。因为体系化学习过程中，很多知识点在工作中运用不到，迟早会忘，而且也不一定有那么多时间体系化学习。

比如现在有些向产品推荐的数据分析课程，通过Python或其他语言进行编写，如果自己只是感兴趣，工作中并没有实际应用，学习一段时间后，大概率会因为实操难度而“从入门到放弃”，奇奇怪怪的失败经验又一次+1。

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

其次我们可以学一些基础的，或者几乎各个系统/产品都会涉及的技术工具。比如我给团队小伙伴的建议是：先学会基础的sql语句，然后学会看服务器日志。

这样起码我们能通过工具查看业务处理逻辑是否合理，或者后续在迭代中，针对复杂的业务场景，和开发一起进行流程设计。就像我在之前提升测试效率的推文中提到的，我们日常接触的系统问题，很多都是业务处理不合理导致的功能性问题。而非因为性能、技术平台选型所导致的技术难题。

当我们能够通过系统日志，把主流程的处理逻辑转化成流程图时，就已经很够用了，再通过不断地实践、练习，让自己熟悉。不出半年，和开发的沟通讨论就会顺畅很多。下面这张图就是我们一位测试小姐姐在刚入职时通过查日志并结合数据库梳理出的平台业务流程及处理逻辑，一共40页，太赞了！

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

第三步，如果产品涉及到第三方系统的对接合作，则可以了解第三方的API文档，基于前期的技术理解，分析产品各个模块与第三方合作系统的关联关系及相互影响策略，最终产出业务架构图、或系统间业务流程图、数据流图，基本就超出业内很多产品同仁了。

当然很多中后台的产品经理，或者网络层、数据层、硬件相关行业的产品人，在入行之后跟随产品的迭代，也能够或多或少掌握很多专业技术知识，有些可能还会转型为架构师。但是这些专业性较强，也有很多高效但不通用的方法，在此不再展开讨论（当然这些我也不会）。

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

当我们真的了解基本的技术，理解开发人员之后，紧接着我们将面临一个严重的问题：用技术思维设计产品，或因为技术思维而影响产品设计。

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

当我们在功能设计完成后，与研发进行评审或日常沟通时，会不自觉的被技术同事代入“这个功能很难做”、“这个功能花的时间会很长”的思维怪圈。最后可能自己因为同理心等原因，主动就把功能简化了，尤其是在进度计划已经确定的条件下。

一来二去，后续迭代过程中，便会自觉把一些技术难题，或者逻辑变更大的需求砍掉，逐渐让迭代方案从功能层面越来越弱。

原本懂技术是件好事，我们可以甄别出设计风险，和技术一起想出更优解决方案，或者在技术同事“敷衍”、“夸大难度”时进行合理识别。但久而久之，我们原本很重要的产品思维、对设计体验的极致要求，占比会持续走低。

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

这也是很多技术转型产品的过程中必将遇到的问题，当我们对产品有更高的要求时，技术思维也会让我们陷入瓶颈。

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

其实我挺羡慕交互设计和UI设计的，但也可能是因为自己不了解。其实他们在推进新规范与新体验时，也势必会遇到技术上的障碍。

但是真正的灵感，或者真正好的功能与体验，更可能由这些不懂技术的产品人提出来。因为他们是更专注的，目标更清晰的。

在现如今这个创新乏力的环境下，只有真正的观察用户、观察竞品、体验自己的产品，才能真正想出一些能够击中用户痛点的【微创新】功能，才能在现有版本的基础上创造出更极致的交互，设计出更有温度的功能。而这些，需要花时间探索，且不使用技术思维探索。

当我们真正有了创新的想法，更愿意让想法落地，去坚持和技术battle，坚持实现自己的方案，且不打折扣。当然这个过程很难，当我们真正懂技术又不精通技术时，可能自己就。。。

放弃了~

所以我一直在刻意锻炼自己，在思考时不去想落地。但这，也挺难的。就像“明知故犯”一样，我知道这个设计做不出来，或者没时间做，那我还要继续想吗？

说了这么多，总结一下我的观点：

真正一款好的产品问世，既要有良好的产品设计，又要有严谨的技术支撑，本身两者应通力合作，一起为了目标而努力。产品和技术不应该被对立，我们理应合力采用十八般武艺让理想逐渐照进现实。

学习技术，是为了更好的工作；不学习技术，也可以更好的工作；吵架与争执，一定不会更好的工作。

坚守设计理念与愿景，路要一步一个脚印地走。

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