编辑导语：众所周知，产品经理是一个综合能力要求很强的岗位，需要了解很多方面的知识。那在技术方面呢？产品经理要不要懂技术的底层逻辑？本文就此问题，从六个方面来展开论述，逻辑清晰。推荐对产品经理感兴趣的盆友来阅读。
有产品的同学问我，他的领导让他懂一点技术以方便工作，但领导说的不明确，自己又不好意思继续追问，因此现在很困惑，问我作为产品经理要懂技术吗？
要回答这个问题，我们要把它拆开来回答，它包含了以下6个方面：
遇到哪些问题懂技术的目的懂到什么程度要懂哪些内容如何有效学习懂技术的好处
一、常见问题
案例一：
案例二：
开发：这个功能至少要开发2周。产品：啊，这么简单的功能要这么久啊？等上线了热度都过了。开发：是的…因为…算了，跟你说也不明白。产品：……
在日常工作中，产品经理可能有以下类似的烦恼：
提出的需求被开发觉得异想天开，需求被拒，经常返工；觉得开发评估时间过长，自己很无力；需求评审会被开发批的体无完肤、一无是处；听不懂开发说的内容，开会时云里雾里，安排任务效率低；不知道技术的优劣，做决策拖后腿；出了问题不知道找谁，开发相互推诿，用户的问题无法得到快速解决；对项目进度无法掌控，版本经常延期；上线跟打战一样，问题还特别多；开发的领导好难打交道，感觉很凶；……
网上讨论最多的就是案例中所描述两个的场景，很多人为之苦恼，感觉自己经常被开发忽悠，事情推进不了就算了，开发说的话还阴阳怪气，说话夹杂着嫌弃，眼神充满了鄙夷，非常的没面子。
二、找到问题本质
很多人认为之所以出现上面的情况，就是因为自己不懂技术，当产品经理懂技术之后，开发也就无法再忽悠，没有了鄙视和嫌弃，以上问题也能迎刃而解；即便没有解决，自己的技能树上又多了一个技能，总比只懂产品要强。
这种想法对吗？不一定。
这种想法实际上是在用战术上的勤奋来掩饰战略上的懒惰，开发是一个很看重实战的岗位，我们利用业余时间学习的一些皮毛，就想和在实战中厮杀多年的开发掰手腕，那就把开发岗位看太轻了，在他们眼里，我们和刚入行的开发没区别。
退一步说，哪怕你天赋不错，学到了一些技术，开发想忽悠你还是一样，因为你不了解实际的代码情况。
即使同样能力的开发，面对陌生的项目、不熟悉的框架和代码，在做评估的时候，都会选择保守，你也不能代替他们去开发，这种情况尤其以跨部门沟通时更加明显，因为你根本指挥不了他们。
开发说“做不了”，你说“可以做”，开发说“你来？”。
开发说“这个功能最少要3天”；你说“少唬我，我可是练过的，最多1天半就够了”；开发说“我就要3天”，接下来你有两个选择：
当场揭穿他，可能会上演全武行；向他领导告状，领导可能和颜悦色的告诉你，要相信专业的；也许领导这次帮你解决了，下次呢？
因此，懂技术不一定能解决“做不做“和“忽悠”的问题，或者说要解决以上的两个问题和懂技术不能划等号，那可以给以后找工作加分吗？
绝大多数情况不行，除非你在一个项目里即是产品，又是开发，而且项目完整跟完并上线运营，并且这个项目和这家公司类似（需要运气），这样的懂技术才可能成为加分项，否则很难。
因为我们面试的不是技术岗位，级别越高价值也越低；产研负责人岗可能有价值，但这时就不是加分项，而是必要条件。
有人不服气说，怎么就不是加分项，懂技术可以很好的和开发沟通，是的，可能，但这里的重点是沟通能力，技术只是其中的一小部分，也不能划等号，你是不是听过很多程序员都不擅长沟通的例子。
当然，以上的分析不是说懂技术没有价值，而是不希望将懂技术当成唯一的阻碍，产品做不好是因为开发不配合，开发不配合是因为我不懂技术，我很苦恼，我没有办法。
将问题推给环境，推给外在因素，没有思考对问题的本质，但是，产品经理恰恰是需要去思考问题本质的岗位。
懂技术可以辅助你把工作做的更好，但不懂也不是阻碍你推进产品进度的关键因素，绝大多数人面临推进难的问题，究其本质，在我看来就三块：
1.甲方的优越感
说出来你可能不信，开发在公司里面其实是弱势群体，作为最下游的执行方，很多时候是很被动没有话语权的，甚至经常要背黑锅。
而产品经理作为甲方，习惯把开发当成纯执行者，听话就好别瞎BB。
优越感带来的第一个问题，是无法接受对方提出的修改意见和建议，觉得在挑战自己的专业，你一个开发懂什么？（这句话开发也经常对产品说，你啥也不懂），有时实在无法说服对方，就耍赖说“我不管，我就要，实现不了是你的能力问题，怎么实现是你们的事”。
优越感带来的第二个问题，是在需求被拒时挫败感很强，内心觉得被开发鄙视了，其实真的想多了，开发一般都比较单纯，不会因为某个人不懂技术而看不起他，绝大多数问题是因为某个人的态度导致。
所以解决问题第一步，端正态度，实现和开发平等对话，不是甲方乙方的关系，而是战友关系，将双方拉到统一战线。
2.能力的不自知
需求来自来自用户的诉求、老板的想法，产品经理很容易成为传声筒，没有去思考逻辑和细节是否合理，绝大多数开发与产品间的争吵，都是因为产品需求逻辑的问题。
在需求评审会中，面对开发的疑问，无法在逻辑上讲通，产品经理很委屈，觉得这不是自己的错，明明是用户的需求，老板都答应了，开发怎么还这样呢？这不是刁难人吗？
面对开发的不配合，没有去思考自己的问题，而是怀疑开发在针对自己，给自己的错误找很多借口。
人与人之间的合作，不会因为对方不懂己方的专业而嘲笑，而是因为对方不自知、不虚心、不学习，才会让人看不起。
学会调整自己的心态，认识自己的不足和知识盲点，不明白的地方虚心请教，承认自己不足有时比去学习一项新技能更难，主动避险是人的天性，我们习惯为问题找外部原因，而忽略了对自己内心的建设。
3.和研发之间的信任缺失
我们习惯用“怼”和“甩锅”来构建产品和开发之间的爱恨情仇，从内心就已经将产品和开发摆在了对立面，在双方划了一条信任鸿沟，需求评审会就变成了博弈游戏，认为对方是欺负自己不懂（当然也有可能是真的，但不常见）。
你觉得开发在偷奸耍滑，开发效率这么低，每天不知道在做什么，开发觉得你在异想天开，啥也不懂，脑子瓦特了。
懂技术似乎是一个构建信任关系的桥梁，但其实重点是如何和开发建立信任关系，而不是一定要去学习技术，其他方法可以尝试，如共同兴趣爱好，日常的交流关怀，都是不错的方法。
在自己领域足够强也能增加信任度，需求够专业，逻辑性够强，思考有深度，上线有结果等等，人性是对强者会有天然的崇拜感，做出成绩就是最好的信任背书，开发也不会因为你不懂技术而轻视你，因为相信你肯定能做好。
因此，合作的基础是信任你同部门的队友，双方不是你死我活的拉锯战，而是为了实现共同目标的攻坚战，通过统一目标也可以成为自己人，信任每个人在自己擅长的领域能做出最好的判断。
如果你做不到对每个人的信任，那可以招一个你信任的资深开发，让他来帮助你做判断也是一个有效的方法，没有了信任，你再懂技术也没有用。
倘若是跨部门，在对方的阵营中找到一个可信任的战友是有必要的，这个战友最好是团队中比较资深的那种，亦或者是有想法、责任感比较高，可以帮助你解决很多问题，时不时的请教，也能让你做事情事半功倍。
排除了以上三点问题，先认清自己，认清环境，找到关键因素，看看懂技术是不是真的是你遇到问题的解法。
三、懂技术的正确姿势
1.懂技术的目的
要不要懂技术，先要想清楚自己的目的，以终为始才能做到有的放矢，不同的目的，所需要学习的内容和程度会有所区别，但不管是什么目的，有一点可以肯定的是：
绝对不是去代替开发写代码！除非你是纯粹个人兴趣，除非你是创业者要控制成本，否则，千万不要本末倒置，将自己陷入开发的自嗨中不能自拔。
甚至有些人还说要懂技术架构、懂计算机底层，这是要飞天吗？
一个开发经过多年的打拼，多个项目线上实操，没日没夜的解决各种性能瓶颈，才能成为一个合格的架构师，才敢说自己懂技术架构。
一个工作5年以上的老码农，如果没看过一些技术的源码，只敢谦虚的说自己知道原理和怎么用，底层如何实现还需要研究。
咱就看了几个名词解释，安装了环境输出了HelloWorld，开发了一些简单的增删改查就大言不惭的说我懂技术架构，懂技术底层，只能是班门弄斧。
技术是一个需要持续学习的领域，每隔几个月就会有新的技术诞生，永远也学不完。
只有清楚自己的目的，才能清楚学习边界，才能在有限的时间内快速掌握所需要的知识，并在实际工作中使用产生价值，任何不能对你的目的产生帮助的都是鸡肋，要及时止损。
你是想减少原型的返工次数？出需求时考虑的更加全面？还是想更好的和开发打成一片？推进工作时更加高效？还是想对产品迭代掌控力更强？更快的出结果？还是想有没有更优的解决方案？提高用户体验？还是想在产品的商业决策更自如？决策效率更高？
2.懂到什么程度
列出自己的目的，才能知道自己要学习到什么程度，以及学习哪些内容，并不是要所有的都要学，所有的都要懂。
想要和开发交流时跟上节奏，那就要懂一些行业内的专业名词或技术专业名词。
因为技术讨论方案时基本上的内容是“关键词+逻辑”，逻辑我相信大家能听懂，只是夹杂着关键词会出现断层的情况。
因此理解了关键词的含义，就能明白开发所表达的意思，才能切入解决方案讨论，接下来他们各自的分工和估时，能有效提出个人见解。
想要减少需求的返工几率，推进需求开发效率，要了解现行技术边界，公司研发能力边界，清楚哪些能做哪些不能做。
清楚岗位的分工、职责，和完整的产品开发流程，大概知道什么样的问题应该去找谁解决。
了解一些不同岗位用到的软件、工具、技术名词、专业术语等，时不时能请教下开发，这种好学的求知欲能让开发认为你是自己人，也乐于去做一回老师。
既能和开发打成一片，也能在提出需求时考虑到实现难度，自己能提前进行规避。
想要对产品迭代掌控力更强，那就要掌握一定的项目管理知识，包括流程和管理工具，清楚团队中每个人的开发能力和效率，学会拆解开发任务，掌握正确的估时方法，对常见功能估时心里有底，掌握日常跟进内容，具备风控能力，并在出现延期时进行有效决策。
想要了解更优的产品解决方案，提高用户体验，那要熟悉产品所在的技术生态，看生态内开放了哪些接口和能力（如
联系电话：