成功的产品和失败的产品最大的区别是能否很好的满足需求
广义上的需求：渴了要喝水，饿了要吃饭狭义的需求：则是经过筛选后留下的对特定产品服务特定场景／用户有正面影响的诉求和建议
需求的来源（即特定场景／用户）
需求评审会：请整个公司各个部分的同事来一起收集需求，描述需求，这种方式的优点是不必事必躬亲地去体验，适合多人协作场景中使用，但是缺点是会需要占用一部分时间来互相沟通需求，这种沟通的过程，就是需求评审会。
需求的获取渠道
1）老板提出的需求；
2）用户直接反馈的需求；
3）公司内部同事反馈的需求；
4）通过数据分析／问卷调查得到的需求；
5）自我驱动产生的需求。
6. “老板提出的需求其实是基于老板对产品的理解，往往很难拒绝，但是如果对于实现产品价值有很大的影响，必须尽自己所能说服老板。” 突然想到行秀面试的时候，那个老板也是这样问我的，然后好的回答是：1）用数据分析来说话，尽量劝服，查各种资料去看 2）引入第三方 3）还是要坚持，那就是要准备收拾残局，把伤害值降到最低，想好一切补救方法，后面其他的事情再说
7.需求管理方法：
单项需求卡片：规范化地收集需求，避免很大一部分仅仅是“拍脑门”想出来的需求
建立／维护需求池：需求池中的需求，其实是经过pm阅读需求卡片后，“翻译”成可以被开发人员直接理解的需求，这个必须由pm亲自把控，以免造成误读
需求更近：
1）需求池中的需求如果在需求评审会上被拒绝或暂缓，需要在备注中说明情况，
2）也必须通过邮件的方式告知提出需求的人（我认为这是一种尊重，这样才会有人愿意不断配合你提需求），切忌石沉大海一般毫无反馈；
3）如果需求已经进入开发队列，产品经理则需要不断跟进需求的状态直到开发完成，通过需求卡片中规定的验收标准验收产品，这里也同样切忌只管头不管尾
4）产品上线后要持续对新的改动进行观察，随时做好版本回退的准备。
8. 在需求池中有这么两个可以帮助产品做需求决策的参数：一个是优先级，一个是性价比。
优先级来自于需求卡片的描述，经过对需求细致了解后作出的感性判断（这里的感性只是相对性价比而言）；
性价比则比较量化，可以通过价值／开发量进行计算，性价比越高，理论上越值得做。
开发量可以通过开发时间来预估，价值则需要参照产品现阶段的OKR（Objectives and Key Results即目标与关键成果法）来进行评估，比如说某功能需求可以完成现有OKR的50%，那么该需求的价值可以定为50，开发量为10个story，则性价比为50/10=5。
作业：遵义那家VR体验店
