产品经理是条狗
作为产品汪,撕逼技能就像Axure、墨刀、Xmind、PPT一样,是一项必备技能,跟技术撕简直就是家常便饭,而且还可能会跟运营撕、市场撕、设计撕、老板撕~总之,一切跟产品相关的人都可能成为你撕逼的对象,没办法,产品经理是产品的核心和owner,沟通中只要有不畅的地方,都避免不了一场撕逼大战。
今天和大家聊聊和程序猿撕逼的那些事儿!
撕逼四重境界
撕逼第一重:程序猿哥哥你好腻害,我就小小的反抗一下
大部分缺乏经验的产品经理以及性格偏软的产品经理会遇到的问题,甚至在一些技术主导型的公司,这样的现象更普遍,产品经理提出的观点论断甚至都没有程序猿提出的靠谱,就算产品经理内心有一些想法,提出来遭到程序猿反驳后,都没底气辩解,依靠小小的反抗刷下存在感。
撕逼第二重:需求评审拍桌子,需求变更扯嗓子
有点脾气,或者有些经验的产品经理,会想办法说服程序猿,我在上家公司做过,你这种技术观点不靠谱,我做这个做了3年了,我能不了解,你看看这数据,就应该这么改,我就需求变更一下,哪家公司上线前不变更需求啊?办公室就像菜场一样!
撕逼第三重:抄领导
你不听我是吧,我这个和老板过过了,邮件抄CEO,CTO,COO,CPO,CXO,产品总监,研发总监,来,我们进行不下去了,我们在邮件说吧,邮件里再来一场血雨腥风!领导也纳闷:玛德制杖!
撕逼第四重:拜拜~
女产品哭了,找产品总监提了离职报告。程序猿怒了,劳资不干了,你爱找谁找谁吧!同是打工者,相煎何太急!
撕起来了,产品狗该怎么办
一个负责任的产品经理不是为了撕逼而撕逼,都是为了解决问题而来的,既然都已经吵了起来,怎么才能稳住大家情绪,围绕核心问题展开激烈的讨论呢?
首要原则,请不要人身攻击!撕逼就是撕逼,请优雅的撕逼,别俗不可耐的一堆脏话出来了,你个傻逼,你这么low走后门进我们公司的吧。控制好你的情绪,你的那些所谓不经意间的口头禅都会伤人,这伤疤留下了,即可调解好了,日后也难以痊愈!
其次,对事不对人!我曾经遇到一个女PM需求评审时候,研发总是提出各种质疑,这个女PM脾气也大,直接来一句:你是不是看老娘不顺眼!完了,整个桌上的人都懵逼了,你在质疑人家的动机,你对人不对事儿,这评审会还怎么开下去!撕逼是为了解决问题,不是为了制造问题,单纯的程序猿人家就是逻辑性强,你逻辑有问题,自己没想好,还不允许人家提啊!有城府的程序猿别提了,想坑你,太容易了,分分钟让你成为背锅侠,没必要在需求评审时候卡着你!
第三,就事论事!产品经理经常遇到这样的质疑,研发问:你上次主导的产品害我们加班通宵,结果辛辛苦苦搞出来的的产品数据那么差,那这次我们还听你的?所以这个时候讨论的核心点就不是看产品需求本身是什么了,转而先确认要不要相信这只产品狗。但是话说回来,就算上一款产品失败,也不能论断该产品失败的原因就归结于产品汪的能力问题啊,有些只是为了验证老板的想法是错的罢了,这锅,不背!
第四,别老是拿权威说事儿!程序猿也总会质疑产品为啥要这么设计,你会说,看看京东,看看淘宝,看看微信等等,张小龙说过,XXXX,乔布斯说过,XXXX,李彦宏说过,XXXX。作为产品经理,还是要基于具体使用场景和用户需求进行讨论。毕竟,权威的话不一定适用于我们特定的产品以及讨论场景。
如何在程序猿间游刃有余
第一,不要抱着撕逼的心态
抱着撕逼心态的时候你的潜意识就是在别人对立面,反正人家说什么我都要辩驳,进了评审会议室,自动开启撕逼模式,容不得别人对自己的设计指手画脚,哪怕别人是对的。心态不对,基本上很难做好沟通工作,那么许多工作也会很难推进下去。
第二,想清楚你的需求是什么
在某个行业做互联网产品经理,不代表我们只需要懂产品设计,要把这个行业吃透,才能有更完整的信息和论据,得出来的结论才更可信。所以每次做需求前,最起码你要把需求本身的意义想清楚,你要有充分的论证,市场分析,竞品分析,运营数据,用研反馈,这些你要有逻辑的向程序猿们阐述清楚,让大家觉得我们不是在瞎做,我们是有目的的在做一些东西,大家做的不是无用功,最起码,我们产品是用心做了调研!就算是老板的需求,那么你也要问清楚需求是什么,为什么这么做,有没有什么市场前沿信息,老板的战略构想是怎样的等等
第三,评审前和技术充分沟通
产品经理在规划产品的时候要及时跟技术团队沟通技术上实现的可能性,开发可能耗费的工期,以及对目前技术架构的改动。一个懂技术的产品经理能够节省很多时间。每个技术团队的能力不一样,都有一个客观的边界,如果实现起来的困难很多,时间很长,那就需要产品经理对相应功能进行取舍或者变换一种设计形式。当然,如果你在平时交流过程中,结交了不少研发好朋友,多向他们讨教讨教聊聊需求,工作会事半功倍。
第四、完整的需求文档
只有你把你的需求文档想的细致想的全面甚至连一个错别字都没有,这样才不会在需求评审的时候不被喷,才不会撕逼。
1. 逻辑清晰你的整个需求当中,逻辑是不是清楚,整个流程能不能走完,页面跳转流程是不是正确,别一番走下来,流程上都有问题。
2.完善产品的异常流程和细节补充说明。很多产品经理的完成产品规划的时候,大致一看主流程。其实由很多异常流程没有想到。比如用户登录时候,什么时候出现图片验证码,用户手机号输入错误,密码输入错误怎么提示,你做个分享,icon,title和content有没有附上等等
3. 在PRD中建立note项,强调关键的东西别让研发遗漏,自己评审时候也能注意到,会后,研发也可以根据你的标注来理清思路,起到查漏补缺的效果。
第五、不要频繁变更需求。
需求文档确定以后就不要频繁变更需求。如果变化大的话意味着之前做的东西推倒重来,技术所做的成功付之东流。频繁的变更需求,会让研发人员不信任你,自然你的沟通也不会那么顺畅。所以产品经理为了不频繁变更需求,一定要在需求发出之前把所有的细节都想到,尤其是面对一个新的问题的时候不要急于做决定,你完全可以告诉研发,这个问题我现在有些想法,但是不完整。我在想想,尽快给你答复。一个迟来的完整的决定总比一个没有经过深思熟虑做出的决定好。
第六、产品经理参与到测试中去。
产品经理如果时间充裕可以和测试一起写test case,这样你就能发现自己有哪些没考虑到,和测试的test case比较,测试有哪些没考虑到,和测试一起测试,可以最快速的了解你这个产品的全貌,也许你做的只是APP的某个功能,但是你一起测试时候,有些关联功能会测到,几次测试下来,你对你的APP会有一个全貌的了解。
第七、产品上线后,适当的犒劳一下项目组。
一次产品的孵育,大家都经历了不少的辛酸和无奈,结束之后,大家完全可以吃吃喝喝,把酒言欢,起码研发会认为你这产品经理实在,大家在吃喝的氛围中培养一下友谊,大家以后会更愿意给你卖命。
最后再说几句大家不爱听的
1.埋头做事,也别忘抬头看看
2.别以为title里面有个manager,你就觉得自己是manager,manager和你无关
3.永远积极,乐观,正能量
-
#1
转载注明出处是对原创者的基本尊重掌握如何撕逼并没有卵用,这4个点让你和程序员好好沟通
刘飞产品经理,公众号:liufeinotes2016-09-171.7万7327
从零开始学运营,10年经验运营总监亲授,2天线下集训+1年在线学习,做个有竞争力的运营人。了解详情知乎上有人问「如何跟工程师优雅地撕逼?」,以下是我的回答。

