需求评审

产品经理在需求评审会上必定被问过的7个问题!

在需求评审过程中,产品经理往往需要跟多方进行解释和沟通,其中,与技术小伙伴的沟通过程中,有可能会就功能、方案设计等方面提出相应问题。本篇文章里,作者就总结了产品经理在需求评审过程中可能会遇到的七个问题和对应解决方法,一起来看一下。有一句玩笑话:产品经理不是在吵架就是在去吵架的路上,生动地刻画了我们产品经理在沟通上需要花的时间。而需求评审会是所有的沟通场景里面比较重

多、快、好、省、趣、美、嗨、秀,八字判断需求真伪

成也需求,败也需求。产品经理跟需求有着一种说不清楚的孽缘和宿怨,真可谓成也需求,败也需求。身处互联网江湖十余年,已经司空见惯。产品经理被骂被黑已经成为一种莫名其妙的风尚,最常见的情况就是错误的产品战略是老板亲自决策的,荒谬的产品设计也是上位者意淫出来的,操蛋的产品需求是XXX部门提升KPI撕逼出来的,而这一切的一切,最终的结果就是产品经理躺着中枪被骂被撕。产品经理吃这种哑巴

又是被客户DISS的一天

产品经理的日常工作,跟客户的沟通必不可少,被客户DISS也成了“日常”。昨天又一次被客户在沟通会上DISS了,之所以用“又”是因为它就像北京的大雾(或大霾)一样,指不定哪天就来了。天无三日晴,心无三日

产品经理,如何进行有效的需求评审

上周连续针对同一个版本进行了三次需求评审,第一次进行了全范围的评审,涉及到各方相关人员,包含:产品、设计、开发(客户端和服务端)、测试;第二次产品团队内部小范围的评审,主要是为了确定第一次评审中部分不太确定的/没考虑到实际可能遇到的问题的需求,涉及人员:产品(iOS端和Android端)和运营;第三次针对那些不太确定的/没考虑到实际可能遇到的问题的需求进行确认,涉及人员:开

需求评审几个最常见的坑

佛家讲,一饮一啄,莫非前世注定。对于产品同学来说,归因理论本应该属于基础的底层产品思维,不仅应该清楚需求如何去做,更要知道需求背后的原因。同样的,评审会本身

谈谈我对需求评审的理解

需求评审是产品设计流程中的必备环节。评审时,产品经理可能会遇到各种刁钻又犀利的问题,一不小心就变成了“撕逼现场”、“批判大会”。评审会似乎成了产品经理面临的一项

跟研发同学又吵了一架

前天需求评审会上,跟研发同学又“小吵”了一架。原因很简单,我想解决问题,他们想“解决需求”;我想推进项目,他们想推掉项目。咱们来还原一下这个场景。当时评审的需求是:场景1:夜班遇节假日,以0点为界限,

关于需求评审的一些实践方法和思考

开需求评审是产品经理的工作内容之一,那么如何做好这项工作呢?梳理自己在工作中的实践和感悟,希望能找到更适合的最佳实践方法。需求评审的作用向他人传达自己设计理念如何在会议上讲解清楚自己的设计思路并得到大家认可,是需求评审前应准备和考虑的问题。发现自己设计的不足,查漏补缺一个人的思维毕竟是有限的,通过评审,让不同角色的人员站在不同的角度审视方案,是很好地补充自己思维不足和发现方