在几家公司实习，进行了一些产品工作之后，经常陷入到工作细节中去--每天写需求，自我学习的重点也就放在了“产品方案上”，遇到其它问题都是“乱拳一顿”，没有经过认真思考；但是，实际上产品经理不是做好产品方案，写好PRD就好了的。
产品经理的工作围绕着“需求”展开，所以产品经理究竟需要做什么、在那些方面提高应该也是围绕着需求谈起，所以今天让我们从“需求”的生命周期谈起，看看除了写需求，产品经理还应该做什么？
一个“需求”完整的生命周期可以按照如下理解：
需求收集--讨论与设计--方案设计--待开发--开发--上线--复盘
【需求收集】
一个需求的获取即是需求收集阶段，
需求来源有：
-来自老板等上级的需求
-用户反馈
-自己的思考、产品节奏安排与规划、灵感
-数据分析
-走查
-业务、运营等合作方
每获取一个需求，需要进行记录，推荐对需求进行完整记录，主要字段有：
需求命名
来源
背景
描述（场景、问题、方案）
优先级评估（重要紧急程度初级评估）
上述对需求的记录构成“需求池”
【讨论与设计】
有了需求池，定期需要进行个人、组内讨论，将需求池需求进行处理，这个阶段需要确定每个需求的优先级以及初步方案。
1、需求优先级判断
方法一：
P1：BOSS需求，对于boss的需求，产品经理应该做好控制而不是抗拒，boss们的信息更全面、站得更高，往往更加具有前瞻性，所以，boss的需求往往排在前面。
P2：核心功能以及商业化，产品或者版本的核心功能迭代等往往比较重要（APP+后台）；商业化需求直接面向盈利，优先级较高
P3：提高日活、拉新&体验需求
P4：产品尝试、提高效率
方法二：四象限法则
重要、紧急进行划分
重要程度划分：
不做，会造成严重的问题和恶劣的影响
做了，会产生巨大好处和极佳效果
跟核心用户利益有关
跟大部分用户权益有关
跟效率或成本有关
跟用户体验有关
紧急程度划分：
不做，错误会持续发生并造成严重影响
在一定时间内可控但长期会有糟糕的影响
做了，立刻能解决很多问题、产生正面的影响
做了，在一段时间后可以有良好的效果
方法三：KANO模型
P1：必要型
P2：期待型
P3：惊喜型
2、初步方案
完善初步方案后需要确定时间节点。
时间节点主要是指方案完成的截止时间（Deadline）。就是当前需求能够完整提交给开发人员的时间。如果没有这个时间，对需求的管理就没有意义了。另外，如果是要跟相关部门再确认、需要对用户调研及要统计各种数据再作判断，那么还要有调研或讨论完成的时间（Deadline）。
同时，注重同步给需求来源需求状态与需求进度、规划等。
【待开发阶段】
现在产品已经有了明确的需求方案，进入待开发阶段，这个阶段严格意义上讲属于“方案设计”阶段，但是需要尽快与研发进行可行性评审，并且必不可少，
明确前后端等各方面的变动与人员安排
方案本身的可行性：技术是否可行？
有没有更好的替代方案
方案成本预估（打点）
【开发阶段】
正式开发前会对需求的优先级以及方案成本综合进行技术排期
高优先级、低成本的先做
扯皮原因与对策：
1、方案不完整：文档、自我批判、组内评审与讨论、技术评审、复盘
2、需求方需求变更：自己的问题自己道歉复盘、合作方的问题在需求阶段及时同步沟通
所有的，都要保持与研发的良好沟通，我们的目标是一致的，要双赢，而不是证明自己是对的。
【上线】
需求上线包括几个注意点，上线实验（AB/灰度）、上线活动、新手引导&用户教育、上线后的数据日报、价值评估
