需求调研过后，会得到一份需求清单，但不是所有的需求都要做上去的，一是受限于开发能力，二是部分需求与产品定位不符。因此，对于收集到的需求，需要有一个筛选的阶段。这是一个需求不断筛选、从抽象到具体的过程。
本文记录需求做不做，什么时候做的一些决策。
一、分析需求的属性
每一个需求都包含用户、场景、需求、频次，对这四个方面进行详细的分析，就能初步得到需求的投入产出比。
1、分析目标用户
要分析目标用户，首先要知道怎么划分目标用户。一般而言，目标用户有两种分法，第一种是按用户的自身属性，比如岗位、性别、年龄、婚否、兴趣等一个或多个属性来划分。第二种是按照产品发展规律来划分，比如老用户、新用户、潜在用户，其中老用户又可细分为忠诚用户、活跃用户、潜水用户。两种划分方式是一定重叠的。通过以上方式得出的目标用户大多数情况下是不会只有一种的，所以可将用户划分为核心用户、次要用户、边缘用户。
对于不同产品，要确定目标用户有不同的方式，可分为新项目和版本更新两部分讨论。
新项目。对于一个新项目，如果是B端项目，用户一定会是新用户，而如果是C端项目，那用户一定是潜在用户。确定新老用户后，就说明产品一定要做好纳新和快速上手指引工作。接下来就确定目标用户属性。比如做一款母婴产品，那目标用户定位可确定为25-40岁的女性，这部分用户扮演“母亲”的角色，是首要考虑的用户。但不是说目标用户只有一个，也要考虑25-40岁的“父亲”、40-70岁的“奶奶”、40-70岁的“爷爷”。所以很容易得到目标用户：
·核心用户——25-40岁的“母亲”
·次要用户——25-40岁的“父亲”
·边缘用户——40-70岁的“奶奶”、40-70岁的“爷爷”
所以这个母婴产品最终目标用户可以确定为潜在用户、25-40岁的“母亲”。
版本更新。首先要确定的是，在版本更新中，如果产品的基调不变，产品的目标用户属性也是不会变的，所以可沿用产品初期确定的目标用户。但是要确定好需求的新老用户，这是根据需求类型来确定的。比如要促进用户活跃度而做一个每日签到功能，那核心用户就应该是老用户和新用户，如果要提高用户注册量，那核心用户就是潜在用户。
以上就是一个确定目标用户的过程，核心用户自然是我们所关注的，但次要用户和边缘用户也是需要有所研究。
2、分析使用场景
功能不是时时刻刻都被需要，只有在特定场合下，需求才能发挥其用处，因此分析需求在什么场合下会被使用，这是一个很重要的问题。使用场景可用时间、地点、人物、起因、经过、结果这六要素来确定。确定使用场景可分为两部分来讨论。
·B端产品。B端产品是商业产品，因此它的使用场景有非常有限，很容易列举出来。例如做一个B2B平台，那所发生的场景基本就围绕“采购”展开，可以很快锁定核心场景：工作时间的办公室，采购人员在平台上下单购买原材料。确定核心场景后，可展开获得次要场景：工作时间的外出环境、加班情况等。
·C端产品。C端产品的使用场景根据其用户规模来确定，用户规模越大，使用场景越复杂。比如抖音，其使用场景非常复杂，全时间、全国、4亿活跃。C端产品使用场景这边就不展开了。
3、找到真实需求
很多用户在描述需求是不懂描述他真实需求，他们觉得某个产品的某个功能好用时，就会告诉你这个功能多好，最好能加到系统上面。以上行为可描述为“伪需求”，那如何得到“真需求”呢？
在得到用户反馈的需求后，要尽可能多问为什么，挖掘出其真实需求。可以按照“时间、地点、人物、起因、经过、结果”这种方式咨询，问出其原因、使用场景、要达到的目标。根据这样的用户调研内容，可得出一个最佳的解决方案。
4、分析需求频次
很多需求并不具备普遍性，它通常是由特殊用户在特殊场景中产生的极端需求，这种需求使用频次极低，做了纯粹浪费资源。因此，分析需求的频次是不可避免的一个环节。
曾经接到老板提出一个需求，当时项目是一个电商平台，商家可在平台上入驻销售瓷砖，支付对接的是第三方支付，老板担心单一支付公司存在被停牌风险，因此要求对接多家支付公司，并且已经谈好新的了。由于平台规模并不大，而且当时做支付时并没有考虑支付健壮性的问题，因此若要做的话，整个支付必须重构，开户、支付、查询、绑卡、提现各个环节都要推倒重来。后来就停牌风险和开发投入权衡下，将这个需求停掉。因此对于这个项目而言，完善交易体验、做纳新功能是远远大于对接新支付公司的。
二、需求的优先级
通过用户、场景、需求、频次四个方面的分析，我们已经可以得到一些完整并且可以准备投入开发的需求了，但开发是有先后顺序的，一股脑把所有需求都做上去是不现实的，一来开发时间长、二来用户需求无法及时上线。因此，接下来就要分析需求的优先级了。
需求可按照重要和紧急两个维度来划分：
·重要且紧急。这个一般是产品问题，例如服务器崩溃、代码存在bug、需求上线口碑直降等。这对产品影响非常恶劣，需要第一时间修复。
·重要不紧急。这个属于核心用户/核心场景需求。上线后的产品将得到极大完善，对用户、竞争对手有深远影响。这种需求在需求阶段需要反复分析论证、严谨规划。
·不重要但紧急。这类需求可以是错别字、功能流程存在小问题但不影响结果等框架层、结构层、展现层体验上的需求。这种属于不影响大局，但对体验有所降低的需求。
·不重要不紧急。这种一般是核心用户的次要场景，或次要用户的次要场景需求，或某些需求的后置需求，需要做，但不是现在。
三、总结
到目前为止，需求已经提上日程表格。接下来就要正式将需求变成文档和原型了。
