为什么不懂技术的人可以做产品经理--百度百家
为什么不懂技术的人可以做产品经理
分享到微信朋友圈
为什么不懂技术的人可以做产品经理
首先说一下产品经理的主要构成：毕业就做产品或转自其他工种。
毕业就做产品的，除了计算机系的大多也不懂技术;转自其他工种的，我了解的，有来自开发、运维、运营、设计、销售、售前、业务等各个领域的，其中必然有大量懂或者不懂技术的。如果一定要按照这个维度来分，那么就只有技术背景、非技术背景两类。
在我的八年产品经理生涯中，见到过相当多的优秀的产品经理，也有更多刚及格的产品经理，当然，有更多的产品经理尸位素餐，完全不及格。所以我认为其实是人人都能做产品经理，但不是人人都能做好产品经理，大家都盯着产品经理喷，无非就是这个职业的批评难度最低。其实这么多年我见过的开发也必然是三六九等，优秀的、及格的或者是不及格的，不一而足，但是批评技术同学的很少，因为有些开发会用一句话来回答：你懂技术么?不懂勿喷。这个世界就清静了。
这里我没有任何攻击或者侮辱其他任何人的意图，我只是想说，产品经理的工作是工作难度相对入行门槛差距最大的一个工种，尤其是人人都能做产品经理这个概念广为流传之后，很多人会故意曲解这句话(这里必须举个栗子：成功=99%的汗水+1%的灵感这句话广为人知，但是真正重要的后半句却有意无意间被宣传者忽略)。
接下来我说说我对产品经理这个工种的理解。
从上到下看，一个合格的产品经理需要达到以下标准：
1、理解公司发展战略，能够带领所负责产品和公司战略有效结合，使得产品规划符合公司的发展需要
2、了解行业动态和市场趋势，能够制定和规划产品方向，并根据变动适时调整
3、把握产品的定位、目标用户群，以及目标用户群的实际需要，使得产品能够切合用户需要，对用户有价值
4、能够综合用户的实际需要、竞品和市场状况，制定产品的路线图和各版本实际需求，形成有效的产品描述和设计文档(文档类型并不重要，能够清晰描述即可)
5、能够把产品需求如实有效地传递给开发以及团队中所有的相关方，使其在团队内部形成共识，能够认可并完成共同确认的目标;协同技术团队确定技术实施方案。
6、根据项目情况，组织和协调所需资源，尤其是跨团队跨部门的人力资源资源
7、根据资源情况，合理安排项目管理粒度和项目周期。
8、带领虚拟团队，按照既定的产品规划(包括CR)完成设计、开发、测试、上线和迭代，即常规的项目管理过程。当然，项目管理过程可以根据实际需要简化或者精细化，不再赘述。
从上面的情况看，其实所谓的“懂技术”在产品经理的技能树上所占的比重并不是很大，我不否认其重要性，但是不了解市场和战略的PM，对一个产品线来说，其危害远比不了解技术要高。
那么问题来了，为什么那么开发同学吐槽产品经理不懂技术?嗯，同理，还有很多设计吐槽产品经理不懂设计。我的理解有两点：
1、产品经理对于开发、设计师来说是任务输出方，在某种程度上代表着劳资双方的对立，很多时候产品经理需要向团队内部输出公司战略或者领导意图，当这个业务线面对着一个想法复杂而多变的老板的时候，那么把老板想法转换成具体任务的过程就会变得无比悲催。
2、技术、设计是开发同学和设计师的职业壁垒，是工程师和设计师批评产品经理的最直接有效最难以反驳的武器，并且很容易在同工种之间获得共鸣。这就好像日韩只有在批评中国的时候才达成共识，中韩只有在批评日本的时候在合作无间、中日也只有在批评韩国的时候才最容易同仇敌忾。
产品经理需要怎么改变才能从根本上解决这个问题?嗯，怎么做都不可能完全解决，因为这是一个“我们来做这个”和“我们为什么要做这个”的根本对立问题。但是还是有一些办法可以缓解一下。
同理心问题，产品经理必须站在工程师和设计师的立场上思考问题，因为PM才是虚拟团队的leader，而其他工种不是。然后才是技能问题。
项目管理是产品经理的必备技能，无论任何背景出身，都需要基本的项目管理能力，如果从事了产品经理工作，就必须了解学习相关的知识，并在实际环境中加以应用，而不能只是拘泥于教科书的条条框框。
产品经理的背景不同，可以懂技术，也可以不懂技术，这个因人而异。但是入行之后，完全不懂技术就不够用了，根据所负责的产品形态不同，对技术的深入程度需求也有较大差异，至少需要了解所负责产品所涉及到的技术点，需要有能力把用户需求尽可能保真地转化成开发同学能实现的描述。
懂技术这件事情，不仅会降低和开发同学沟通时的难度和被歧视风险，还会提升在面对开发同学意见时的判断力，会降低被技术团队忽悠的几率(这几种情况我都遇到过，不举栗子了)。同时，在需要向上级解释技术原因导致变更的情况下，也会有助于说服老板。(什么?我一个学心理学出身的产品经理为什么要花时间去了解技术?Emm，个人觉得这样回答的产品经理可以考虑专门做业务或者转岗)。
我之前在另一个类似问题的回答里说过“术业有专攻”，要相信自己所接触的开发团队是专业的，靠谱的，相信开发团队为实现需求所做出的技术方案是合理的，最优的。如果有质疑，可以加深沟通，以合适的方式提出自己的质疑。这里要补充一句的是，这个信任过程是需要建立的，也是会根据团队的表现不断变化的;同理，其实团队对于产品经理的信任度也是一样的情况。
吐槽是没有意义的，关键还是要解决问题。如果觉得产品经理不靠谱，那么有没有进行过深入的沟通?如果觉得开发不好沟通，那么有没有进行过了解，不好沟通的原因在哪里?如果当事人本身确实不可沟通，那么有没有考虑和对方的老板沟通，或者通过自己的老板如实反映情况?吐槽是最容易的，解决问题反而会很难。
这里必须要说一句，无论任何工种，都有不可沟通的一小撮人存在，就是无论任何沟通方式都会完败于对方的情况，如果对方人品还过得去，那么就加强线下接触，吃饭喝酒小礼物不一而足;如果人品实在不行，先考虑是否能完成当前的任务目标，结果为导向是任何公司都在意的事情。
我很讨厌上面自己的回答，貌似站在道德的制高处指指点点，充满了说教意味。我也不能说自己很多地方都做得好，面对上一段提到的奇葩合作方的情况，我也不止一次暴走。及格就是我对自己的评价，仅此而已。
如果对产品经理认证有兴趣的话，建议还是多参加线下的NPDP认证讲座，听一听讲师在日常工作中是如何利用NPDP中所学的知识进行调控产品的。这样也能够更直观的理解NPDP认证。
北京9月24日线下大型讲座“从敏捷教练到产品管理——敏捷产品管理的‘幻想’、现实与实践”报名地址：
分享到微信朋友圈
在手机阅读、分享本文
还可以输入250个字
推荐文章RECOMMEND
阅读：3214
阅读：2568
阅读：11万
热门文章HOT NEWS
在地产泡沫破灭以前，能跑得掉的，都是成功者。
百度新闻客户端
百度新闻客户端
百度新闻客户端
扫描二维码下载
订阅 "百家" 频道
观看更多百家精彩新闻产品经理懂技术的五大好处_夜的视窗_新浪博客
产品经理懂技术的五大好处
1.更丰富的产品设计
　　通常我们的产品设计工具有文档、流程图
、交互设计。但其实还有更多更好用的工具等待我们去发掘。对技术思维的了解，能够为产品经理提供更多更直观的工具去进行设计。例如：
类图（不需要太精确）能够替代名词定义，释清对象之间的联系。
　　用例能够帮忙厘清用户
，分解特性点，也能方便产品经理体验DEMO和进行sanity测试。
　　时序图能够帮助产品经理整理子系统
和外部系统的调用关系，估算成本、优化策略。
　　状态机能够让关键对象的状态以一种无比清晰的方式表达出来，让整个项目
的人一看就懂。
　　在面对稍微复杂的特性时，伪代码
能让产品更好地与研发沟通，梳理并发现问题。
　　最重要的是，以上这些工具的学习成本
　　2.对运算、通信
、存储等成本更加敏感
　　很多产品决策
其实是商业决策，网络通信是否快速、服务器能否HOLD住产品需要的计算能力，这些成本因素也可能决定着产品能否活下去。产品设计的策略可能对实现成本产生巨大的影响，产品经理需要懂得如何优化资源，用最聪明的方式去解决问题。
　　懂技术的产品，会对这些成本因素更加敏感。这样的产品经理需要对网络通信、数据结构
和算法有一定的知识积累，甚至会进行时间复杂度和空间复杂度方面的估算。
　　其实，这些因素也会影响用户体验
，特别是外部调用较多的场景。如何优化整个网络请求的时序、如何平衡同步和异步的流程、如何通过交互设计隐藏由于技术限制而产生的体验缺陷，这些决策都能大幅提高产品设计质量。我在做MIUI云名片，以及短信识别机票信息（在一个界面中使用了大量外部网络请求）时，对这点的感受非常强烈。
　　3.了解设计模式
　　基础的设计模式，如工厂
模式、单例、代理、适配器、观察者模式等等，我认为是产品经理的必修课，非常实用。了解这些设计模式，让我们能对产品的实现方式、难易程度和可扩展性有初步的估算。
　　然而设计模式这个主题更吸引我的，则是「N大设计原则」（有些地方描述为S.O.L.I.D五大原则，有些地方则是六大原则、七大原则、十大原则）。这些原则，甚至可以提升到哲学
层面，为各种生活决策、个人管理提供指导性的意见，在产品设计上甚至还有豁然开朗的感觉。
　　DRY原则告诉我们：「Don’tRepeatYourself.」
　　单一职责原则（SRP）说：「每一个类应该
专注于做一件事情。」
　　依赖倒置原则说：「抽象不应该依赖细节，细节应该依赖抽象；即针对接口编程，不要针对实现编程。」
　　又如开闭原则（OCP
）：「Openforextension,YetclosedforModification.」
　　而迪米特法则的那句「低耦合，高内聚」更是经典。
　　这些设计模式，都是经典。细细品味，妙趣横生。熟悉代码
的应该比较好理解，不熟悉的建议找本书来研读。
　　4.快速搭建原型的能力
总是紧缺的，而产品经理总想做新东西。掌握初级前端技术的产品即可快速搭建一个可用的原型，说不定这样就能拿到投资了呢？
　　而且浅尝前端技术也并不难，HTML
+CSS已经可以搞定大部分场景了，IOS和Android开发也并不难上手。而且现在的傻瓜式开发工具也越来越多了，入门门槛也越来越低。
　　5.能够更清晰地把握系统
　　工程师
最讨厌产品哪点？改需求、乱评估工期，还有就是：不懂重构等技术调整对产品的意义，明明很重要的事情，却一直分配不到优先级。
　　这是产品经理对技术的无知导致的。
　　随着业务的增长，产品在后台和运维层面都要经过一些调整才能更好地支持业务发展，这些事情包括但不限于：制造开发工具以缩短开发流程
、封装固定的业务流程以增加复用性、购买更多的带宽和服务器、优化性能、重构。
　　懂技术的产品经理能对系统的现状有一个大致的了解，并且在产品
以上技术调整时，能够提供合理的资源和优先级支持，更能够帮助统计和表达技术调整对业务的贡献，避免让有价值的事一直沉寂在后方。
　　——————
　　说了那么多，最后有一个问题：产品经理
懂技术，意味着需要自己会开发吗？
　　不是因为产品经理不应该
懂，而是因为今天的软件开发已经是一个巨大的工程：前端、后台、算法、运维等等，每一个环节单独提出来都是一整个团队的工作。没有哪个产品经理能够搞定这一切。我们所需要做的，是理解研发，并且帮助研发做得更好，减少沟通成本、提升业务效益。
　　至于有些人说的「技术思维
和产品思维难以转换」，其实我认为这是能力问题。你看人家ponyma，既是技术大牛，同时也能一秒钟变小白用户呢！
博客等级：
博客积分：0
博客访问：37,652
关注人气：0
荣誉徽章：您的位置：
产品经理到底要不要懂技术？
作者：佚名
　　[导读]我不是做产品的，只是对产品设计颇有兴趣，所以个人并不代表产品经理的立场;我是技术出身，但不热衷技术，所以也不能代表研发工程师的立场。我所说的可能会比较中立，也可能带有极强的个人偏见，不过我也只是个无知无畏的学生，所以十分乐意接受大家的指正。
　　PM(产品经理)VS RD(研发工程师)
　　常听业内人士说起，产品经理(PM) 和 研发工程师(RD) 之间是很喜欢互相掐架的(知乎上的讨论)，对个人而言感同身受，因为自己内心的技术小人和产品小人也是常常互相掐架的，感觉更像是一种是思维模式上的互掐。当然这并不代表这两种思维模式是相互对立的，好的产品显然不是掐出来的。PM 和 RD 之间需要的是一种建立在尊重和理解上的有效沟通。不过铺砖垒石的朴实研发工程师们还是比较倾向于被动的，所以我的建议是，产品经理主动去了解技术。&互联网的一些事&特推荐此文，希望大家认真探讨产品经理是否需要懂技术的问题。
　　为何 PM 要懂技术?
　　不得不说，技术人员是很傲娇的。PM 虽然并不是凌驾于 RD 之上的角色，但遵照着 PM 的设计来进行实现多多少少会让 RD 生出低人一等的感觉(不乏 PM 本身也是这么认为的)，这可能是让骄傲的技术流不爽的地方。所以 RD 不待见 PM 可以说是自然而然，如果 PM 还不懂技术，那么 RD 就更加可以在自己的长处上放心大胆地鄙视 PM 了。这倒也不是 RD 的小人得志，几年的技术经验会让他们觉得这更像是一种自我保护，保护自己引以为豪的知识领域不被非专业人员指手画脚。所以如果 PM 懂技术的话，是会在一定程度上赢得 RD 的尊重的。这么说似乎有点绕，说白了就是，如果我是 RD，我会更尊重懂技术的 PM。
　　与被&指点&的设计师不同的是研发很难被&指点&
　　懂技术解决的不仅仅是心理层面的问题，事实上，这会让 PM 和 RD 之间更容易交流。我们常常觉得 RD 出于对技术的自负而难以沟通，如果 RD 开始甩术语、甩原理，那么多耗费一些时间和耐心也还是能够理解的，有时候，更可怕的就是 PM 会觉得自己和 RD 的对话完全发生在两个次元里。其实 RD 们在这样交流的时候，并不是在企图彰显技术的 NB，这似乎更多的是一种习惯，是技术流长期和技术流交流所养成的习惯。所以，PM 懂技术，可以更好地去理解和适应这种习惯，至少也可以让自己不被 RD 们忽悠了，PM 如果被 RD 绕得云里雾里，无法反驳、无力判断，那也是一件很可怕的事情，如下面这个来自 xkcd 的漫画。
　　另外懂些技术可以把 PM 从高屋建瓴拉到脚踏实地。很多时候 RD 会消极配合 PM，很有可能是 PM 的设计在技术可行性上出现了问题或制造了麻烦。于是在 RD 看来，PM 就是天马行空不负责任的 YY，却把落实的各种不靠谱问题都抛给了他们。就好像建筑师不可能对土木工程毫无了解，PM 有时候也需要在技术层面上了解一砖一瓦是如何落实的，才能让设计变得踏实。
　　PM 也许可以不懂技术?
　　行文至此，也该中庸一下，其实 PM 懂技术，也未必是必须的，比如我个人内心的技术小人就会把这三种情况排除在外。
　　1. 这位 PM 有着非常成功的产品经验
　　技术流虽然骄傲，但也有着崇尚权威的谦卑。如果你有着非常辉煌的历史，即使你对技术一窍不通，但凭借着&PM 将再一次带领大家走向产品成功&的信念也足以令 RD 们信服。不过能够做到这种程度的 PM，不懂技术的应该是凤毛麟角吧。
　　2. 这位 PM 有着非常敏锐的产品直觉
　　如位 PM 有着非常敏锐的产品直觉，尤其对新技术可能带来的产品革新有着灵敏的感知的话也是被排除在外的。好的 sense 是能令其他人都跟着拍手叫好的，RD 再顽固，也是能够嗅到方向的，所以也会愿意跟着你的直觉走。不过，sense 这种东西，有时候跟天赋一样可遇而不可求。
　　3. 这位 PM 有着很强大的逻辑思维能力。
　　技术流都是逻辑控，如果你的设计出现了逻辑上漏洞或者问题，将会让 RD 们无比鄙夷，如果已经令 RD 们做了很多无用功，那更可能招致怨念。正是因为 RD 们对逻辑的执着与看重，PM 的逻辑思维能力就更加成为了一个巨大的考验。另外学习技术其实可以锻炼人的逻辑能力。当然，懂技术到逻辑强大，这不是充要条件。
　　说了这么多，倒也不是要标榜懂技术的种种好处，其实技术有时候反而会给设计思维带来限制。例如，PM 看产品可能首先考虑的是产品定位，而 RD 看产品首先想到的是功能。个人以前就很喜欢拿功能攒产品，做出来的东西基本不能称之为产品。这也许就是前面所说的思维模式上的差别。PM 的思维模式其实是很宝贵的，所以学习技术，还需慎重。
　　总而言之，PM 应该是懂些技术的，或许不需要懂到技术的细枝末节，但至少要有常识，再次也要对技术表现出尊重和热情。只有这样才有可能成为一个优秀的产品经理。
(转载请保留)
互联网的一些事，已超50万小伙伴关注！