快生活 - 生活常识大全

高级产品经理的条工作原则从立项到完成的工作流程


  秩序从混乱中产生了出来。——弥尔顿
  本文记录笔者总结的工作原则27则,涵盖了一个业务/需求从评估,到立项、策划设计、沟通协作,直到完成的整个流程,每天进入工作前默读两遍,用以警示自己,希望对你有启发。
  评估
  最重要的是信息。
  01:
  产品经理:咦?我感觉B活动更适合下周的新年活动啊。   运营:A活动要明显优于B活动,你看昨天我们做了A活动,参与用户比B活动的人数多了2倍!   真相——昨天是圣诞节,活跃用户数量达到20万,是平时的5倍,而B活动是2个月前日活2万的时候做的。A活动的参与率只有B活动的20%。   原则:不要轻易相信,要收集更多信息再做判断   对于产品经理来说,做判断是要比做原型、写文档、跟项目都要重要的事情,而做出好的判断的必要前提是:要掌握足够充分的信息。   02:
  需求方:我们的超市今年又再创佳绩!但是无人便利店恐怕会在未来威胁到我们。   产品经理:呵呵,防盗怎么办?无人便利店绝对开不起来!   真相——亚马逊、阿里巴巴还有国内的数十家无人便利店企业拔地而起,发展迅猛。   原则:接纳未知,不轻言否定   作为一个有着常识,基本逻辑的人,面对那些跳脱常识的观点,不免第一反应就是"不可能"。然而世事如风云,变幻莫测,不可能在以以往想象不到的速度变成现实。   03:
  产品经理:我们新推出的功能您觉得怎么样,是不是解决了您的问题?好用吗?   用户:嗯嗯。   真相——用户数据完全没有上涨,很快竞争对手推出了另一种解决方案,大受欢迎。   原则:做一个冷眼看客   观察,应该尽量不要影响到事物原本的样子,如果带这主观情绪去询问用户,那么用户很可能会迎合你的情绪;如果亲身跟进到流程中去,那么流程中的人和事可能会发生变形。   04:
  用户:我觉得你们这个特别不好用,因为我经常……   产品经理:嗯,我们现在做了优化,在新版本里我们做了A,B,C,D…   用户:可是我还是觉得不好用啊!   产品经理:怎么会呢?那一定是您不会用,我来教您……   真相——用户之所以认为不好用,其实他是想实现另外一个类似的需求,而现在的解决方案并没有注意到那个新需求。   原则:倾听   记住,在现阶段,你的目的是了解用户的需求,而不是去解决某个用户的问题,更不要急迫地想要让用户爱上你的产品。   05:
  客户:新版本没有满足我的需求!   产品经理:怎么会呢,我可是按照需求评审会上你的要求做的!   真相——当初客户举例说要在线协调100人,产品经理就真的做成了最大100人的网络,可是客户实际上偶尔也会有协调好几千人的需求。   原则:多想,多问   在需求没有得到最终认可之前,每一个细节都有可能隐藏着陷阱和机遇,因此你需要事事留意,多想多问,不要把它当成一件苦差,因为它完全可以升华意义。   立项   精益求精。   06:
  老板:我发现有很多客户对海外品牌很有兴趣,而那些做代购的良莠不齐,正是我们的好机会!   产品经理:是的呢。   真相——海外建仓,加关税,还要另外搭建新的供应链、库存管理、客服系统导致实现周期极长,而且利润率大大低于代购。   原则:做投入产出分析   信息足够丰富的情况下,经验丰富的产品经理,应该能够对业务实现的投入产出进行大致判断,如果做的仅仅是一件"65+50=70"的事情,那么就应该好好考虑了。   07:
  运营:你不能因为你不喜欢,就不做这个功能,这对公司来说非常重要。   产品经理:好吧,但是我真的不喜欢这种做法。   真相——产品经理曾经看过类似的失败案例,但是已经不记得了,只是潜意识在让他抗拒这个做法,最终该功能也因为上线后出现了一些用户的不满,因此被产品经理当做借口下掉了。   原则:不做让自己不高兴的事   所有的理性分析,都离不开情感。   我们常说的产品感,就像是救生员的救生直觉,艺术家口中的灵光乍现,其实是平时积累的东西,在潜意识的呈现,如果你经验足够丰富,遇到一件让人极不舒服的事件,那很有可能你是对的。   如果你已经完全理解了原理,还是单纯地不喜欢它,那么将它转交给其他人吧,它有可能会因为你的喜好而被冷落。   08:
  老板:我觉得微信的会员卡功能很好,我们也有这么多的用户,照抄一个微信的吧!   产品经理:好的,我觉得我们应该在个人中心增加一个入口,采用……   真相——老板做会员卡的目的只是想让用户了解自己的权限,问题在于当前的用户对特权的感知不强,老板认为用户有了会员卡之后就会仔细研究权限。   原则:先考虑能不能不做   当我们接触到一个新的业务/需求时,怎么才能考虑的更清楚呢?如果仅仅是去考虑它如何实现,实现之后带来的好处,那就相当于一开始就为自己准备了一个狭小的套子,最终也往往是狭隘的。   考虑不做,能够让自己的思考范围从"做"的极端到"不做"的极端,因此思考的可能性就更多。   09:
  老板:XX直播的形式很好,我们也需要用户更强的互动,我们也能够做直播吧?   开发:是的,我们能够做的。   产品经理:好的,我也就安排。   真相——公司是做共享充电宝的,用户到app上唯一理由是没电了充电,用完即走。   原则:应该做,而不是可以做   其实不仅仅是在需求,因为"可以做"而盲目去做的人随处可见。笔者就因为会做数据分析,会做测试,会写文案,而被老板、同事理直气壮的要求各种打杂。   放大到业务/需求上,做了不应该做但是可以做的事情,不仅事倍功半,甚至可能会带来用户认知的丧失,给产品带来致命打击。   10:
  运营:我们需要一个第二件半价的营销活动。   产品经理:好的,第一件原价,第二件五折,下周实现。   真相——运营在接下来的日子里又提出了第二件6折、买二送一、满100减10等等活动,产品开发每次都临时开发,运营、开发相互抱怨,苦不堪言。   原则:解决一类事,而不是一件事   很多人在去解决一件事的时候,真的就是在解决这么一件事,下一次哪怕只有少许改动,他们也会从头开始再来一遍,更可悲的是,自始至终他们都没有发现这些事情很类似,如果把这类事的原理告知他们,他们也能够想到解决方案,可惜他们就是不能发现。   这其实就要求产品经理具有较强的抽象分析能力,能够理解到事物的本质,一次性解决类似的事情。如果只是一件,一件的去解决,不仅效率低下,也会让人丧失成就感,终日重复着简单、低效的工作。   策划&设计   不仅仅是解决方案。   11:
  市场:这个需求对我们来说很重要,希望尽快实现!   产品经理:好的,我们会按照精益思路,先做用户访谈,然后设计MVP,再灰度发布……   市场:???听不懂,反正尽快上线就好了!   真相——需求本身的确对用户来说是有用的,但是市场主要是想要有相关的宣传物料给他们做市场拓展,顺便提升下自己的业绩,对于这个功能最终实现的效果如何,市场根本不关心。   原则:了解需求,也了解关键人的诉求   许多时候,业务部门会跟产品开发对立,抱怨产品开发不能体谅他们,而产品开发也振振有词的表示为用户考虑。但或许并不冲突,处理需求的时候也站在需求人的立场,思考"为什么是他提需求?","需求满足后对他会有什么好处",这样我们在处理需求时也能够更好的把握需求的实现顺序。   12:
  开发:我们的新后台打通了A系统和B系统!   产品经理:那太好了,我们可以将麻烦的X后台迁移到新后台!   真相——麻烦的X后台的主要目的就是为了联系A、B系统,而现在这件事已经被新后台做了,X后台已经没有存在的必要。   原则:牢记目的,反复零秒思考   当我们深入细节,往往会忘记初衷,把注意力集中在一个个细分的点上,甚至问题已经不存在了,我们还醉心于研究解决方案中的细节。   零秒思考,是日本麦肯锡合作人赤羽雄二发明的一种思考方法,它可以让你自由翱翔在自己的思绪,去深入思考问题的方方面面,这是我常用的思考方法,推荐了解。   13:
  需求方:我要的商务合作的页面做好了吗?   产品经理:嗯,已经加入了排期。不过我想了想,既然做了商务合作,那么对用户也不能吝啬,所以我准备做意见反馈,但是有些简单问题让用户等待实在是体验太差了,所以我研究了一下在线客服系统,还挺好的,可以接入。产品要成长,所以我们要鼓励用户反馈,因此要用积分奖励他,我准备做个积分系统,顺便做个有吸引力的用户等级……   结果——产品经理将这些需求提出来,市场表示他们只需要商务合作,运营表示没资金准备积分奖励,开发表示没时间,客服表示听不懂,老板表示产品经理可以去财务那结下薪水。   原则:保持专注   产品经理常常以脑洞大自傲,但想太多也有可能意味着难以专注,做一个业务/需求,总是患得患失,思绪万千,其实这很有可能是目标不清晰,逻辑混乱的表现。我们要尽量以全局视角观察业务/需求,明确它的目的、职责,保持专注。   14:
  需求方:用户扫描领取会员卡的需求做好没有,急着用!   产品经理:还不行,H5的图做的没有体现我们的品牌,资料填写的表格不能判断输入的格式,填写完成之后居然不能够直接跳到应用市场下载app……我们要做就要做好。   结果——第二天果然没有上线,需求方到老板面前声泪俱下,老板批评了产品经理和技术团队,技术团队和需求方对产品经理十分不满。而产品经理一再坚持,终于上线了一个华丽的解决方案,但是一段时间之后,用户似乎无动于衷。   原则:完成>完美>完整   本人是精益创业的拥趸,在满足需求的前提下,越简单的实现就越能被我接受。如果一个需求和它的解决方案被用户认可,那么它才值得被完美,被完整,否则只是劳民伤财。   沟通协作   你以为的,不一定是你以为的。   15:
  需求方:圣诞活动测试完了吗?我们已经在用户群里做了预热,反响强烈。   产品经理:哦,上周我们评估了一下,认为这个活动太老套了,实现起来也挺麻烦的,就取消了。   结果——需求方到老板面前声泪俱下,老板批评了产品经理,最终需求方厚着脸皮去向用户解释,需求方不再相信产品经理。   原则:及时反馈   产品经理往往同时面对很多需求方,很多信息,我们常常刻意或者不自觉的将这些需求方和需求做优先级分类,对于信息的变更,也常常认为理所当然,熟不知对需求方来说,这些需求可能非常重要,反馈晚了,就可能会犯下严重的错误。   16:
  需求方:你是这个想法啊,可是来到这一步的用户之前就看过这些信息,有必要再看一遍吗?   产品经理:需要的,因为特别重要。   真相——产品经理在需求方表达的同时就意识到了问题,为了维持形象,因此不顾众人反对,坚持上线。后面在用户访谈中,也有用户表达不满,产品经理最终迫于压力改成了自己也认可的方案。   原则:承认错误   许多产品经理认为自己是业务/需求、用户体验方面的专家,听一些"一秒钟变小白"之类的段子,就把其他人都当成小白,不懂装懂,作出一副权威专业的姿态。这样不仅让自己吞下苦果,更会加大自己与用户的距离,变得更加不能理解用户。   17:
  合作方:你们要求的,做成跟滴滴一样的模式,我们下周技术对接吧。   产品经理:嗯…行吧。   真相——合作是领导牵线的,希望做到跟滴滴一样的接单模式,产品经理意识到接单模式其实不止一种,但是领导都谈好了,总是没错的吧,而且都准备对接了,现在才来问这种问题,岂不是让人看轻自己?还是算了吧。结果,合作方理解的一样的模式果然是跟产品经理理解的不一样,甚至跟领导理解的也不一样,对接了1个半月的合作来这么浑浑噩噩的结束了,合作方将公司列入了黑名单。   原则:充分表达   不要过分高估了其他人,也不要让不好意思害了自己,把自己踩在脚底下才能更接地气。有疑问就提,有想法就表达,这样能够换取更多未知的信息,对于产品工作,它的作用比你想象中更大。   18:
  需求方:我有一个想法,为什么不能做一个定时的引导呢,如果用户停住5秒钟不操作,就弹出提示?   产品经理:这样做会吓到用户的,属于预期之外的事情,还是我这种在页面中增加提示按钮的做法合理。   真相——产品经理意识到那个做法是更好的,但是怎么能让需求方占了上风呢?小小提示无关紧要,这可关系到脸面呢。产品经理坚持的解决方案上线了,但是用户还是一直投诉不知道怎么用,产品经理很后悔。   原则:采纳最好的想法   虽然并非人人都是产品经理,但每个人都有解决方案的能力,采纳最好的想法,不仅会让产品更好,也能够让其他人投入到产品设计中,从而更加认可你的工作。   19:
  产品经理:什么情况?这么多BUG,主流程都没有实现?不是让你们好好测吗?   开发:是好好测了呀,测不出来也没办法嘛。   真相——产品经理并没有给出明确的标准,直说"好好测",开发只是随便点了几下,并没有用心思考。产品经理对开发更不信任了。   原则:一定要有标准   人是感性的动物,绝大多数时候大脑都会选择最节省能量的方式——感觉,去应对问题。所以我们常常会用"我觉得"、"大多数都是"、"可能"、"用心"这种不明确的词语,但当我们去推进事件时,不能够给出明确的标准,会让被推动方感到无从下手,甚至钻空子。而有了明确的,可量化的标准,不仅有助于事件的推动,也能够让我们更有掌控力。   20:
  开发:我这已经有很多需求了,时间不多,你这个需求有要求吗?   产品经理:这个需求非常紧急、重要,你们越快越好啊。   真相——开发将需求逐一加入了日程,对这个"越快越好"的需求,由于没有deadline,被开发扔到了一个叫做"零散需求"的地方,直到很久以后产品经理火冒三丈地过来质问。   原则:一定要有deadline   跟需求方呆久了,就会发现对于他们来说,绝大多数需求都是"重要"又"紧急"的,而且要求都是尽快完成。对于这种情况,我向来是不置可否,要求他们给出一个准确的时间。   而自己作为需求方时,为承接方设定明确的deadline,能够避免我们对于项目进展的失控。   21:
  产品经理A:我们这次做的会员体系,跟用户的个人中心关系比较大,这是我的方案。   产品经理B:你这个改法有点问题,优惠券不应该弱于会员,毕竟优惠券一直是我们的核心。   产品经理C:我正在做个人中心的优化,改动比较大,你们说的我可都不知道啊,不准改。   结果——产品经理A、B直接对开发团队发起了需求变更,开发一片混乱,好不容易达成一致,产品经理C的改版方案获得了通过,之前所做的工作将全部被推翻。   原则:责任分明   工作中,职责不明确的事情屡见不鲜,有些人因为自己熟悉某些工作就指手画脚,而公司内部还乐在其中,以为这是"开放的全民参与"。这样会带来信息的过载,影响到许多人的判断,更会丧失其他人对于产品经理的认知。   22:
  产品经理:怎么跟阿里奶奶的技术对接还没完成,市场那边就已经向客户推广了?   开发:我怎么知道,我们还以为是你安排的呢!   真相——产品经理将工作安排给开发后,就撒手不管了,而需求方向市场直接下达了任务,最终公司不得不向已经签约的用户致歉,并作出补偿。   原则:跟进到底,确保始终有第一负责人   许多产品经理把自己定义成一个接需求,做方案,推开发的内部产品开发的管理者,对于相关的合作、市场、运营的工作不闻不问,甚至抗拒,而其他人对产品经理的定义理解不清,就会很容易第一负责人的丧失,导致项目失控。如果产品经理并不想做主要负责人,或者在某些工作环节与多人对接时,确保有责任人,并确保大家都知道他是责任人。   23:
  开发:又是XX提的需求?前两次都是没搞清楚情况就火急火燎的来提需求,这次你调研了没?   产品经理:前两次我都跟他讲明白了,相信他这次不会继续犯错了。   结果——需求人这次依然在犯错,而且出现的问题比之前更大,他也不以为意,让产品经理去收拾烂摊子了。   原则:不要相信一个犯错两次的人   同样的错误,如果两次发生在同一个人身上,那么我会认为这个人是不用心的,不靠谱的,以后需要谨慎防范的,甚至使用一些可以规范他思维的方式,比如需求提出文档、交互检查清单等,去帮助他发现自己的错误。(仅代表个人观点)   24:
  设计:这种交互虽然还很新潮,但是在欧美年轻人那里已经很受欢迎了,我们也尝试尝试嘛~   产品经理:看在你这么热情的份上,就这么做吧。   结果——新版本上线之后,用户并不接受,吐槽"越改越差",迫于压力,产品经理又将其改回了老版本的样子,设计师反而也瞧不起产品经理了。   原则:只做事,不做人   当遇到想法不一致时,很多人不仅考虑事情,还受到人情事故的影响,生怕惹他人不高兴。产品经理作为各方的枢纽,这种事情就更多了,我们的确是要站在其他人的立场考虑,但不应该因为照顾某些人而去做不对的事情,坚持自己的立场,只做事,不做人,或许事情也没你想象中严重。   25:
  产品经理:我故意做成这种简单的原型,就是想让你们设计师好好发挥想象力与审美能力。   设计师:该你想的你不想,还让我来帮你想,你是产品经理还是我还是啊!我不管,反正你原型什么样我就做成什么样!   真相——设计师以前都是由需求方给出图,然后将其上色,改成高保真,对于交互设计也并没兴趣,认为产品经理应该做出高保真和交互效果。产品经理苦心劝导无果,反而被设计师告到老板那里说"不懂脑子,推卸责任"。   原则:区分对待,赋能与把控   赋能,给一个目的,让执行人自由发挥;把控,明确做法、步骤、目的、时间,让执行人严格执行。自谷歌提出赋能后,国内大大小小公司都提出了各种赋能,我也很喜欢给同事赋能,但事实证明,很多人不理解,不接受,不能承受赋能,把控对他们才是有效的。   观察你的合作伙伴,根据情况赋能与把控,让他们都进入到更舒服的状态。   26:
  开发:这个功能做的不彻底啊,为什么不一次性开发完?   产品经理:哦,你们一直说时间紧,任务重,所以我故意做简单点,以后有时间了再补充。   真相——一次性开发完并不比现在麻烦多少,开发很高兴对别人说时间紧、任务重,讨厌外行评估他们的工作。   原则:不了解别人的立场,就别自以为是对别人好   作为同理心强的产品经理,我们常常为其他人考虑,做我们认为对他们好的事情,但是其他人似乎并不领情。这是因为"为你好"与"站在你的立场"是不同的,如果不能理解别人的立场,那么千万别自以为是对别人好。   最后谨记27:   开发:这里漏了一个逻辑,如果用户是先买东西后取消订单,这个商品会对他15分钟内不可见!   产品经理:还好,用户都取消了就不太可能再买了,还是上线重要!   真相——这是电商购物的一个很正常的现象,出现的概率还是有的。上线之后,投诉电话如潮水般涌来,用户流失率飙升,产品经理不得不跟开发一起,通宵修复BUG,并做用户道歉。   原则:相信墨菲定律,不抱侥幸心理   写这最后一条,其实是用来警示自己,除了做事不要抱有侥幸心理外,对于以上的26条原则也不能随意违反,事情都是从不紧急变成紧急的,问题都是从小问题变成大问题的。
网站目录投稿:又冬