告别撕逼大战!产品经理「需求评审会」通关指南!
据说「需求评审会」又名「撕逼大会」,你可以感受下这其中的画面感。产品经理组织的「需求评审会」类似多方会谈,与会人员很容易进入角色后产生「自主」情绪,形成正反两派甚至是多派,最后由「讨论」演变为「辩论」,有点类似「奇葩说」的形式。产品经理在这个「辩论」的过程中,不断展示自己的观点,希望获得更多的认可
据说「需求评审会」又名「撕逼大会」,你可以感受下这其中的画面感。产品经理组织的「需求评审会」类似多方会谈,与会人员很容易进入角色后产生「自主」情绪,形成正反两派甚至是多派,最后由「讨论」演变为「辩论」,有点类似「奇葩说」的形式。产品经理在这个「辩论」的过程中,不断展示自己的观点,希望获得更多的认可
上周连续针对同一个版本进行了三次需求评审,第一次进行了全范围的评审,涉及到各方相关人员,包含:产品、设计、开发(客户端和服务端)、测试;第二次产品团队内部小范围的评审,主要是为了确定第一次评审中部分不太确定的/没考虑到实际可能遇到的问题的需求,涉及人员:产品(iOS端和Android端)和运营;第
原本觉得需求评审也就那么回事儿,大家应该都差不多这么做的,没啥好说的。不过,前不久有一位同学问起来我们是怎么做需求评审的,然后发现有一些团队的做法可能还不大一样,他们也还踩着我们之前踩过的坑,他们还在探索更好的方式,于是决定将我们的“玩法”写下来,也许能给困境中的小伙伴一些启发。首先,我这里提到的
搞产品的人都会经历过无数次的挑刺,无数次的评审!当大家对于产品提出一道道质疑时,这时候就要以专业的只是说服沟通他们!很多产品人更多层面是在会议之前准备的不够充分,从而导致会议效率低下,甚至于需要好几次才能通过!(需求评审会议的意义再次就不做讨论了,你们懂得!)在召开会议前,内心要清楚的知道本次会议