面对来自客服、运营、竞品、市场、用户调研等各个渠道的海量需求，哪些应该放到产品会议中PK、哪些应该直接pass，产品经理该如何抉择？完成“需求采集”后，在召开产品会议进行“需求筛选”前，“需求分析”是这中间很重要的一个步骤。

关于“需求分析”，苏杰先生在所著的《人人都是产品经理》中提出了一个方法论——需求的DNA检测，如图1所示。

图1 需求的DNA检测过程

按照苏杰先生的方法论去操作，当然是再好不过的，不过在一些创业公司中，负责产品的人员数量不多，而产品的迭代速度很快，对于每一个需求都规范地完成“需求转化-确定基本属性-分析商业价值-初评实现难度-计算性价比”的一系列流程不太现实。因此，对于一些性价比明显不高的需求，产品经理在经过定性评估和分析后就可以直接pass。本文以某产品手机端“轻审批”主页面改版为例，谈谈这个需求为什么不做。

图2是某产品目前的手机端“轻审批”的主页面，某用户提出将主页面改为图3的形式。

图2 目前的“轻审批”主页面

图3 建议改版后的“轻审批”主页面

为了便于分析问题，首先列出了审批功能的主要使用场景，如表1所示。

表1 审批功能的主要使用场景

基于以上场景，结合苏杰先生的方法论，从以下4个方面进行了分析和考虑：

1、面向未来规划产品

目前，该产品的核心模块——IM模块和任务模块尚不够成熟和稳定，仍有一些bug未修复、一些需求未满足。因此，现阶段某产品应集中主要资源完善核心模块，审批这类非核心模块的优先级并不高。并且，审批模块目前并不存在影响用户正常使用的问题，本需求并非为了解决影响用户正常使用审批模块的问题，因此紧急度不高。

并且，随着某产品开放平台的完善和商务合作的开展，未来包括审批在内的非核心应用将会逐步对接第三方。闻道有先后，术业有专攻，该产品在IM方面积累深厚，但在审批方面的积淀也肯定不如拥有多年经验的专业审批软件丰富。因此，在对接第三方之后，某产品自带的审批功能的重要度将会更低。

2、高频场景优先于低频场景

根据经验可知，发起审批功能和处理审批功能的使用频率明显高与审批记录回溯。审批记录回溯则主要针对两种场景：一种是审批程序出现问题时需要查询，这种情况发生的频次较少，尤其是在审批制度推行一段时间后；另一种是周期性统计需要，一般为每月一次。因此，“发起审批” 、“审批进度查询”、“处理审批”是高频的场景，“审批记录回溯”则是相对低频的场景，产品设计时应优先满足高频场景的需求。

3、优先满足核心用户

决策者与使用者分离是企业级市场区别于个人市场的一大特点。对于To B产品而言，企业愿不愿意买单取决于企业决策者（老板）对产品的满意度，而产品能不能顺利地在企业用起来取决于产品直接使用者（广大员工）对产品的接受度。因此，To B产品最应该关注的是老板，接着是广大员工。

而审批的回溯工作主要由人事部门、财务部门等职能部门完成，而这类人员既不是企业决策者，不能在IM产品选型中起决策作用；在产品直接使用者中占比也不高，因此他们的需求并不具备代表性。因此，人事部门、财务部门等职能部门员工并不是To B产品关注的核心，“审批记录回溯”这个场景的重要度并不高。

4、分类导航层级不宜过多

图3的方式下，用户要想查看审批项，进入“轻审批”后需要首先选择一级导航“我发起的”、“我收到的”或“抄送我的”，然后再选择二级导航“已审批”或“待审批”，才能到达审批项列表，这种方式相当于分类导航层数越多，分类更精确，但用户使用路径也会更长，使用成本会增加。 而目前的方式（图2），用户进入“轻审批”后直接选择“已审批”或“待审批”，即可到达审批项列表，导航层级更少、用户使用路径更短。

基于以上分析可知，该产品手机端“轻审批”主页面改版这一需求的重要度和紧急度均很低，而且改版会使导航层级变多、增加用户的使用成本，因此本需求不做。

作者：刘增明（微信号lzm479364262），浙江大学研究生，研究方向是IE/IT，有志于成为一名互联网产品经理。博客地址：http://www.cnblogs.com/liuzengming/。

本文由 @刘增明 原创发布于人人都是产品经理。未经许可，禁止转载。