产品经理日常的工作中有很大一部分时间精力是花在需求管理上面，而需求管理，其实管的是一个需求从获取到（功能）上线的一整个生命周期。需求在不通的阶段，产品经理对这个需求所需要负的责任是不同的。一个合格的产品经理，要能够做到对每个需求都了如指掌。
要管理起整个产品，将产品拆分成功能，功能都从需求中来，是需求的表现形式。
一个需求有如下几个生命周期：获取需求，设计和讨论，待开发阶段，开发阶段，复盘阶段。
获取需求
不管是从用户反馈、业务方提交还是老板处获取到的需求，在获取到需求的这一刻都应该要做一个判断并且记录。
需求判断的方法
1. 判断需求本身的重要性
2. 考虑需求来源
3. 了解需求背景
需求记录
有几类不做记录的需求：
1. 没说清楚原因的需求不记
2. 没说清楚逻辑的不记
3. 不是实际遇到的需求不记
需求记录的格式：需求背景+需求描述
设计和讨论
需求优先级讨论
通过四象限法则或者（简易）KANO法则对需求进行优先级的判别。其中通过KANO法则讨论得出的需求中有3类最重要的需求类型：
1. 必要需求——存在，用户没感觉；不存在，用户不开心。即“痛点”需求。
2. 期待需求
3. 惊喜需求
方案的草稿
确认清楚需求要用哪种方案来解决。
在这里产品经理先讨论出一个大概的方向及粗略的方案后跟业务方确认，确保意见一致后再进行方案的细化。
指定负责人
要指定一个产品经理来负责整个需求，直到需求（功能）上线后，一旦出了问题他也要负责任。
划定时间节点
这里的时间节点主要是指方案的完成时间（包括调研及讨论完成的时间）。
讨论完成之后，需求池中每条需求的状态都会得到更新。
待开发阶段
需求方案确认之后，及时跟开发人员确认方案的可行性，需要确认以下几件事情：
1. 方案本身的可行性
2. 有没有更好的方案
3. 涉及的产品和技术环节有哪些？
4. 方案的成本如何？（包括开发成本、服务器成本、给用户带来的额外流量成本等）
开发阶段
结合需求优先级（P1（高）、P2、P3）、实现成本（D1（低）、D2、D3）对需求的开发顺序再进行一次排期，按照工作量及上线时间确定本次迭代需要开发的需求。
开发过程中，出现扯皮的情况的原因：
1. 产品方案不完整
2. 需求方的主观改动
3. 无法预测的客观原因
复盘阶段
在需求走完一个生命周期之后，最好能对整个过程做一个复盘，看看发生了什么问题，怎么预防问题再次发生。
总结
一个好的需求管理方法和工作习惯，能为你剩下更多的精力去关注更重要的产品设计。
