人人都是产品经理
需求评审篇
01
产品经理精心做了一个需求,组织大家参加。
产品经理:需求背景是这样的…..以前的解决方案是这样的……问题是这样的…..现在的方案是这样的……
开发:没问题啊,都能实现,不过我们得重构,一个月不够,得2月!
设计:我觉得你做的方案很不合理啊,XX流程特别不顺,XX页面的跳转很奇怪,XX页面的交互规则与我们现在的不一致……建议你改一遍之后再到我们这核对一次,最好做成高保真,带交互的那种。
运营:挺好的呢,不过我觉得XX页面的XX功能需要做的更突出一些,这可是我们的核心KPI呢!我已经想到了好几个美妙的运营方案,参考咪蒙、杜蕾斯和今日头条,保证能够让产品大红大紫的呢!
领导:咳咳,我也说几点。刚才想到了几个小想法,XX页面增加一个广告位,然后XX页面的做一个有趣的动画,用户一定喜欢,还有参与度,只做一个排行榜不够呀,不如我们做一个会员系统,不用太复杂,跟QQ差不多就行了,嗯…也可以引进一些礼物赞助商,用积分兑换礼品……
客服:听不懂,再讲一遍!
浅析:
事情总与你想的不一样,总有意外在发生。在工作中,每个人都有自己的立场,有不同的诉求,大多数的诉求其实没必要在意。如果有可能的话,召集大家一起开会之前,最好能跟这些部门一个个先过。慢,能成事。
02
产品经理带着需求参加排期会。
技术负责人:我们的开发能力有限,加上XX请假,下个版本只有20个人日,你们看着分配吧!
产品经理A:我的需求是公司之前定的核心战略规划,之前评估大概要5~8个人日就可以做完,我没其他要求了!
产品经理B:我的需求都是小需求,分分钟搞定,对于产品的体验有很大的提升,最多3个人日就能做完,先做我的吧!
产品经理C:各位,各位!我这边的客户每天玩命的打电话,你们又不是没看到,新功能做出来也不见得有人用,用户体验什么的什么时候做不行?先解决我的需求吧!周末我不休息做测试给大家节省时间好不好?
产品经理D:本来呢,我就不该说什么的,可是你们几位上个月也这么说的,我上个月的需求就没处理,这个月总得让我的需求先做了吧,技术老哥之前评估说5、6个工作日就够了,才占总工作日的四分之一,真的,拜托各位了!
产品总监:咳咳,各位都有苦衷,相互理解…..其实昨天公司高层战略会议,老板想出一个很好的方向,我们决定马上封闭开发10天出MVP……
技术负责人:嘿嘿嘿嘿…..
浅析:
这种情况往往发生在那些开发资源不足的大公司,于是产品经理还得跟产品经理撕,明知是错还要一错再错,另类的囚徒困境。这种情况,就需要领导能够制定明确的项目优先级,采用产品线分组的划分方式,可以有效的缓解这种情况。
设计篇
01
产品经理把原型发给了设计,2天后去看进度。
设计:呐,你看,半天就做完了。
产品经理:筱筱,指甲做的真漂亮,特符合你的气质……啊,这高保真怎么跟我的原型一模一样?
设计:哪里一模一样了,你的原型做的这么丑,都是黑白的,宽高像素都不对。
产品经理:我说的不是这个意思,原型没做排版,交互也没做,你看这个选项卡,其实有很多更好的方式,比如topbar……
设计:你原型设计成这个样子,我就做成这个样子啊,你自己怎么不想好!
产品经理:这不是因为你更专业吗,帮我做的好看点呗……
设计:少来这套,反正你原型是什么样,我就做成什么样,你要改,先去画原型,再重新排期,自己想不清楚还指望我给你做,你给我发工资呀!
产品经理内心OS:MD,我要是都做好了,要你干吗?上色吗?亏我还想照顾你的自由创意的心,原来都是白瞎!
浅析:
并不是所有设计师都心思敏捷,愿意动脑筋,他们乐意只做些重复低效的事情,安安心心的做美工。所以,不能一厢情愿地以为对她好,先去之前共事的人那里了解设计师的性情,然后区别对待吧。
02
产品经理把原型发给了设计,2天后去看进度。
产品经理:嗯…嗯?这个价格怎么字体这么小,还是黑色的?这个页面中最重要的就是这个价格了。
设计:我得照顾页面的视觉风格啊,我们的app是绿色、黑色的风格,搞一个红色,还这么大,特别难看。
产品经理:莹莹,你说的的确没错,可是价格是红色是常用的规范,你看京东、天猫都是这样,红色是扎眼,可是更突出啊!
设计:呵呵,红配绿,你什么审美啊!反正我觉得不好看,不改。
产品经理:呃,那我们上线之后看看效果,如果不好再换成红的看看好吧。字号调大点行吧。
设计:嗯,那就调大2个像素。
产品经理:太小了,至少再大一点吧!
设计:那就4个像素好了,还有这里的文案“温馨提示:使用微信支付可享受0.1~99元的随机立减优惠”,你没有说清楚!应该加上不大于支付金额的提示…
……2小时之后……
产品经理:天,我都干了什么,文档写不完了,今晚又得加班……
浅析:
遇到爱动脑筋,有审美,有体验意识的设计师,是产品经理的幸事,但让自己全程参与对方的工作,看起来是重视体验,其实并没有让设计师很好的独立思考,自己的时间也没能有效利用。多赋能给这样的设计师,有不同意见时,多用抽象的语言表达你的观点,让对方理解产品的思维,而不只是理解这一处为什么这么做。
开发篇
01
产品经理:本次的需求点是xxx和xxx,特别注意xxx….
开发:做不了。
产品经理:为什么,这个对用户很重要,已经有用户来投诉了。
开发:太麻烦,做不了。
产品经理:你是不是没理解我的意思啊,我也懂点技术,这个很简单的啊!
开发:反正我做不了,你行你来做啊!
浅析:
开发并不见得都懂得产品。而产品经理常常不能够理解他所提出的“小需求”其实很难实现,所以矛盾就出现了。我们应该细致的了解开发难点,有时候是需要牺牲一些功能与体验换取技术的简易。
当然,对于动不动就说“你行你来啊”的人,不管是不是开发,都是心智不成熟的人,有必要的话,向领导反映。
02
产品经理:本次的优化点是xxx和xxx,特别注意xxx…
开发:好的。
过了一周,产品经理去跟进进度。
产品经理:完成的怎么样了,过几天就该测试上线了。
开发:还说呢,你的逻辑有问题,漏掉了VIP的特殊逻辑处理!
产品经理:我看看……还真是……
开发:一定要想清楚啊,差点又给我挖坑了!还好第一天就发现了!
产品经理:嗯?那你怎么不找我?
开发:我很忙的,你得来主动找我好不好?你赶紧补充这部分的逻辑,排期要往后延迟一周。
产品经理:……
浅析:
一件事对不同的人来说,有不同的重要程度,也代表着不同的责任感。对于开发这种不主动提出、上报问题的情况,不可以随意就给该开发安插上“缺乏责任感”、“不主动”的帽子,作为开发需求的提出方,产品经理是主要负责人,在力求主动的情况下,应该及时跟进、推动。
03
产品经理:本次的优化点是xxx和xxx,特别注意xxx…
开发:好的。
过了一周,产品经理去跟进进度。
产品经理:完成的怎么样了,按计划过几天就该测试上线了。
开发:没问题。
产品经理:开发文档搞定了吗?
开发:这么简单的需求要什么开发文档,我们现在不是强调敏捷吗?能减少文档就减少文档。
产品经理:你说的好对,我竟无言以对。
又过了一周,产品经理去验收。
产品经理:怎么回事,逻辑不对啊?应该是这样的….
开发:啊?我可是照着你说的做的啊。
产品经理:怎么会呢,需求没改过,不信你看文档。
开发:现在不是强调敏捷吗,还看什么文档,当面沟通最有效。
产品经理:好吧,可我的确没有这么讲。
开发:我觉得这样更合理啊,我觉得用户也是这么想的,要不你改需求?
产品经理:我们事先做过调研,我前面的做法才是更符合用户预期的。
开发:我觉得这么做更合理,就这样吧,有问题你重新提需求吧。
浅析:
产品经理如果在刚开始就长篇累牍的阐述需求,开发听得浑浑噩噩,自我暗示说很简单的东西。笔者建议把话分几次讲,开发启动时将需求背景,解决方案大致流程,开发中强调流程,补充细节,有时候甚至要开发画流程给我们看,这样才更能保证开发对需求的理解。
如果开发还是有做的“不对”的地方,不要只是要求更正,问问开发是怎么想的,或许是产品经理自己想错了,这正是一个了解他人心智模型的好时机。
测试篇
01
开发:好,搞定了。我打包出来给你和QA测试吧!
产品经理:你自己测了没?
开发:这…应该问题不大,反正我测了你们还是不放心。
产品经理:好吧。
浅析:
开发总是对自己写的代码很有信心,觉得不会出现什么错误,但往往事与愿违,改BUG的时间比写代码时间还长。让开发自行检查,确保走通主流程再交付测试,是应当遵守的规定。
02
产品经理:刚测到了XXX的BUG,偶现,很严重。
开发:不可能!
产品经理:是真的,我亲眼看到,我还截了图。
开发:怎么可能!是网络的问题吧?你切换成4G再重现给我看!
产品经理:…好吧。
产品经理搬了个凳子,坐在开发旁边,开始刷。
产品经理:快看,BUG!
开发:哦,还真是。行吧,你就在这坐着我马上改完,你接着测。
浅析:
人对否定自己的人或事,第一反应往往是否认。而自己出错了之后,浪费其他人的时间帮自己找错误,又是另外一个错误。对于这种情况,笔者也没有什么办法,只有一句箴言:让别人测试。
运营篇
运营:我需要加个需求,是这样的…
产品经理:为什么呢?
运营:因为我们最近做了一个活动,有好几个用户提出的,对我们的KPI有帮助。
产品经理:这些用户是我们的核心用户吗,需求的强度大吗?频次高吗?
运营:你是产品还是我是产品?自己去调研啊。
产品经理:好吧。
运营:我这还有……
产品经理:太不合理了,什么样的用户才会有这样的需求啊!
运营:我把联系方式给你,你去调研吧。
产品经理:……好吧。
运营:最后一个需求,是这样的……
产品经理:太商业化了,会伤害用户体验。
运营:这关系到我们的KPI啊,觉得不好的用户肯定不是我们的核心用户。
产品经理:这……
运营:是不是得提需求啊,没问题,我让老大去找产品总监,排个期,老板对这次活动很看重!
产品经理:……
浅析:
运营缺乏对需求的甄别能力,一股脑的将需求捅给产品经理,这并不是坏事。笔者建议,面对提交的需求,不能简单口头描述,应该使用文档的方式,让需求方将需求详细描述,拿到需求后,需要做整理、归类,然后在定期开展评审会,来评审这些需求的优先级。
市场篇
01
产品经理:这次的新功能帮忙好好推一下,有用户反馈及时发给我!
市场:还来?不要推出新功能了好不好?之前做的优化,有许多客户都要求改回老版本!
产品经理:这个用户的需求是五花八门的,有人喜欢就有人不喜欢,我们是处于产品规划来的……
市场:什么规划部规划的,一天到晚不知道你们加班在忙些什么,我们之前提的功能都没做,还这么多BUG,我们在外面演示的时候经常遇到BUG,丢脸!
产品经理:是,您说的对。但是我们现在的排期确实很紧,而且你们的那些需求很多都不合理…BUG是一直在改的。
市场:这个新功能我也不会用,你要想收集反馈,跟我一起去拜访客户,外面30多度,我们一天跑10个客户,没问题吧?还有,真的别这么快发版了,2个月发一次行不?用户根本不想更新我们的app!
浅析:
很多产品经理认为市场部分是为产品服务的,而市场人员想的恰恰相反。想要获得用户的新反馈,而旧的反馈却迟迟没有解决,市场人员却也同样觉得做一个月才改改BUG,上一两个页面的产品技术工作不到位,所以争执在所难免。笔者建议,对于市场人员的产品宣讲会必不可少,他们是离用户最近的人。而产品更新,以及此前的问题反馈,应该有规律的定期给市场人员以及用户结果。
还有就是,产品经理往往以为产品迭代速度越快,用户越开心。但事情往往跟你想的不一样,用户只用你的核心功能,产品更新他可能会不胜其烦,所以没必要的话,不要提示用户更新版本。
老板篇
01
老板:我想到一个绝妙的主意,我们在app内做公众号怎么样?邀请商家入驻,以后收费!
产品经理:可是我们是做计时器的呀,增加商家入驻,一是……二是……三是……四是……
老板:但是你想过没,存在这样的场景……用户需要商家服务啊!
产品经理:您说的这个场景也太不合理了吧,用户可以使用XX应用来满足,用户没有在我们的应用里实现这个需求的预期…
老板:所以才是超出预期的体验啊,你这动手开发,我让市场部去找合作,下个月上线!小步快跑,快速迭代!
产品经理:可是……
老板:小王,你的思维太受限制了,产品经理更要有互联网思维,想别人不敢想,颠覆式创新!
产品经理:……
浅析:
老板不懂产品,甚至不懂商业,却学了一大堆时髦术语,整天念叨。提出一大堆不靠谱的需求,还随时想要教育想要跟他据理力争的产品经理。不过这种老板脑袋里可能都被这些高大上的专业术语给洗脑了,忘性大,产品经理口头答应着,过段时间老板可能就忘记了。如果他没忘,你又不想做这些垃圾需求以免遗臭万年,出门左拐招聘网站。
02
老板:我有个紧急的需求,赶紧来我办公室一趟。
产品经理:来了!
老板:我们原来的积分排行榜可以显示并列排名前100名的,这里需要优化。
产品经理:是的,只显示前50名,自己的名次及跟上一名的差距就够了……
老板:不是啊,我们现在的积分很多人玩,我想100名实在太少了,我自己是525名,我也想出现在排行榜上。
产品经理:嗯?您的意思是?
老板:显示前1000名,含并列。
产品经理:啊?并列的前1000名,那这个名单得有3000条了,如果我的排名是900名,那么一秒钟刷50名的话,我得刷接近50秒?谁会这么干呢?
老板:这就是你不懂用户心理了吧,我是525名,我就愿意从第一名刷到525名,看看我前面都是哪些人……
产品经理:用户又不认识其他用户,给他看这个有用吗,如果还一个个找名字,看一个榜单就要几个小时啊,而且得多费流量,我觉得这个很不合理。
老板:不是,多长时间我都愿意翻。
产品经理:您是您,不代表全部用户,我们现在每天进入到榜单页面的用户不到活跃用户的2%…
老板:那是因为之前只显示前100名,现在显示1000名,不就变成20%了吗?
产品经理:可是……
老板:我就喜欢翻啊,我就喜欢这个功能啊!
产品经理:……
浅析:
老板总是爱琢磨产品,想出一大堆稀奇古怪的需求,然后煞有其事的找产品经理研究。你跟他讲数据,他跟你讲逻辑;你跟他讲逻辑,他跟你讲场景;你跟他讲场景,他跟你讲情怀;你跟他讲情怀,他跟你讲他喜欢。得,你闭嘴吧。
03
老板:这个需求你来跟进,看怎么设计才好。
产品经理:好的。
老板:这个项目开发上线,你来跟进。
产品经理:好的。
老板:下一个要上线一个活动,你要盯紧参与人数和付费转化。
产品经理:……好的。
老板:产品需要有长期战略规划,你去做出来发给我看。
产品经理:……我尽力。
老板:市场部分明天开一场线下的产品宣传会,你去支援一下,用户有不懂的地方,做一下讲解,顺便帮忙布置一下易拉宝、海报之类的。
产品经理:……OK。
老板:新版本上线了,这次功能有点负责,客服那边人手不够,你去充当下客服,顺便了解用户需求。
产品经理:……嗯。
老板:这次的合作总算完成了,你去催一下合同的事情,跟法务审核完了,把合同寄给对方,要用EMS,这样专业,记得找财务报销。
产品经理:???我学学。
老板:到点吃饭了,你帮我点个外卖,顺便把饮水机的水给换了。
产品经理:……
浅析:
不少产品经理说自己就是个打杂的,诚然。浪费时间去做这些简单、低效的事情,对于产品经理来说,是一种折磨。笔者建议,不要忍气吞声,跟领导讲清楚,会得到谅解的,如果没有效果,短期内也不会得到缓解,一样出门左转招聘网站。
其他篇
01
产品经理今年快35岁了,任资深产品经理。
产品总监:下一个我们要开融资发布会,在此之前的这个版本一定要保证准点上线。
年轻产品经理A:好的,我会督促开发加班,保证完成任务。
年轻产品经理B:我觉得有必要培训一下市场和客服同事,这事我会加班完成。
年轻产品经理C:最近我在下班的时候参考了一些国外的竞品,还参加了一些同行聚会,觉得有些地方做的很好,待会我发给大家看看。
产品总监:嗯,很好。老王,你有什么计划?
产品经理:嗯,我提升效率,争取在下班前完成所有工作,孩子外婆住院,我老婆去陪床了,我得早点下班接女儿放学,大家放心我不会耽误进度的……
浅析:
随着年龄的增长,家庭事业都越发忙碌,大龄产品经理也没能升职为相对清闲的管理岗,这时候压力巨大,精力体力也比不上年轻的产品经理,焦虑倍增。
02
产品经理回家过年,去亲戚邻居家里拜年。
七大姑:哎呦,狗蛋儿成熟了,做什么工作呢?
产品经理:互联网产品经理。
七大姑:才工作没多久就做经理了呀,真有出息!下面管多少人?
产品经理:姑,这个是岗位名称,不是真的经理,我们都是项目制,一个项目十个人左右……
七大姑:哦,那是不是跟那些卖房子的小员工都叫客户经理一样?
产品经理:这俩不太一样……
八大姨:他姑,对孩子这么高要求干嘛,也都不能跟你们家孩子似得,现在都是20人的包工头了,人各有志嘛。
七大姑:我说觉得狗蛋儿从小聪明,有出息,刚好大姑家的电脑屏幕坏了,狗蛋儿你帮我看看……
产品经理:……行,姑,我回头给您找人修,我还有事,先走了。
浅析:
这是个大家熟知的段子,对于亲戚朋友,解释自己的职业确实不易,希望产品经理这个岗位早晚有一天跟老板、CEO一样被人们所熟知。
03
业内人士聚会。
产品经理A:我是TX的,参与过安全卫士、视频的产品工作,现在在做云,业务推进不错。
产品经理B:我现在出来创业了,原来在F萌,全程参与了立项到爆火,后来我走了,F萌也不行了,可惜……
产品经理C:我在创业公司,负责的模块月复合增长率100%,大家应该听说过,叫硬克。
产品经理:不好意思,我出去接个电话。
浅析:
绝大多数的产品经理能力不足,气运不佳,数年工作下来,依然没有拿得出手的成绩,随着年龄的增长,这种焦虑与日俱增。笔者认为,没有成绩这事情既然是事实,那也没什么不好意思的,兵法有云:兵者,道、天、地、将、法。产品的失败并不一定代表着产品经理的失败。我们只需潜心修炼,等待时机,一展才华。
需求分析
从用户提出的需求出发,找到用户内心真正的渴望,再转化为产品需
求的过程。
挖掘客户真正的需求
----------------------------------------------
有的用户很“危险”,在提意见的同时还说你们应该做成什么样子,这时候一定要头脑清醒了,
用户提的解决方案往往是站在自己的立场上的考虑的。比如对
“快递单打印”的功能,用户提出要添加一个他经常用的小快递公司的快递单模板,
而我们会发现,这家快递公司可能只是一个区域性的快递,最终的解决方案是做了一
个“自定义快递单”的功能。
有时候,用户给出的做法存在明显的逻辑矛盾,就算他给出的解决方案合理,也
要再深挖用户内心根本的需求,比如用户描述“新建非支付宝交易订单的时候必须要
选择用户不合理,希望能自己填写客户”。这里更深层的需求就可能是他需要把线下客
户也管理起来,所以我们或许更应该做一个新增线下客户的功能,而不是在新建非支
付宝交易的时候让用户自己填写客户姓名。
------------------------------------------------
小明说要吃猪骨头火锅(用户需求),80 块吧,但没想到又碰到
了大毛。
“真的想吃?”
“想吃!”
“为什么?”
“我饿了……”(找到了本质!)
“哦,这里是两个馒头(产品需求),请你吃,才1 块钱。”
“……”
------------------------------
这个阶段收集到的需求都是比较粗的,测试更多的可以从系统验证的角度考虑问题,即这些粗的需求如果实现后,后期交给客户时,是否可验收,有哪些验收场景、验收的思路是什么、具体的商用使用场景、需求验收是否需要特殊的验证平台、有哪些验收难点等等。可以输出《需求验收分析报告》(我们的story)
改进
小范围发布,后大范围(目前很多已经采用这种模式,)
数据的分析
平时应该对数据进行分析,做决策时,才能派上用场
对需求的要求
11.who why when or where