说实话,除了在创业的时候经常跟工程师瞎闹、吵架,在其它公司但凡流程正规化一点,「撕逼」就是严禁出现的现象。就算是创业时候的「撕逼」,也只是因为比较熟而已。
很多人会从抽象概念上强调,真理是越辩越明的啊、只要在理就不怕撕啊、撕也是沟通的一种技巧啊等等。在我看来是有问题的。
我过去也是这种死工科男的思维,认为只要道理在,我就不怕吵到多狠,反正最后大家认理就行。
事实上这样是大有问题的。
如果是在双方平等的情况下,怎么吵架都没关系,更容易就事论事。但是产品经理和工程师的撕逼、吵架(或者说好听点,激烈的碰撞)是双方不平等的状态,前者更像甲方,后者是乙方。这样造成的局面就是:
产品经理吵赢了。工程师会觉得,有理就可以声高吗?有理就可以这么吼我吗?又不是你来写代码,我提出这些质疑不行吗?你何必这么趾高气扬? 工程师吵赢了。工程师会觉得,艹,你看你提需求这么不靠谱,想问题不周全,给我埋这么多坑,我以后还能不能信任你了? 两边都没吵赢,勉强达成了共识。工程师会觉得,你的道理都说服不了我,那你做产品经理有什么意义?还跟我这么吵,你这是什么态度?不管哪种情况,都会引起工程师非常负面的情绪。原因很简单,从本质上说,产品经理是想主意的,工程师是实现的。想主意的一点错漏、没想明白的地方,会给实现方造成巨大的麻烦;而如果想得很清楚、想得很明白,那是应该做的。
经常撕的话,会让工程师渐渐失去信任、也没有做好产品的动力。他写每行代码的时候,脑海里可能都会复现当时讨论功能时你狰狞得意的脸,这是件很恶心的事情。
我觉得撕逼不可取,但希望撕逼解决的一些问题其实仍然存在,在跟工程师的沟通中,解决这些问题的方式可能有这么几种:
1. 事前把方方面面想周全。
对产品经理来说,提的方案有明显的逻辑问题(比如前后矛盾、不合理、有明显错漏),那就占不了什么理,这也是会让工程师失去信任的最关键因素——你想不清楚就来跟我提需求,是不是不靠谱?
在我们需求评审时,一旦被工程师问住了,并且回答不出个所以然,我们就认为是产品经理的失职。这种情况我们认为是等同于开发的 bug,是产品经理的失误,要记录在案,不断复盘和鞭策自己。
如果方方面面想的足够周全,那所有工程师提出的「我不觉得这个有意义」或者「我认为这个没道理」的问题,都能用功能的业务背景和用户需求来解答——「实际场景下,用户会在 XXX 的时候用到 XXX,这是我们功能的初衷」或者「你觉得这个功能没有意义,但我们通过数据 / 调研 / 访谈观察到,用户确实有这个需求」。
「这个… 我也说不太清」「等我去跟 XXX 再确认下吧」「你说的没道理,你不懂」这些都是产品经理的禁用句式。
2. 塑造良好的沟通氛围
如果真的是想清楚了,那就跟工程师信息同步,让他也明白所有需求的背景和价值,不要反感;其次,像我刚刚说的,如果没想清楚,那就是产品经理的失职。错漏经常在所难免,但既然是产品经理不占理,那为什么一定要撕逼来解决?
在这种情况下,让工程师觉得,我们是竭尽全力在帮助他们更好地工作,而不是随便想了个点子、不负责任地提给了他们。对工程师,他们未必能知道我们也在冥思苦想、费劲心思地做功能设计,在他们看来,只要有几个漏洞和问题,就会想象出一副产品经理花天酒地不关心开发民生疾苦的画面。
一旦有了问题,要表现出「我们马上改」和「下次不会犯」的态度,这才能让工程师更信任。硬说「人都会犯错啊,你不是也会出 bug 嘛!还不高兴我们也出点问题嘛!」既不能挽回颜面,也不能挽回工程师的认可。
3. 了解技术背景
良好的沟通都是双向的。既然我们希望工程师能了解产品和业务背景,那么我们也应该了解技术背景。这也是「产品经理要不要懂技术」的解答。
对我们来说,未必要会写代码,但要知道他们所说的「做不了」和「很难做」是什么意思。他们没有耐心讲,我们也要有耐心学。这些知识掌握之后,能更有利于我们做出让他们更满意的方案,促进更好的沟通。
知彼知己,是最好的沟通方法。如果信息不对称,撕逼再多也没用;如果信息对称了,那为何还要撕逼?
4. 特殊的情况
还存在着一种特殊情况,就是某些工程师确实性格或者职业操守比较一般,会以各种借口做挡箭牌,习惯性跟产品经理撕逼,故意推延实现需求甚至刻意删减需求。这种是我认为的唯一能接受撕和吵架的场景。不过针对这种情况,最好的解决方案是反馈给他的上级,让上级来判断孰对孰错,同样不要指望撕逼能带来质的提升。
总结下来,就是对产品经理而言,尽量避免撕逼才是沟通的技巧,而掌握如何撕逼并没有卵用。
#专栏作家#
刘飞,微信公众号:刘言飞语,人人都是产品经理专栏作家。互联网产品经理,先后在锤子科技、嘟嘟美甲和点我吧任产品经理,知乎产品经理领域最佳回答者之一。豆瓣阅读《最好的时代》作者。
http://www.woshipm.com/zhichang/414839.html
-
Serenityblue 楼主#2
素以楼上乙方同学撕的论点是: 上撕不撕20180404