编辑导读：上一篇文章作者详述了需求的参考系分为四种类型：弱点参考系、最优参考系、普通参考系和目标参考系。那么，在用参考系确定了需求的价值之后，高价值的需求就一定会被采纳吗？作者对此展开了分析讨论，一起来看看~

有的需求能够提升日活，有的需求能够改善新增，每个需求都有自己的最优参考系，也都存在大量的弱点参考系。原本无法进行对比的两个需求，借助目标参考系的设定，就能够被很好的进行取舍。

若是目标参考系相对该需求而言是弱点参考系，就需要将这些需求冻结起来，记录在需求池当中，等到该需求的最优参考系成为目标参考系时，再取出来进行深入的判断。

若是目标参考系相对该需求而言是最优参考系，该需求是否就应该列入到开发计划当中，投入资源实现出来呢？

并不一定。

即使目标数据指标是需求的最优参考系，也还需要经过第二轮的价值衡量，才能判断出价值的高低。

01 做，还是不做

西瓜新闻是一款资讯类产品，为用户提供多类型的时事热点内容，其核心模块是同城热点，系统采集用户当前地理位置信息，主动推送该位置所在城市相关的热点新闻。

同城热点的内容与用户具备较高的共鸣性，用户愿意将自己看到的关于这个城市的新闻分享到自己的朋友圈，也愿意向朋友推荐西瓜新闻。

该模块为西瓜新闻赢得了市场的认可，仅上线6个月的时间，就达到了200万注册用户，并且，产品每天都有5000人以上的新用户增长。

最大的问题在于用户的留存周期较为短暂，7日留存率不到20%，15日留存率不到5%，大多数新用户都会很快速的流失，只有极少数能成长为产品的忠实用户。

名词注释：

7日留存率：从注册日期开始计算，用户在7天后依然使用产品的概率。

15日留存率：从注册日期开始计算，用户在15日后依然使用产品的概率。

因为留存的问题，尽管有200万注册用户，但产品的日活用户加上每天的新增用户也只有10万人。

经过半年的扩张，创始团队意识到了问题的严重性，如果不能解决留存问题，新用户的增长将没有意义，增加多少，就会流失多少，这些新用户仅仅是注册表里的一条数据，并不会为产品带来实质性的价值。

为此，创始团队决定用2个月的时间强化产品对用户的留存能力，在这2个月里，日活数据将被视为目标参考系，只有能提升日活的需求，才会被实现出来。

张三是西瓜新闻产品团队的一员，在使用其他产品时发现了早起挑战的功能，这是一个能提升日活的功能。

用户每天需要报名，以及支付1元现金才能参与次日的早起挑战，次日在6:00-7:00时间段内使用产品，完成打卡操作便视为挑战成功，若是超过该时间段，则视为挑战失败。

挑战成功者将会退回报名费用，并且与其他挑战成功者平分挑战失败者的报名费用。

参与早起挑战的用户至少会产生两次使用行为，一次是报名，另一次是查看挑战成绩，也就意味着用户将会连续使用两天，为产品贡献两天的日活数据。

日活数据，便是早起挑战的最优参考系，同时，也是产品当前阶段的日活数据。

张三推测该功能将为产品增加1000的日活数据，并将其以需求的形式提交给了产品总监，希望能被采纳，能够获得开发资源将其实现并投入使用。

现在，你是西瓜新闻的产品总监。

你认为，该需求应该被采纳吗？

02 适者生存，优胜劣汰

英国生物学家，也是全球著名生物学家，查尔斯·罗伯特·达尔文在其1859年发表的《物种起源》里提到了“适者生存，优胜劣汰”的概念，意思是：不能适应竞争并且进化的物种，会遭到自然界无情的淘汰，只有那些最适合周围环境的生物才能生存下来，这个理论奠定了生物进化论的基础，也给当时的生物学带来了一场革命性质的变革，而且，受到影响的，不仅仅是生物学。

几乎从理论一出世，就被引入来解释各种社会中的现象，包括军事领域，政治领域，经济领域，管理领域等等，从街头的小店，再到集团公司，甚至是代表国家的政党，均是该理论的忠实拥护者以及践行者。

即使已经过去了100多年，但“适者生存，优胜劣汰”依然被作为生存法则，被各行各业引用。

其中，也包括了我们互联网行业：只有适合的需求，才会被选择。只有优秀的需求，才会被选中。

产品设定的目标参考系就是需求生存的环境，相对需求划分出的弱点参考系，普通参考系以及最优参考系也是需求相对环境的适应性划分。

处于弱点参考系的需求，也意味着，此时需求对环境的适应性最弱，处于最优参考系的需求，意味着，此时需求对环境的适应性最强。

将日活数据设置为目标参考系，也就意味着需求的生存环境转变成了以日活数据提升为目标的生存环境。

那些对日活没有帮助的，相对日活数据处于弱点参考系的需求，就无法在新的环境里生存，不会被纳入选择范围。

目标参考系一直在变化，需求所生存的环境也一直在变化，就像海里的鲸鱼，在陆地上无法生存一样，一旦需求不能适应新的环境，也就无法在该环境下生存。能够适应新环境的需求，才能继续生存下去，才能被选择。

