就目前产品的成熟度而言，绝大部分产品经理做的产品都能找到竞品。产品从0-1的时间很快，短就1个月左右，长点的3-6个月也差不多了，而后续都是完善维护性工作。
这意味着什么呢？
由于产品0-1的阶段很短，我们的初版很多时候都把竞品核心能力抄过来改改就好了，所以大量需求其实都来自竞品和行业理解。这些需求都是行业标准需求，功能模块比较好分类整理。
后续持续完善的时间很长，我们的产品会慢慢形成自己的特点。我们会采用快速迭代的方式来实现需求，这些需求很多、很小、很细，我们要把握的是哪些需求最重要，要把重要的需求先做好。
所以，作为产品经理，其实我们大部分时间做的都是产品持续完善性的工作，我们的需求更多都是按周、按月度来迭代开发的。
我们会面临的问题可能是管理好50个需求甚至更多，然后每个版本要选出10个左右需求优先处理。
我们采集了那么多需求如何管理？
需求的管理我觉得主要涉及到3个形态：
第一个是产品蓝图/产品路线图
一、产品蓝图是展望未来的样子，就是产品中长期的一个规划，是未来至少半年一年的样子。产品蓝图通常也是业务功能组成，是产品的全貌图包括未来的部分。
产品蓝图更多的是从产品能力出发，会体现出产品未来的能力，会包含产品所有的功能模块和未来的能力，他们是融合在一起、有关联关系的但又可以相互独立运转。
产品蓝图就是给老板/客户汇报的时候用的，一般在大点的项目中，在PPT里面经常出现，是项目的全貌。
二、产品线路图主要是将产品以业务流程、业务类型、用户场景和用户完整路径来进行划分，是产品的行动路线。
所有产品都不是一蹴而就，特别是产品体量变大以后，会形成产品生态。比如要打造智能家居全品类产品，像小米，从做手机开始，扩展到排插开关业务，这就会形成一条排插开关业务的的线路发展图；还有照明业务发展线路图、安防业务发展线路图、运动、厨房卫浴、宠物与植物等等，每个业务都会有一条产品线的发展线路。
第二个是临时需求记录表
产品经理其实在任何时候都可能采集到需求，大到一个新系统的想法或一个大模块，小到一个文案的修改，这些需求我们都要马上记录下来，不然随时可能会忘记。
针对这些非常临时采集到的需求，我通常会用一个文本文件来做快速记录。
把需求分为跟进和代办。
跟进的事情通常会插入到我本周的工作计划去跟进处理，而代办的任务我只是先记录下来，每周或者每3天梳理一次代办事项，紧急的插入本周工作，不紧急的扔到需求池。
从个人需求采集和管理的角度来看，这个需求记录表用起来特别方便。
第三个是梳理过的需求池
需求池是产品的弹药库，你的产品已经投入市场去竞争了，而竞争是持久战，你要清晰的明白，你还有多少子弹、炮弹可以打出去，最终帮你赢得客户和市场。
需求池不是单纯的把所有需求放到一起，我们需要分析归纳梳理，就和仓库管理商品一样
- 每个商品放在什么位置是确定的，不能乱放，否则很容易遗漏。
- 仓库可能某块位置是空缺的，是按规划做的预留。
- 同品类同样的商品很多，哪个先出库哪个后出库是有规则的。
需求优先级的评估
需求的管理，最难的不是需求多而杂乱，最难的是优先级的判定。
我们对需求优先级的衡量其实大部分都很简单，就是根据用户价值和紧急程度来定就行，但是这些都是相对依赖个人经验和个人的能力。
下面有2个需求优先级评估的方法，可以参考借鉴：
一、我整理过一个产品需求优先级套评分体系。
主要根据四个维度进行打分:
- 用户价值。根据需求给用户带来的实际作用和价值进行评判；价值越高分越高。
- 使用频率。高频的功能一定是核心功能；频率越高分越高。
- 简易性。需求的实现难度，越简单分值越高，如果实现起来耗时长、复杂性高，那么得分要低。
- 特殊性。客户或老板硬需求，具有一定临时性且重要，有特殊的应用场景。如果此项没有则可打0分。
每个维度10分，四项分别打分之后，相加平均得到一个综合得分。
评分表如下：
二、用二维四象限的方法来评估需求
即把需求按：不重要但紧急，重要且紧急，重要但不紧急，不重要也不紧急 进行分类和优先级安排，理论上这是最合理的。
本页的评论功能已关闭