依我看，产品经理需要懂技术，而且还要写代码，写过代码和看过书完全是两回事。
但是不需要水平有多高。
哥这么多年七七八八学了点技术，虽然至今还是菜鸟，但是比完全不懂技术的，还是感觉踏实很多。
不过我从一开始就是最简单最实用的VBA、VBS、JS入手，目的就是操作EXCEL操作电脑里的文件，跟DOS批处理似的，生产出来的代码直接就是简化自己日常工作的。到后来我做的东西给全公司人用了，直接提高了大家的生产效率，以至于有人要求技术也开发一个专业的产品来，可惜产品出来大家还是宁可用我的脚本，不用专业技术做的EXE程序，虽然我的脚本程序几乎没有界面，但操作简单够智能。
我建议所有文科生想学技术的，不要跟风开发什么苹果APP，先学点对自己工作直接有用的脚本语言，简单归简单，其实没啥可耻的。
做出来的东西自己就是第一个用户，每一次的改进对自己都有好处。这感觉是非常的爽。
一上来就学一些特高级特潮流的语言，或者特低级特底层的语言，我觉得都没什么好处。你要是问专业程序员，他肯定推荐你学C、C++什么的，理由是学了之后基础扎实，啥也不惧，我擦，他自己对外宣称要花一辈子吐血去学的东西， 再让你去学，你说这算怎么回事？
你懂得if else，懂得循环，懂得数据库怎么回事，懂得面向对象是啥意思，这就够了。你说你要学会用指针有什么意义，你会操作内存又有什么意义，你理解什么是多态又有什么意义？
学技术的目的是为了用，而不是做屠龙高手，华山论剑。
（其实有很多技术人员， 貌似屠龙术不少，一张嘴就是没有啥实现不了的，真到了开发的时候，复杂点的业务逻辑都能把他给圈糊涂了。）
依我看最好的学习办法不是看书，而是直接COPY帮助文档里的示例代码，改，调试。
还有，不要被IDE折腾死了，IDE固然方便高效，但是新手装个IDE真是挺烦的。
所以建议学技术还是先从脚本开始（但不建议学rubby和python），开发产品先从网页开始。
你写PHP\js代码，根本不需要什么IDE，干净利落editplus直接就上了，调试直接就浏览器。你搞什么安卓开发，你装java装eclipse完了还要下载一大堆android的东西，速度慢得跟牛一样，一大堆版本问题，还有模拟器。你搞IOS，你还要有MAC，还要注册神马的。
搞完这些你都吐了，往电脑里装了N多乱七八糟的玩意，却连一句代码都不懂，你说你是何必？你搞网站，网上有现成的三件套，apache+mysql+php，一次性全装好，放个只有一句echo的页面到指定文件夹，当时就可以看到“网站”效果。至于VBA，直接在word\excel\ppt里就带了，录个宏， 你改一改就是你的第一个可运行有用的程序！批量处理一些EXCEL上的工作，瞬间解放生产力
神马hello world，关你屁事啊？！
花几天时间，跨过最初的障碍，很快你就可以理解工程师的爽和痛了。
再往后，你要学C学JAVA，做个windows下的EXE，做个安卓APP，那都是看你的毅力了，起码你不会被唬住了。什么代码之美，各种程序员们争执的牛B问题，你都可以逐步理解。
以后技术再跟你说什么，你哪怕不懂，上网搜搜也能明白。
如果你非要选择买个什么很吊的书在那里狂看，十有八九你永远跨不过障碍。到头来你还是啥也不明白。
如果你连VBA和JS都害怕。你可以学HTML+CSS，这些虽然不算编程，但至少学了有收获有用，没事弄个博客，自己还可以改改界面，比你啃完一本破书还是啥也不懂要强多了。
不过懂了技术，不代表就能和程序员和谐相处。
如果不懂人情事故，就是程序员转产品，也未必能和程序员打好交道。
个人认为可以分阶段看。
一、pm的成长本质上是不断假设，不断验证的过程。大概是7个阶段：入门阶段p4，练习阶段p5，熟练执行p6，创造价值p7，权衡决策p8，变迁阶段（产品架构师）p9，封神阶段（上帝视角）p10.
二、技术理解大概可以分为5层：逻辑层（把产品需求翻译成逻辑），实现层（具体的函数方法、写代码），接口层（各模块交互的通道），数据层（程序执行的结果），架构层（技术的结构、调用关系、规范）.
三、不同阶段pm有不同的使命和技能要求
-p4阶段的pm：是打底子的阶段，这个时候你去研究技术是没有意义的，这个时候的使命是产品入门，熟悉业务、练习工具，掌握产品设计基本功。
-p5阶段的pm：是不断训练自我的阶段，这个时候必须注重逻辑层的训练，例如画流程图，穷举从0到n每一种情况的解。
-p6阶段的pm：之所以叫熟练的执行者，因为他是公司战略落地的中坚力量，要求每一个解法都是最优解，因此这个阶段的pm最需要加深对技术的理解。训练方法是同理心代入，即换位思考，站在rd的角度思考逻辑是否有漏洞，函数是否可复用（开发成本），接口如何定义，涉及哪些字段，数据如何流转，日志能否顺利入库。pm同理心代入rd的对象，越是高阶、架构能力越完美，对pm的成长越有好处。因为技术架构和产品架构本就是相通的。当然也不能沉迷于技术，即，可以只了解但不掌握技术实现层的能力。而逻辑层、接口层、数据层、架构层是必须深入理解的，这样pm才能不断给出最优解，扫除需求中的隐患（扫雷）。
——因为pm要做的是倾听并认同rd，而不是指导rd，过于沉迷实现层，你就完全变成了rd，会冒出一堆这句代码应该这么写，这里应该这么实现的想法，反而会让rd反感。
#-p7阶段的pm核心使命是创造，由于这种创造往往涉及到新技术、新解法，因此更注重架构层。这里有人可能会说，我见过很多高阶的pm不懂技术架构，也没见他们画过架构图，但是他也做的很好。我的看法是这样的：技术架构、产品架构、组织结构，本就是相通的。p7以上的pm，他们能够在日常的组织沟通中，润物细无声的掌握组织架构，进而理解技术架构。不信可以随便找一个p7的pm问他们技术团队是怎么分工的，他一定能给你讲清楚：我司的rd有*个组，分别叫abcde，他们分别负责***，其中e组是我创造了**业务/服务后专门组建的。还会觉得他不懂技术架构吗？不可能不懂的，只是没有专门去梳理画图而已。p8以上的能力都是已经被验证过无数次的，他们要么同理心极强可以看人知事，要么经历了无数的权衡，其决策的复杂性早就超出了架构本身。也许你的老板当年就是在和rd聊天的时候掌握了组织架构，进而在心中投射出技术架构，并hold产品架构。
四、p5p6阶段的pm如何训练技术理解1.逻辑层必须精通：画图，流程图、逻辑图。但要注意别乱画，一定要先有主干，再有分支，脉络清晰。不要画整体的逻辑图，判断的主体不要一直在变，每一个技术模块的判断要解藕，不然rd会很难受。另外必须精通所负责业务的订单状态机，不然很难获得rd发自内心的认同。——精通的标准是获rd认同点赞2.实现层了解即可：掌握基本的概念，mvc、面向对象（封装、多态和继承）类、方法（函数）、调用，可以看懂简单的代码，了解常用函数，不了解的可百度自查。如感兴趣，可自学python，写几个函数。——了解的标准是和rd聊天畅通无阻3.接口层也必须精通：因为往往涉及到多个模块，多个团队，60%的问题都是字段理解不一致导致的。p6阶段的pm必须掌握每一个核心接口，尤其是后端与前端的接口，准确记住核心字段的定义、类型、返回值，否则在我看来都是会出问题的。——精通的标准是接口文档心中留4.数据层要做到熟练掌握：因为p6的pm往往是团队的中流砥柱，是一切的兜底，比如数据分析师生病了，难道昨天的数据就不看了吗？我认为现在pm的竞争比前些年要激烈的多，标准也严格的多，除非极少数天赋极高工作不久就突破p7的pm，95%以上的p6同学都必须熟练掌握sql.当然这个要求也和业务相关，不同的业务对pm的要求不太一样。对于滴滴、美团这类的强业务产品，熟练掌握数据工具是必要的。
——熟练掌握的标准是在数据获取和分析方面能为团队兜底5.架构层：p6阶段也应该熟练掌握，训练方法有三种，一种是同理心代入，对于滴滴、百度这样的公司，pm每天能接触到高阶的技术架构师，在日常聊天交往的过程中，代入对方去理解他们的思想，理解他们创造的架构。第二种是组织架构代入，就是通过熟练理解rd的分工，理解人与人之间的关系，映射到技术模块，进而理解技术架构。第三种是画图，在前两种方法的基础上，画架构图，如遇困难可翻阅rd的文档甚至当面请教。——熟练掌握的标准是了然于心总结：对大多数天赋正常的pm，除了实现层可以理解即可，其它的（逻辑、接口、数据、架构）都要熟练掌握甚至精通。
p8的以上部分也是我自己同理心代入老板的视角体会的，未必正确，大家自行感受。
首先，对于产品经理是不是要懂得技术，我是保持肯定态度的。
为什么这么说呢，有以下几个原因：
可以提高自己的工作效率比如在工作中，如果自己需要看一些基础数据，我觉得这时候你可能要与开发沟通，让其帮助你提取数据，过半小时一小时后，开发把数据给你，然后发现不是自己想要的，还要反复去麻烦别人。自己效率低不说，还影响了别人，如果自懂一些技术，几个小时的事情，自己分分钟就搞定了。
可以降低沟通成本现在一堆的产品埋怨，给开发提需求，这样不行，那样实现不了，而开发则吐槽说，产品什么都不懂，提的一堆满天飞的需求，逻辑行不通。我认为这种现象的原因，其实不是产品提的需求逻辑不合理，而是产品没有办法用技术听得懂的逻辑去描述需求。
懂一些技术可以更好的把控产品设计与开发的节奏，确保产品研发周期。不仅如此，一旦你了解一门技术的边界，与你合作的研发工程师，也会更愿意与你合作。
总结：
我认为产品经理懂技术可以保证产品开发节奏；在产品设计的过程中，懂得技术自己就可以进行功能的可实现性思考，如果技术团队水平一般，而在设计中所呈现的开发难度大，且人员配置数量较低的情况下，就难以保质保量的完成开发。
一.忌不懂技术 有常识，当然不一定就能做出好产品，但没常识，就很象在村里呆了半辈子的人乍到城市，一举一动即使小心翼翼，也没法儿不透着突兀和不和谐。
很多公司都有完全不懂技术的产品人，大多年龄较长，也许是互联网出现的时候，他们已经过了充满好奇和渴望未知的年龄，不愿意放低身段去学习新东西，喜欢只凭着想象和自己的生活经验就开喷，间或以若干近期热门关键词作为点缀，以示自己尚蹲在潮流尖端。
二.忌懂技术 我遇到不少工程师喜欢说：“只要产品需求明确，技术上一切都能实现。”
这句话听起来相当豪迈，也让产品经理大为放心，觉得技术真是产品的坚强后盾。但其实传递了一个特别糟糕的信号。 当工程师这么说的时候，潜台词是：“你弄好你自己的事儿就行了，别来管我！”而且这种说法隐含着一个乐观但显然并不现实的假设：技术是无所不能的，他（掌握技术的人）也象灯神一样，可以实现你的任何愿望，只要你能明确的描述它。
我不知道阿拉丁说完愿望之后，假如胆敢继续追问灯神将具体采用何种技术方案来实现的话，会不会被塞到灯里，但我知道很多工程师在发现你关注技术层面过深的时候，都会有种领地被侵犯的感觉。 这就是工程师维护自己专业槽的本能，与行业中其它角色相比，工程师地位不是最高，待遇也不是最好，还经常加班加的要死要活的，唯一得天独厚的优势，就是专业槽比任何角色都深。关于产品、关于UI、甚至关于商业模式每个从业人员都能喷上几句，要是说到用户体验，那更是连业外人士都敢大喷特喷而没有任何心理负担：反正我就是用户嘛，越傻越光荣。而一旦涉及到代码，大多数人就直接晕菜了。
想想那些UI设计师的苦逼段子，工作时没有喷子们指手划脚的干扰，真是上帝赋予工程师独有的恩赐。 所以当他们认为有外人正试图跨越这条槽时，自然会有所警惕，甚至体现出抵制和敌意。当一个产品经理发现工程师开始比较密集的使用术语或拼命把简单问题往复杂了说，你应该知道，他们在槽边开始向你射箭了。
从整个产品乃至公司的角度来说，各个专业角色之间的专业槽都是应该被填平的，产品经理不该对工程师玩挟天子以令诸侯，不要总假装自己是用户的三个代表，动不动就拿想象中的“用户需求”当“奉天承运”来用；工程师也不必总装灯神，假装无所不能很累的，工程师之间必有能力高下之分，其实有时候功能做不了或做不好，纯粹只是因为工程师能力所限。如果彼此坦诚一些，大可以提前有效沟通，尽可能避开那些投入产出比过低的部分，有不少工程师不愿意拿出来讨论的技术实现上的细节，都是值得产品经理参与进来的，在这些细节上如何取舍与抉择，会对产品的开发进度、性能甚至功能带来极大的影响，如果沟通到位，往往可以让开发工程师少做大量无用功。在我开始自己动手写代码之后，对这一点有了越来越深的体会。本回答被提问者采纳