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

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

需求分析 2017年01月26日

需求的折磨：需求评审的前、中、后，产品都要做些什么

半年经验的产品助理为什么会犯这个错误呢？这是我最近一直在反思的问题。最后，我发现这和我之前的工作方式有关。每一个需求的从无到有，从有到确认；每一次的需求评审，从失败到成功。对产品经理来说都是一次折磨。每一个版本迭代，我们都需要反复地被折磨，换了新工作后到现在已经4个月了，工作方法的转换，2个版本，4次需求评审的折磨。我也慢慢发现错误，改变工作方法。第一个问题，出在需求评审，

需求分析 2016年11月09日

需求评审时总是被挑战，肿么破？

前几天有小伙伴给我留言，说自己每次需求评审的时候被各种拍砖，不知道肿么破。先看下这位小伙伴遇到的问题：下面是我的回复：确实，需求被挑战几乎是每个产品经理都会遇到的问题。要想在评审的时候被拍得越来越少，首先得总结下常见的被挑战的问题点有哪些。经常被挑战的问题1、技术层面，实现逻辑的可行性问题需求评审中，常常会被技术同学挑战的问题，多是发现产品经理提出的某个“想当然”的功能需求

产品经理 2016年08月23日

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

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

产品经理 2016年08月15日