从技术角度看,很多产品都会犯这7个错误
之前的经历只能代表过去,而你未来的行为才能决定你在这条路上你能走多远。
私下不断学习,不论线上公开课或是线下课程以及相关书籍,总在不断汲取前人的谆谆教诲。网上很多人都说“什么都不会的都去做了PM”,“PM门槛低”,作为一个无时无刻不跟PM打交道的我来说,深有感触。但是我个人认为:之前的经历只能代表过去,而你未来的行为才能决定你在这条路上你能走多远。至于到底是从哪个行业转过来的,大可不必介怀;持续的学习及自省才能保证你在这条路上越走越宽。
好了,进入正题,谈谈我遇到的一些产品经理(画图经理),也算时刻警醒自己,避免未来犯些同样的问题;
1、借鉴(不动脑!)
常用口头语,“别人怎么怎么样”,“他们就是这么做的”,“按照这个做就行”这应该是很多产品经理都做过的事情。借鉴跟抄袭完全是两码事,没有结合自身的业务及产品定位就一味地生搬硬套这是不动脑!根据自身业务模式,产品定位,使用场景,用户受众而有选择性的模仿这是借鉴。
曾经做过一个O2O项目是关于卖酒的,老板(老板是最大的PM)来一句:按E代驾那样做,主打一键叫酒功能,不管在哪随时随地可以买酒。模式很创新,但是这界面跟他们一样真的好么?还有,喝酒的场景,一般是小饭馆、饭店、酒吧、KTV或家里,但是饭店、酒吧、KTV之类的一般是不允许自带酒水。产品的定位都是进口酒,消费用户又是那种相对经济能力稍好的,所以尽管这个模式很创新但是细想,按照这个模式做可能并不一定很好。
2、不做用户研究
不知道用户真正想要的是什么!,单纯为了画图而画图,俗称画图经理!
老板:“这个应该不错,咱们可以尝试一下,小张啊,你做个原型出来我看看”。
小张:“嗯,那个…功能?”。
老板:“你看下其他App怎么做的么”。
小张:“额…好嘞”。
。。。。。。一个星期过去了
小张:“老板,你看一下,原型做出来了”。
老板:“嗯!可以,可以…对了,那个地方这么做不对啊,你看看那什么什么怎么做的啊,把这个地方在改改”。
小张:“嗯,好的”。
。。。。。一个星期又过去了,接着。。。。。。苦逼的开发开始了。。。。
这种情况应该是比较常见的,老板下需求、运营或者PM去执行,最后交给开发,然后再循环往复。但是产品经理很少去研究用户,也不动脑去哪找到目标用户去研究。
例如:我们现在做的是一个家装类产品,我们的客服是跟客户打交道最频繁的人,每天都需要电话回访用户,但是没有人跟客服说或者系统的培训下,让其在回访用户过程中有意识的记录下用户比较关心的问题;以及APP里客服系统的历史聊天记录,做些分析及总结。这些都是很好的采集用户关心的问题及需求的地方,但是却没有人做,我觉得这就是没有真正的思考。做好了原型,交给开发,最后上线,万事大吉!
哦,对了,忘了PM的一个很重要的职责(把控用户体验),在这一过程中,总时不时的跟我们说,“怎么能这么做呢,用户体验不行的”,张口闭口谈他所认为的用户体验!!!(我真的很想打你,你知道么)
3、考虑不全面,逻辑都不通,开发效率低下
这逻辑不通啊,这没网咋办啊,这里要是没数据咋显示啊。这种情况下,文案写什么啊。
这种情况也经常出现,虽说智者千虑,必有一失,但您这失的频率也忒高了点吧?
没有流程图,单纯的画产品原型,哪怕你是创业团队,时间有限,没有功夫画流程图,那您也得自己好好把整个流程过个几遍吧?看看哪里有遗漏缺失什么的。
4、不经常把玩自家产品
我始终认为(最基本的好么!)自己的产品一定要多用,只有这样才能发现一些不易发觉的问题。
我因为开发的原因所以总无法避免的要天天面对它,就因为这样我总能看到一些PM发现不到的问题及可优化的地方。如果一个技术对产品的了解甚于PM,想让技术尊重你?咱们还是谈谈特朗普当选的问题吧。
5、产品没规划及对整体的把控、后期跟踪不到位!
产品上线就结束了,没有后续的版本规划,老板说后期做什么后面就做什么没有自己的一点想法。说白了就是对所处行业了解的不够透彻,产品后续的走向不知该如何把握,只能单纯做一些执行方面的工作(画原型);产品开发期间进度很少过问,跟踪不够及时。
虽说项目进度是项目经理的工作,但是实际情况是很多公司都不是没有项目经理的,所以做为PM这块是一定要抓起来的,整合各方资源为你所用,将项目顺利往下推进。
6、任何决策都没有数据的支持,说服不了别人!
很多PM吐槽,技术老跟自己作对,交流不顺畅,工作难以推进,总跟自己撕逼。身为技术的我,在做一个产品及功能的时候也是需要认同感的好么?每当接到一个SB需求,我内心是很反感的,不好意思,就是不想给你做!下次请用数据说服我。
我接触不少PM确实如此,有的连埋点都不知道,更别提什么数据分析了,不做统计工作,你到底是依据什么做的产品优化及迭代,大神,请教教我好么!
7、不反思!!!
古人有云:“吾日三省吾身”。
不求一日三省,好歹一个版本你省一次可好。
“什么这你都懒得省了”…..
他们自己私下到底有没有反思总结我不知道,但是起码从之后的工作中可以发现,即使是反思总结了,也基本没什么效果。好的产品是需要不断打磨的,这就需要我们不断的反思及总结,在过往的工作及版本中出现过什么问题以便在日后的工作中不在发生同样的问题。
最后最后想说的就是不断的学习,互联网发展太快,智能机的兴起掀起一股移动互联网大浪潮,在以后的未来几年谁又会知道会发生些什么呢,我们应时刻抱有一种危机意识,不停的奔跑,即意识上危机,行为上积极。
人无远虑,必有近忧。
谨记谨记。
本文由 @夏祥全 原创发布于人人都是产品经理。未经许可,禁止转载。
非技术出身产品经理的技术沟通秘籍!15天补齐程序/代码、前端、后端、数据库4大模块基础技术知识。
详情戳>http://996.pm/7daXE 或咨询起点学院蘑菇(wx:qdxymg)
楼主果然是资深的开发,应该是架构师级别的了吧。。本人小白想问个事,如果接手一个产品,一看就知道差的不行的。还需要做那些分析什么的么,比如UI很差,还是90年代的拟物化,我就不可以通过我自己经验做优化?有必要做数据分析和调研么。。当一个需求一年了还没做出来那还需要用户调研么?还需要收集客服的用户反馈么?大神,知道为啥PM越来越没脑子么?一个简单的需求点评估时间30人天,90人天的,你感觉这个需求能推进下去?要不就加人,要不就不要做的这么炫,只有这两个办法。所以,一边开发,一边老板,逼的PM能动脑子么?动脑子的东西做不出来有什么用?什么是逻辑不通?我看你的举例,这些逻辑不通我这个小白感觉这不是问题。。比如断网情况,消息提示框提示网络错误,这是最简单的东西了吧,难度开发就没脑子?当产品出来了,主要需求功能点都有了才做用户体验,会提示主人,我感受不到网络啦。这类的等等。额,个人看法,当需求一砍再砍的时候,像您这种开发大神就会说这些没用,那些没用,这些做了带来什么?如果做就1个星期,人工工资多少钱?做这个功能值当不值当?哎。。然后砍砍砍,到最后逻辑根本不通,好多小问题。然后就会说,你看看你做的方案,这不行那不行,什么都没考虑到。对此,我只想说要不要把第一版方案拍你脸上?
楼主写的没错啊,这些都是产品经理的通病啊。
一开始就是小白,没有一点营销、市场经验,基本都存在这些问题。
作为一个刚入行没有一点经验的产品来说,出现以上问题很正常,而这些是我这些年做开发过程中,遇到的一些产品普遍存在的问题,不乏有工作一两年的经验的人。而作为一个有经验的产品来说,以上的错误将使你在不论是技术、设计还是运营的心里其专业性都会大打折扣,长此以往,你以后所做的任何决策,他们都会抱有质疑。至于砍需求或是多报工期这是每个产品都会遇到的问题,不论大神还是小白,即使一个功能一个星期能做完,开发也会给自己预留几天,因为这期间不知道会出现什么问题,导致实际工期延误,还有特别想说明的一点是,有些功能产品看着可能感觉简单,“那个什么什么不都有这个功能么。。。”作为开发真的非常非常厌恶这种话,你看百度简单么,就一个搜索框,但是你要考虑后面的整个逻辑。— 砍需求,时间不允许的情况下,这是必须的,但是,产品要把握一个原则就是,主要功能不能砍,酷炫动画,以后可以迭代加(微信有酷炫的动画么?这不是吸引用户的重点)。至于你说什么逻辑不通,这不是问题,开发就没脑子?开发的脑子都放在写代码上面了,OK。所有的异常状况,及异常状况的页面怎么显示,文案是什么,异常状况下页面需要重新加载,加载方式?下拉?点击屏幕?还是怎么样?上述这些都是一些细节性的东西,也是比较基本的这些如果都出问题,那以后的工作将更难往下推进。
本人并没有不赞同你说的,只是根据不同城市背景,不同环境,所面对的不一样,像本人4线城市唯一一家互联网公司,你能想象技术有多难招?技术的话语权是多重?所以针对本人这种情况下,你所说的这些错误根本不是错误。如果不存在这些错误的话公司是承受不住的,是要考虑成本的。而且砍需求方面本人对PHP、JAVA也略懂一些,我需要实现一个功能时,我是考虑进去的,不是说“那个什么什么不都有么”。我认为这个功能实现需要1周时间,开发考虑实际情况如果需要1周半,2周,我都能接受,但是一评估,1个月。我能接受,老板能接受?不接受怎么办?砍!我没有说逻辑不同是开发的问题,我是按照你的举例,网络错误下是怎么样。最起码,我做的东西考虑不到的地方很多,沟通解决。和运维同学一起论证。但是逻辑不通的情况只有在不断砍需求以后才会出现。当老板不听你说的,就要把核心砍掉,你知道有多无奈么。开发会说:我不管,那是你们的事,就给我需求我就按需求做。跟开发搞好关系的代价是需求根本不会按照理想做。我就想问,是做事的还是搞关系的?当给开发好好说话的时候他会认为你对你的东西没底,是求他干活的。反正在我们这边不撕逼根本推进不下去。我基本不话图,不写PRD,当初有个方案点击某个按钮进入该频道,点击该频道内个人中心检测登录状态。生生的做成了点击按钮就检测登录。告诉我他理解的是这样,技术部门40多人,就开发主管是这么理解,他下面的开发就按他的理解做。额,说的有点多了。总结回复:你说的这几个错误并不是从技术角度看产品,而且从你的角度看产品。环境不同,单位性质不同,很多产品是必须要按照你所谓的这些错误做。多说一句,开发像厨子,产品像服务员,需求方像顾客,你一个厨子了解服务员么?就像同样不了解厨子,服务员只能这菜好吃不好吃,但是你厨子知道服务员需要怎么和顾客对接,怎么像主管,老板报告?你认为的是仅仅点个菜传个餐。
提升专业性,并且跟开发搞好关系,对于以后工作的推进,将大有益处。
永远不要小看调研的力量…只有考虑全面才能说服技术和老板你的需求多么有价值,那时候将不再是需求被砍,而是将需求分步骤按优先级开发~所有人都会配合你的~所以,永远不要小看调研的力量! 说几句题外话,跟老板和技术汇报需求的时候,主打的点可能不一样,这就需要PM不仅要分析用户还要分析你汇报的对象,比如对于老板你可能要强调你的需求可以为公司带来怎样的利益,对于技术你的需求可以解决什么问题会用到什么前沿技术,多跟他们聊聊产品聊聊理想,工程师们都希望自己有一天能变成技术大牛而不是写代码的~所以你看,一个看似简单的汇报需求就需要调研好多东西呢~ 一起加油!
非常赞同
像我这种新手产品就有这种问题,有的逻辑走不通,唉,还是需要多学习啊
同感,被技术鄙视的不要不要的
特别是那句:“这个你们产品要考虑清楚啊。。。”,一万点暴击啊
都是有一个过程的,多交流,多学习。
恩,同意~