阅读完本文大约需2min。

PMCAFF产品经理社区咖友提问:产品经理如何在评审会上不被boss等虐成狗?
需求评审会上被boss、开发、运营和设计围攻,虐成狗,好不容易说服某一方,另外一方又来“找茬”...场面惨不忍睹。因此想问问各位有没有什么好的办法让产品需求评审会更加顺畅。
来自PMCAFF产品经理社区搜狐的产品 @yiyehr 的回答:
需求评审被boss、开发、运营和设计围攻。要不就是需求不靠谱,要不就是需求逻辑、技术实现没有考虑清楚。
1、需要从需求本身出发
你提出这个需求的根据是什么,我自己常用的方式是数据分析、用户反馈、小组内头脑风暴当然还有都会遇到的其他部门要求跟领导指示。
这么说来粒度实在有些粗,还是具体的说说
关于数据分析。
真正能够提炼出需求的数据一般不是新增、DAU、留存等宏观数据,而是针对于某一个功能、某一个路径或者某一个页面的数据分析。
举几个自己遇到例子:
(1)APP登录注册环节,从输入手机号,到获取验证码,再到输入密码,有些还需要输入昵称等更多信息,是一个典型的漏斗事件,每一步都会有流失,通过分析每一步的转化率可以发现很多问题,有一段时间我们验证码不稳,用户时候收不到验证码,扑街啊。
(2)某些流量比较大的页面或者承接业务订单的页面需要格外重视,我们有一个流量非常大的中间页面,跳出率有18%之高,理论来说用户到了这个页面没有满足自己需求,肯定接着往下走啊,可是这么高的跳出率说明这个中间页面没有做好承接跟引导作用,所以我们就会对这个页面做一些改变。
关于用户反馈。
很少有用户觉着产品做得好来夸你的,基本都是用着不爽来喷你的,做产品一定要跟自己用户有直接的接触,很多时候你会发现用户的理解跟你产品的设计相去甚远。举个小例子,之前一直觉着下拉刷新是一个烂大街的做操,就没有做引导动画,后来跟用户聊了才发现很多都还不知道。
小组头脑风暴。
小组头脑风暴很关键,不要以为那些技术同学对产品没有自己的见解,只是很多时候不愿意跟你说罢了,我们就有很多不错的需求是技术同学给的idea。举个小例子,我们有一个特惠车模块,按照默认顺序排列的话会导致首屏总是那么几款车,信息流动性很差,后来技术同学说可以根据用户浏览行为在特惠车首屏放个性化内容,这样每个人看到的都不一样,很棒的想法
这张图没有意义,只是告诉你读到这里休息一会
其他部门需求跟领导指示:这个一般都不会有太多反对
2、需求的讲述方式很重要
除了产品,可能别的同学都是第一次听到这个需求,如果没有很好的方式会让别的同学理解起来特别费劲,我觉着更简单的方式是根据特定场景讲故事,让听众能够在大脑中有有个更具体真实的感知,比如你直接说在特惠车那边加几个个性化车款,可能都没啥感觉,但是你要说你在浏览特惠车的时候突然发现你自己多次浏览或者收藏过的车降价了,这个感觉是不一样的
3、投入产出比
做产品虽然不用自己做开发跟设计,但是基本的技术跟设计感觉还是要有的,所以你提出的需求大概的投入(研发、设计同学的人数与时间等)跟预计的产出一定要把握好,投入产出比很低、或者技术根本不可能实现的需求请不用提,提出来被喷也没人帮你。
刚开始经验不足被喷很正常,心态摆好,慢慢学,慢慢的总结,自己靠谱了别人也就没什么好喷的了。
 ● 
来自PMCAFF产品经理社百度产品经理@迷糊0993 的回答:
昨天看到了苏杰先生的一篇关于资源pk会的推送,里面的内容还挺适合回答这个问题的。他说到,如何在公司的资源pk会上争取公司的认可,争取获得资源支持,如何面对同事、领导的提问。其实,反过来,如果在评审之前,我们先拿这些问题检验我们自己一下,应该会顺利很多。
苏杰先生提到的问题也比较全了,具体内容如下:
  • 你认为为什么要做这件事?不做的话会死人么? 
  • 看到了从总体KPI分解出自己的目标:这是用户的目标还是我们的目标?是不是老板的目标?老板换了怎么办? 
  • 看到从用户需求出发,引用了一个观点,不错:这个用户有普遍性么?能代表多少人?这类用户对我们的优先级是?
  • 看到引用了一个数据,来证明自己的观点:数据来源是?什么时候取的?怎么采样的?
  • 看到写得太实在,都是项目方案:我没有看到这个产品线的一张大图,1年后你这块产品是个什么样子,你实现整个图景的路径是什么?
  • 看到写得太虚,都是画大饼:未来很美好,怎么实现?现在最重要的,如果只做一件事,是什么?你打算怎么做?
  • 看到一个需要运营方案,需要资金预算:你能量化么,ROI是多少?这笔钱真的能用在我们最看重的用户身上么?会不会被不投钱就已经很活跃的用户花掉?
  • 看到要做的事情太多:这么多事情,你打算组建多少人的团队?他们都需要什么能力?怎么分工?如果只给你两个人,怎么办?
  • 看到要做的东西真的很吸引人:实现路上会碰到的最大问题是什么?你打算怎么解决?需要大家怎么配合你?你打算如何说服各个部门都来帮你?
  • 看到具体的项目:你这些项目需要占用的开发资源有多少?如何给技术的同学带来成长和成就感?
  • 还有同事团队对业务的质疑等。
      (来自公众号:iamsujie 的推送)
就如同产品上线前的测试,给自己找问题,自问自答。
其次,在开会前可以提前与与会人员沟通,了解彼此的想法和可能出现的问题,提前做准备,提前达成大致的意见统一,毕竟大家的目标是一起把产品做好,而不是喜欢公共场合互相撕来撕去。这样避免了过多的冲突,同时可以提高开会的效率。
最后一点,就事论事,放平心态,情况很定会有,但是只要是针为了做好工作就好,不要让心情受太多影响。同意楼上所说,没有经验的时候虚心接受,努力改正,争取以后少一点弯路。
本文来自PMCAFF产品经理社区(www.pmcaff.com),不代表PMCAFF观点和立场,未经许可,禁止转载。
继续阅读
阅读原文