问题在于，“选择”并不等同于“选中”，因为，能够在新环境生存下去的需求，并不是唯一的，产品的每一项数据指标都存在若干种可以提升的解决方案，也就是说，不论目标参考系如何变化，该参考系下都会有多个处于最优参考系的需求。

如果以日活数据为目标参考系时，不仅仅是早起挑战处于最优参考系，诸如签到，打卡，会员，订阅乃至抽奖，话题等等以提升活跃为核心价值的需求，均处于最优参考系。

这些同样处于最优参考系的需求，都能够生存下去，也都会被“选择”，但只有少数会被“选中”，并投入开发资源将其实现。

“适者生存，优胜劣汰”在需求当中的体现，就在于“能够适应环境的，才有被选择的可能性，只有足够优秀的，才会被选中，那些不够优秀的，即使处于被选择的范围，但也依然会被淘汰掉。”

最终，被选中的需求，不仅仅是处于最优参考系，还需要有足够高的价值。

03 高价值需求

需求的价值是相对概念，需要以某项数据指标作为参考系进行对比时，才能得到需求价值。

需求价值的高低则是另一个相对概念，我们需要将某个需求的具体价值与另一个需求的具体价值进行对比时才能得到高价值，或者低价值的结论。

就像数字 3，相对于数字5而言，是一个小的数字，相对于数字1而言，则是一个大的数字。

如果没有数字5和数字1，那么，数字3，只是一个数字，既不是大数字，也不是小数字。

需求，在缺少对比对象时，价值的高低就无法判断了。

所以，在西瓜新闻的案例中，我们无法判断“早起挑战”的需求，是高价值需求还是低价值需求。

关键信息摘要：

已知西瓜新闻是一款资讯类产品，目前已有200万注册用户，每日新增5000用户，日活10万用户，团队将日活数据的提升视为近期的首要任务，日活数据将作为衡量需求价值的目标参考系。

产品经理提出了“早起挑战”的需求，经过测算，该需求能够让产品的日活用户增加1000人。

是否应该采纳该需求？

无法判断的原因，在于缺少对比对象，我们可以尝试补充一个新的需求，作为该需求的对比，就能判断需求价值的高低了。

西瓜新闻产品团队的另一位产品经理提出了一个新的需求，姑且称之为需求A，经过测算，该需求能够让产品的日活用户增加5000人。

此时，相对于需求A而言，早起挑战就变成了低价值需求，成了不应该被采纳的需求。

产品的每一个版本，实际上都是一场需求的选择，随着职级的提升，职权的提升，选择的重要性以及选择的复杂性也会越来越高。

从职业的最早期，需要从多个体验需求当中选择一部分进行开发，再到能够独当一面时，需要从多个能够提升产品核心数据的需求当中选择一个进行开发。这些选项互为对比关系，相对价值更高的，就是当下的最优解，也就是“优胜劣汰”。

但也有一种特殊的情况，选择的过程中，只存在唯一选项，没有其他需求进行对比，无法判断需求价值的高低。

此时，就需要设置一个期望值，将期望值模拟成对比对象，也就是我们期望该版本的某项数据能够实现多大幅度的增幅。

需求与需求之间的对比，实际上，就是需求结果与需求结果之间的对比。

将需求的结果与期望中的结果进行对比，若是等于或者高于期望中的结果，该需求就是一个可被选中，可实现的需求，若是远低于期望中的结果，该需求就会处于可被淘汰的状态，团队将在有限的时间里继续寻找更好的需求，一旦找到更优解，该需求就会被确认淘汰。

只有在完全没有更优解的情况，低于期望的需求，才会被投入资源开发，是下下策，也是无奈之举。

案例中，早起挑战的结果是日活用户增加1000人，需求A的结果是日活用户增加5000人，形成对比的，不是早期挑战与需求A，而是日活用户增加1000人还是5000人。

而需求A，就是一个被设置出来代表期望结果的对比对象，日活用户增加5000人，便是我们希望达到的期望结果。

早起挑战被淘汰的原因，也不是因为比需求A的结果低，而是因为与期望中的结果存在较大的差距。

因为，他不能满足我们对需求的期望。

思考题

经过一段时间的努力，西瓜新闻的日活从10万提升到了30万，现在已经有230万注册用户，每天依然有5000新用户使用这款产品。

这天，又到了碰需求的时间，产品团队提出了3个需求：

• 需求A：能够提升日活用户10000人
• 需求B：能够带来新增用户30000人
• 需求C：能够提升日活用户5000人，且能够提升新增用户100人

但，这三个需求均被产品总监淘汰了。

你认为，是什么原因，让产品总监淘汰掉这三个需求呢？

#相关阅读#

决定需求价值的四个参考系

不出彩就出局，产品经理如何选择需求？

一个糟糕的需求，会给产品带来哪些危害？

不被认可的产品经理，可能是你的需求没有价值

功能所解决的问题，真的有那么严重吗？

#专栏作家#

枯叶，微信公众号：枯叶咖啡馆。人人都是产品经理专栏作家。9年经验产品经理，3年产品总监经验。擅长数据增长，商业模式。曾孵化过千万级用户规模的创业产品

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

题图来自 Unsplash，基于CCO协议。