产品经理：应该专注还是应该泛知？

　　产品经理这个岗位本就是一个不单单需要懂原型设计的岗位，还必须有沟通、文案、信息收集、背锅、当炮灰、良好的心理素质等等能力，还要在在夹缝中求生存的岗位，本就生存状态如此艰难，最近又有一个话题热议，产品经理要不要懂技术。那么产品经理到底应该专注还是应该泛知呢？
　　为什么这个话题会被热议
　　产品经理的进入门槛极低，大量基本素质都不具备的应届毕业生同学进入行业，导致了整体素质拉低，在这种现状下产品开发中产品经理又处于一个产品初态设计以及项目主导的位置，所以会遭到入职要求不低的技术、设计等白眼。另外极品的技术和产品都很常见，更不用说大量偏执到无法沟通的架构师和设计师。出现矛盾的情况更多的来自于偏执，自负，自卑，狭隘，以及，利益冲突。大家往往都站在自己的角度上思考问题，心想，我靠，这个产品要是懂点技术就知道我们有多难等等。
　　不懂技术能做产品经理吗？
　　这种“是否存在可能性”的问题，多数都是回答：YES。如果你还不甘心，继续追问：
　　不懂PS，可以成为网页设计师吗？
　　没有驾驶证，可能成为交警吗？
　　不会做饭可以成为一名美食家吗？
　　我肯定还是毅然决然的回答：YES！
　　编程这个事情，实际上就是用代码来实现看到的东西。而更重要的是产品经理，你们真的觉得程序员懂你的产品吗？其实真的未必。就算程序员懂了你说的东西，但是他们真的是你想象的那样子吗？这个回答是肯定的，不是！程序员会用程序员的思想去想这个产品，懂了你说的话之后，就会变成各种实体，然后各种方法，各种属性，当然也包括各种脚本，同时还有各种规则、限制。也就是你的产品早就支离破碎了。特别是团队开发，理想境界是根本不需要了解产品的意义，遵照文档和需求编程就是了。产品经理的职责更多的是需求分析与设计以及对产品的完整度和方向的把控上，所以产品经理并非必须懂编程。
　　懂编程有什么优势
　　那么懂编程的产品经理又有什么优势呢：
　　在设计交互原型、详细文案的时候，会以贴近程序的角度描述功能间的逻辑关系，利于程序解构功能。
　　在工期预估上可以以产品的角度估算整体时间，给项目开发人员提供更加合理、充足的时间开发产品，而不会因为时间紧促、逼迫开发人员提交阉割版的产品。
　　在开发、测试、改良过程中，可以以程序的角度提醒程序员在编程中被忽视的一些节点，让整个功能模块尽量处于闭环状态，让产品变得更加完善。
　　了解开发项目的难度，懂的程序员在开发过程中所付出的价值。付出的精力不被认同有多沮丧，外人是不清楚的。
　　可以拒绝上级或运营的一些无理要求，并且给出合理解释。即使无法拒绝，也会在时间、资源上对程序员进行补助。
　　作为产品经理应该专注还是应该泛知？
　　越来越多的招聘条件上，明确要求需要懂代码的产品经理。至于要求产品经理精通Android和iOS开发的一看就是想把开发的钱给省下来的鸡贼团队。坦率的讲，在这个产品与开发愈来愈紧密的时代，我并非完全不同意“产品经理懂代码”这件事，但是在“我们需要能写代码的产品经理”这件事情上，我觉得大家存在着相当的误解和歪曲。我可以懂，但是专业的事情，应该让专业的人来做。
　　产品和开发（不论是前端还是后端），是高度专业化的职业，有着清晰的定位和分工。每一个这样的职业都需要若干年的时间来掌控，想在一个领域中成为专家是无法一蹴而就的。我们真正需要的是能真正能做好产品的产品经理，能写好代码的开发者。已经两个岗位的紧密协作能力要实现两者的协作，需要一个关键的因素：换位思考。换位思考是设身处地理解他人感受的一种能力，这才是关键。
　　产品经理需要的真是是会写代码么？我觉得并不是，我认为需要的是程序的思维，要了解代码和开发的流程和原理。这和会写代码是两回事。产品与程序要实现的是真正意义上的相互了解，深入到位的沟通，这样才能让孤立的环节有序地整合起来，让真正的专家在他的领域发光发亮。
　　我认为专注和泛知不是两者选其一的，他其实是一个过程，在其位谋其政，首先你在产品经理的位置上你就必须要做到专注，专注于产品相关知识以及行业动态，在你的能力水平已经有空闲时间的时候这个时候才是提升其他能力的时候，才是泛知的时候，打个不大恰当的比方，产品经理的专业知识专注就好比是1而其他的编程、运营、设计等等能力都是这个1后面的0，如果连1都没做好有再多的0那也终究是0。