需求DNA检测:如何判断一个功能是否值得做

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

xuaiudnajiance

关于“需求分析”,苏杰先生在所著的《人人都是产品经理》中提出了一个方法论——需求的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/

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

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中