深挖需求的十三要素五步法_产品经理|产品经理|PM老猫

本文节选自《决胜B端》（第二版）。如何深入挖掘需求背后的真正诉求，并形成全面的思考和设计，是每一名产品经理面临的挑战。本文提到的十三要素五步法，是我原创的方法论，在服务过的多家企业都有实际落地应用，效果很不错；其思考逻辑，可以作为大家需求挖掘工作的一个参考。

6.2.1 一次不成功的需求分析

提起需求分析失败的经历，果冻有着刻骨铭心的教训。刚毕业没多久的时候，果冻负责设计一款企业自研产品——给电销团队销售人员使用的销售型CRM产品，主管会将一些比较简单的需求交给果冻跟进。

有一次，销售运营部的小姐姐豌豆找到了果冻，提了一个需求。

豌豆：“果冻果冻，又来麻烦你了，给你提个新需求！”

果冻：“好呀好呀，一起聊聊！”

豌豆（对着系统边说边比画）：“咱们现在的CRM系统不是会有消息提醒吗？里边有很多提示，比如线索还有1天就要掉库时，会在消息中心弹出一条消息。窗口像图6-2这样，有3条未读消息，其中第一条就是线索要掉库的提醒。”

图6-2 目前的消息中心窗口

果冻（不好意思地挠了挠头）：“呃，这个情况的确存在。不过，小姐姐，我想先请教一下，掉库是啥意思啊？”

豌豆：“对了，你刚接手这类工作，还不太了解业务。在我们销售管理业务中，给销售人员分配的某条销售线索，如果销售人员7天没跟进，或者14天没成单，就要被强制收回到公共资源池中，由其他销售人员捞取并跟进。线索一直无人理会的情况就叫掉库。”

果冻：“明白啦，小姐姐就是厉害，一说就透！咱们这次的需求是什么呢？”

豌豆：“是这样的，目前线索的掉库提醒设置为提前一天发出，销售同学看到后很容易就忘了，大家找我反馈，希望提醒能够更紧凑一些，比如说掉库前一小时再提醒一次。事实上一小时哪儿够啊，还得忘，前1小时和前10分钟，得提醒两次，这样大家就不会忘记处理了。”

果冻听完后心中有一些疑惑：提醒了就能及时处理吗？而且掉库前10分钟提醒，就能保证销售同学马上放下手头工作，去跟进这个线索吗？不过虽然有诸多疑问，但是果冻对业务并不了解，刚刚已经请教过一些问题，觉得再追问太多怪不好意思的，于是……

果冻：“好的，这个需求听起来很合理，估计做起来也不难，我让研发大哥评估一下，尽快排期去做！”

豌豆：“太好了，那麻烦你了，果冻同学就是好，工作最高效了！”

两周后，这个功能上线了！豌豆很开心，还给果冻和研发同学买了奶茶表示感谢。

不过，上线一周后，豌豆又来找果冻。

豌豆：“果冻同学，还得麻烦你。上次提的需求上线后，我问了一下销售同学，他们提了个意见，我觉得很合理，就是在消息文案中，能不能说清楚还有多久线索会掉库呢？之前没有这样的信息，是因为大家都知道收到提醒代表还有一天线索要掉库，可是现在掉库前要推三次消息，大家就不知道到底再有多久会掉库。”

果冻：“嗯嗯，有道理！”（内心懊恼，直拍大腿，这么简单的问题我咋没想到！）

豌豆：“还有个问题，这个提醒功能，销售同学非常喜欢，但是大家反馈提醒的内容太多了，如果能分组展示，就能一目了然，知道今天有哪些新分线索、掉库线索，安排自己的工作计划就更方便啦！”

果冻听起来感觉怪怪的，为啥要通过消息中心来管理自己的工作计划呢，不过他也想不出其他更好的主意，也找不到反驳的理由，于是就按照图6-3这样做了设计，过了些日子就又安排上线了！

本以为消息中心的优化到此就结束了，没想到过两天豌豆又找来了。

豌豆：“果冻果冻，又得麻烦你！上次做的功能非常棒，销售同学很喜欢！我最近又想到了一个好点子。现在的消息只提示了掉库预警，销售同学经常记不住自己是否已经处理跟进。如果我们能在消息提醒后边加一个选项，让销售同学来标记这条消息是不是做了处理，这样咱们的消息中心功能就更强大啦！”

图6-3 消息中心增加了消息分类

“你说的是不是这样？”果冻拿着工具很快改了一版原型给小姐姐演示（如图6-4所示）。

图6-4 消息中心增加了消息待办事项标记

豌豆：“对对对，就是这个意思，专业人员果然有效率！”（豌豆对果冻比了个大拇指。）

果冻（思考片刻）：“我想到一个好主意，我们将已处理、未处理的消息再做一次分类，这样如果消息特别多，销售同学就能一下子找到所有没处理过的掉库提醒消息了，就像这样（如图6-5所示）！”

图6-5 消息中心增加了待办事项分类

豌豆（兴奋地搓搓手）：“太棒了，产品经理果然厉害！”

经过前两次修改，研发同学已经开始抱怨这个项目，因为后台数据显示，不同标签页面的访问量基本为0，说明很少有人通过点击这些标签来分类。但是，果冻这次依然硬着头皮找了研发同学，拍胸脯保证了需求的合理性，并说之前没人用是因为宣传不到位，最终艰难地争取到研发同学的排期实现。

过了两周，功能上线了！

这次果冻留心查看了后台数据，发现“已处理”“待处理”这些新上线的标签分类还是没有人点！果冻心很慌，难道优化了这么多轮的功能完全没人用？为此他专门去找了豌豆。

果冻：“豌豆小姐姐，咱们做的优化，从后台看，好像没人用啊，要不我们一起去找销售同学做做宣传！”

豌豆（懊恼地）：“哎，不用去了，我已经做过好几轮宣传了，也和很多销售同学聊过，他们说这个功能的想法是挺好的，不过不是特别实用。销售同学希望消息中心在展现即将掉库线索的同时提供更多线索信息。所以，我正想找你提新需求，能不能在线索列表页中加一个新的筛选条件，可以将新分线索、掉库线索这些不同类型的线索全部给筛选出来，这样大家就不用通过消息中心来管理自己每天的待办工作了，毕竟消息盒子只负责通知嘛！”

果冻听完后，当即“吐血倒地”……

6.2.2 需求分析的十三要素五步法

相信阅读完上一节的案例，很多人都会会心一笑。

耗费了这么多时间和资源，做出来的功能却没能帮助到业务人员，甚至没有人愿意使用，恐怕这是最让产品经理伤心的事情了。

问题出在哪里呢？

我们应该怪罪豌豆，谴责她提需求不靠谱、不负责？

还是应该怪罪果冻，谴责他不去挖掘需求背后的真实性和痛点，只是充当了一个原型工人？

还是认为他们两人都有责任？

在任何产品设计工作中，产品经理对需求的分析、判断，以及对方案的设计都要负全责！产品经理的工作职责之一，就是帮助用户、引导用户分析他们的真实诉求，找到背后真正的问题点，而不是用户提了什么需求就做什么。我们不能苛求用户提出合理、严谨的需求，这不是用户的责任和义务，而应该通过自己的专业能力来完成需求的采集工作。

在上面的案例中，有几个明显的问题：

—果冻不熟悉业务，没办法和需求方在同一个频道上对话交流。

—豌豆只是需求的传递者，并不是需求的真正源头，而且传递时夹带了很多自己的想法。

—果冻没有认真地去分析需求、理解需求。

—果冻在产品设计的常识和原则上需要更多积累（例如，个人待办管理和消息中心不是一回事，这是一个基本的产品设计常识）。

当然，果冻毕竟是一个才毕业没多久的新人，需要学习和历练。那么，有没有什么方法，能帮助果冻尽量做到全面的需求分析呢？其实，在需求分析中，是存在一些套路和技巧的，只要尽可能尝试通过这些方法进行需求分析，至少就能保证在一些关键点上没有遗漏。

接下来，我们将介绍覆盖十三要素的需求分析五步法，这是我结合工作经验以及一些理论总结的一套方法论，帮助B端产品经理新人做好需求分析工作。

十三要素五步法，即在需求分析过程中，通过五个核心步骤来覆盖十三个关键要素，帮助设计人员尽量全面地梳理需求，挖掘需求背后的本质问题，找到所有可能的解决思路，从而做出正确的产品设计方案。这五个步骤分别是分析相关角色、了解基本场景、挖掘真实动机、发散更多场景、设计产品方案，对应的要素如表6-1所示。

表6-1 需求分析的十三要素五步法

步骤	要素
步骤一：分析相关角色	1. 提出人
	2. 使用人
	3. 受影响人
步骤二：了解基本场景	4. 基本场景
步骤二：了解基本场景	5. 发生频率
步骤三：挖掘真实动机	6. 核心诉求（痛点）
步骤三：挖掘真实动机	7. 强烈程度

续表

步骤	要素
	8. 实际价值
步骤四：发散更多场景	9. 横向替代场景
步骤四：发散更多场景	10. 纵向互补场景
步骤五：设计产品方案	11. 已有方案
	12. 功能需求
	13. 非功能需求

下面以果冻遇到的CRM消息中心线索掉库提醒的需求为例，讲解并演示十三要素和五步法的实际应用。

6.2.3 步骤一：分析相关角色

当我们接手需求后，第一件要做的事情就是识别需求背后的各个角色。这和我们在从无到有构建产品的调研前期，需要先识别关键利益方，道理是一样的。厘不清楚人，就厘不清楚事，也就无法设计出合适的产品方案。

要素1：提出人

需求的提出人，是指原始需求的提出人，而非需求的传递人员。

在公司中，任何人都可能是需求的提出人，比如客户、销售、售前顾问、实施人员、CSM（客户成功经理）、业务运营、老板等。需要注意的是，需求的提出人，并不一定是产品功能的使用人，而需求背后要解决的痛点也并不一定是需求提出人的痛点！

要素2：使用人

最终使用产品功能的人，是需求的使用人，也即产品功能的终端用户。

需求的使用人，不一定是需求的提出人。

要素3：受影响人

最终受到产品功能影响的人，是需求的受影响人（或者叫产品功能的受影响人）。

需求的受影响人，不一定是产品的使用人。

产品经理在进行需求分析时，一定要留意对受影响人的分析，有必要时也要进行调研和访谈，从而更全面地理解问题并做出决策。

在果冻面对的CRM需求案例中，需求的提出人是一线销售人员，豌豆只是需求的传递者，然而在传递过程中她加入了自己的理解，并直接给出了解决问题的方案。

需求的使用人是一线销售人员，因为实现的功能最终是给他们使用的，并不是给销售运营部使用的。

在这个案例中，需求的受影响人同样是一线销售人员，并不涉及其他角色；需求解决的是一线销售人员的新分线索管理的痛点。

我们可以再举一个例子，来展示提出人、使用人、受影响人不一样的情况。假设销售部门的老板提出了一个线索分配的需求，希望新的销售线索由系统根据配置规则分配给不同销售人员，而不再由专人来手工分配。针对这个需求，提出人是销售部门的老板，使用人是销售运营（配置功能是给销售运营人员使用的），受影响人则是一线销售人员和销售主管（配置的规则会影响到一线销售人员获取新分线索的方式）。注意，在这个案例中，产品经理要解决的是需求提出人的痛点（销售部门的老板对新分线索人工分配不合理导致线索资源被浪费不满）。

可以看出，在B端业务场景下，仅仅是需求背后的相关方就需要先下一番功夫才能分析清楚。

6.2.4 步骤二：了解基本场景

当我们厘清了需求的相关角色后，下一步要着手分析需求背后的基本场景，也就是将需求对应的一个或多个典型场景加以还原。

要素4：基本场景

在互联网公司做产品设计的C端或B端产品经理，在探讨产品的功能设计时，经常面对的质疑就是“设计背后的场景是什么？”一切脱离了场景的功能设计，都是脱离了实际的空中楼阁，是难以落地并发挥真正价值的。

一旦我们把干巴巴的需求通过结合场景的方式加以还原并描述出来，就会发现需求变得鲜活、生动、立体。

如何还原需求背后的基本场景呢？方法有很多，本质都大同小异，这里推荐一种简单且容易记忆的方法，就是按照写叙事作文的步骤来进行场景分析，即：

基本场景 = 人物 + 时间 + 地点 + 起因 + 经过 + 结果

将需求尽量按照这六个要点进行场景还原，就会发现需求马上鲜活了起来。

现在，果冻试着将原始需求通过这六个要点进行拆解还原。首先回忆一下原始需求：

“目前线索的掉库提醒是提前一天，销售同学看到后很容易就忘了，大家反馈希望提醒能够更紧凑一些，比如说掉库前一小时再提醒一次。”

果冻找到了最早给豌豆提需求的销售同学，并且又联系了几个愿意和产研团队交流的新销售同学和老销售同学，聊了聊这个需求背后的场景，整理后写下了这样一段文字。

场景还原：电话销售同学栗子（人物），来公司半年了，每天勤勤恳恳，手里有不少老线索，每天也会分到很多新线索。在每个工作日的早上、下午和晚上（时间），坐在格子间的工位（地点），开着CRM系统的同时，要忙碌地联系不同客户，可以说，不是在通话，就是在拨号的路上。然而，今天下午，栗子同学又发脾气了，又有一条优质线索，因为不小心忘了跟进而掉库了（起因）！“这个系统一点儿都不好用！”栗子抱怨着，系统中这条线索的掉库提醒只在昨天发了一条消息，一闪而过，一点意义都没有，根本记不住，也不方便统一查看管理。她希望能对提醒功能做优化，让消息提醒得更频繁、更及时（经过），总之能方便自己准确管理和及时跟进，不要漏掉每一条即将掉库的线索！（结果），不仅栗子如此，所有伙伴都有同样的经历和感受！

当果冻还原了这个需求背后的场景后，发现销售同学遇到的问题一下变得生动了，而且在场景中体现出更多问题和现象，却不需要描述解决方案，这让果冻对问题的把握一下子有信心了！

要素5：发生频率

需求背后的事情或问题发生的频率，是我们需要一开始就了解清楚的重要情况，有必要作为一个要素列出来，以引起足够的重视。

在大多数情况下，一般会有这样一个共识，对于非常低频的需求和操作，可以将优先级调低。因为有些功能，做出来可能一年只会用到一次，既然如此还不如提供线下支持，投入产出比更高。例如某些配置功能，可能开发需要10人天，但是一年只用两次，如果让研发人员帮忙在后台手工设置，只需要10分钟，在资源紧张的情况下，这个需求还不如就让研发人员手工实现。

但是，在一些特殊情况下，即便需求的频率很低，也要考虑加以实现。例如，财务的月结工作，每个月只进行一次，但对于企业而言是非常重要的业务动作，如果有相关的处理逻辑调整，应该提前开发，做好充分测试，保证月结工作顺利进行，而不能让研发人员在月结当天手工处理，否则不仅会影响月结工作，还会导致非常严重的后果。

6.2.5 步骤三：挖掘真实动机

掌握了需求的基本情况后，接着要尽可能地尝试挖掘需求背后的真实动机。

绝大多数情况下，用户提出的需求都附带自以为正确的解决方案。这是人之常情。即便是产品经理，也需要经常自我反思，很多时候我们在给别人提需求时，是不是也会习惯性地把自己以为正确的解决思路一并提给对方，而且希望对方能按照自己的想法和意图去执行呢？

畅销书作者Simon Sinek在TED演讲中提出了如图6-6所示的黄金思维圈（Golden Circle）理论：可将思维模式分为三层，即Why、How、What。我们在思考问题时，往往喜欢从外层开始，在表层上探索，却很少深入到核心的Why层；如果我们在思考时能够从最里面的Why层出发，展开到How，再到What，则更容易洞悉问题的本质并做出正确决策。

图6-6 黄金思维圈

在产品设计与需求分析工作中，用户提交的需求往往是在What层面的思考，我们应该帮助用户，从思考的外层逐步深入到内层，找到核心诉求后，再向外延伸，寻找更多的解法，如图6-7所示。

图6-7 需求分析和产品设计的思维方向

要素6：核心诉求

分析核心诉求之前，我们要想清楚，需求本质上是要解决谁的诉求、谁的痛点。痛点既可能来自需求提出人（例如前面讲到的销售线索分配的需求，销售负责人是需求的提出人，需求对应的是解决他的诉求，但需求的使用人却是销售运营人员），也可来自功能使用人（例如果冻参与的这个案例）。

寻找需求背后的核心诉求时，我们可以采用丰田公司的大野耐一提出的5Why分析法，连问五个为什么，层层递进，通过打破砂锅问到底的方法，穷究问题的本质。当然，5Why分析法只是一个参考，实践中并不一定必须问五次为什么。

果冻尝试用5Why分析法对需求进行分析。

原始需求是销售同学希望在线索掉库前一小时也能推送一次提醒。

为什么要多推送一次？

因为销售同学认为目前提前一天的消息提醒时间隔得太久很容易忘记。

为什么要提前到一小时？

没有原因，因为这也只是一个拍脑袋的决定，其实提前一小时推送也可能会忘记。

为什么提前到一小时也会忘记？

因为目前系统只是推送通知，推送完信息就不见了，不是刻意记忆，根本想不起来，也很难找到。

为什么推送完信息就不见了？不能持续地提示或不消失吗？

因为目前采用的是消息通知的组件来进行通知，如果希望将即将掉库的线索提醒变成一个持续存在的待跟进任务，则采用其他产品设计方案更佳。

为什么不能通过其他产品方案进行处理呢？

当然可以，销售同学遇到的问题并不是推送消息的时机问题，而是有没有更好的方法时刻提醒他们有一条很重要的待办工作存在。

设计一个一直存在的有明显提示的待办任务，销售同学就肯定能够及时跟进吗？

不一定，他们可能还是没时间处理。

为什么没时间处理？

因为目前线索分配不合理，有些销售同学会收到大量的新分线索，根本处理不完。

为什么会给某些人分配大量的新分线索？

因为目前系统采用的是销售组长人工分配的策略，销售组长分配时纯粹凭感觉，并不知道目前谁工作量饱和，谁比较清闲，因而分配得不合理。

为什么组长分配线索要凭感觉？

因为目前既没有数据报表供他们参考，也没有系统自动分配策略算法给他们提建议，他们也不知道怎么分配合理。

为什么一直没有在系统上实现这种功能，帮助他们决策或者代替他们决策？

这实际上是一个敏感话题，从某种程度上讲，组长能够手工分配线索，代表着一定的“特权”，而且销售管理层认为每个销售小组都应该有自己的管理模式，分配策略由一线管理者掌握更高效。

为什么管理层会有这种感性认识，而不是理性地基于数据进行分析？

问得好，这是存在了很久的问题，大家一直知道它存在却没有深入分析，我们应该借此机会深入分析一下目前的人工分配策略到底是否合理，是否应该从本质上解决新分线索的分配模式，让每个销售的工作量都变得公平、合理。

通过对需求不停地问为什么，其实可以发现很多问题点和改进的机会点。当然，问题挖掘的深度和方向需要产品经理自己做好把握和判断。比如，果冻在分析完后，发现出现问题的原因之一是线索分配规则不合理，因此不能简单粗暴地直接跑去质疑销售负责人。我们分析的目的应该是洞悉本质，在合理的范围内找到更多更优的解法。

同时，也要意识到，对需求做深层次的洞察，不是没完没了问为什么就足够了，一方面，需要有灵活的思路和探究到底的勇气及决心，另一方面，更需要对业务有着深刻的理解和认识。后者尤其重要。对于B端产品设计来讲，如果产品经理对业务理解不够深刻，是很难洞察需求本质的。

要素7：强烈程度

需求的强烈程度，代表了用户对痛点的忍耐程度。如果需求强烈，说明用户痛点显著，需求真实性高；如果需求不强，说明用户痛点不显著，甚至面对的可能是一个伪需求。

如果需要判断需求的强弱程度，或者说判断需求的真实性，可以使用以下两个方法。

—方法一：采用正反两问的方法。

我们总是习惯询问用户，如果做了某某功能，对方是否喜欢，或是否会用。请相信我，多数情况下，用户都会回答“我喜欢”“我会用”，但上线后用户却不会像之前承诺的那样热心使用新功能。除了正向询问，还应该采取逆向询问，即如果不做某某功能，对方的感受是“我很喜欢”“理应如此”“无所谓”“勉强接受”，还是“我很不喜欢”。这也是C端产品设计、用户研究分析时经常采用的KANO模型背后的设计思路（关于KANO模型，我们在第12章中还会进一步探讨）。

—方法二：询问目前痛点的解决方法。

判断需求强烈程度的另一个办法，是询问用户目前是如何解决痛点的。如果用户表示需求很紧急，但在被问到目前问题是如何解决的时，又表示目前问题并没有得到解决，那么一定要留心，这个需求对用户而言可能并不像其所说的那么紧急。如果真的是很紧急的痛点问题，即便没有人去实现相关功能，用户也一定会自己想办法解决。

同样的方法也适用于产品初期的市场分析。在定义了目标客群后，当分析客户的痛点或遇到的问题时，如果客户当前并没有采取措施解决这些痛点，那么这些痛点可能根本不重要，客户很可能也不会为了解决这些痛点而付费购买产品。

要素8：实际价值

需求的实际价值，是需求优先级管理中重要的排序依据。在需求分析前期，我们也需要明确需求价值。如果价值有限，或者不符合公司当前阶段产品规划的重点，甚至可以不用投入太多精力，而直接将原始需求的优先级降低。

关于需求的价值，我们会在第12章中进一步探讨。

6.2.6 步骤四：发散更多场景

用户提交的原始需求往往附带针对背后痛点自以为正确的解决方案。当我们已经洞察了需求背后的核心诉求后，应该跳出需求本身的范围，从更多的角度、场景切入，思考如何解决问题。

要素9：横向替代场景

横向替代场景，是指围绕核心诉求可以找到的所有可能的解决思路或场景，这些场景彼此之间在某种程度上存在可替代关系。

原始需求所描述的场景，只是所有可选方案中的一种，而且不一定对应着最优解。通过5Why法分析问题本质时，我们对问题有着不同层面的理解，可以选择对其中某一层面或某几个层面分析所有可能的解法。

对问题解决思路的穷举，可以采取金字塔思维、结构化拆解的方式，遵循MECE原则（Mutually、Exclusive、Collectively、Exhaustive，相互独立、完全穷尽）

果冻分析需求后，发现背后的核心问题是销售同学新线索分配不合理，导致来不及跟进线索，造成掉库现象频繁发生。虽然需求希望的是加强即将掉库线索的提醒频率，但这并不是唯一的解决思路。果冻思考后，针对提高销售人员线索跟进效率问题，梳理出了以下解决问题的思路和场景。

1. 让线索分配流转更加合理、公平、高效

a)优化新线索的分配规则

i.实现系统自动化分配策略。

ii.保持人工分配，但给分配人员更多的数据支撑作为参考。

iii.采取机器自动化+人工分配混合的模式。

b)优化线索掉库流转规则

完善线索掉库时间的规则（目前规则可能倾向于一刀切且过于严格）。

2. 让销售人员对每日工作计划的安排和执行更加合理且高效

c)让销售人员及时掌握当前任务待办情况

d)系统帮助销售人员根据优先级安排每日工作计划

果冻的分析相对全面地覆盖了可能的问题解决方向，而且他再次深刻地认识到，需求分析的难点在于对业务理解的深度。豌豆提交的需求，只是方案c）中的一个小功能点而已，除了c），我们还有a）、b）、d），都是可以选择的优化方向，而且它们彼此独立，在某种程度上是互相可替代的选择。果冻通过追本溯源，找到了问题的本质，再通过横向扩展，采用结构化思维，穷举了解决的思路，并认识到一切都应从业务场景出发！下一步，就可以选择一个确定的解决方向和场景，继续深入分析！

要素10：纵向互补场景

纵向互补场景，是对选定的解决方案及场景，在需求点的上下游和整体的用户操作动线上，存在的考虑不够全面的机会点和优化空间。找到围绕需求点的互补场景，可以让方案更加全面、透彻。

用户提交的需求，往往只是一个点，但是背后的场景实际上是一条线，或者一个面。如果我们在设计时只是实现了一个点，那么接下来总会有接二连三的补充需求出现。作为产品经理，需要提前将这些可能的优化点、相关的补充场景都考虑周全，进行统一的规划和设计，避免局部和片面性的思考。

通过用户故事地图工具帮助梳理用户在操作动线上的互补场景，是一个有效的手段和方式。此处我们直接使用用户故事地图工具进行分析，对用户故事地图的具体讲解，可参考第7章。

结合目前领导对产品的规划，当前阶段CRM建设的重点在于赋能销售，帮助销售人员（电话销售专员）提升工作效率，因此暂不考虑线索分配策略这些涉及业务规则调整的功能设计。果冻将注意力集中在如何帮助销售人员及时掌握当前待办任务这个方向上，从原始需求“提高掉库消息提醒频率”切入，思考更加全面的设计方案。

通过在销售部门实际轮岗工作三天，以及大量的访谈工作，果冻尝试使用用户故事地图这个工具，将自己了解到的电话销售核心场景（部分）的用户故事地图（见图6-8）绘制出来，虚线部分的功能目前由销售人员在线下手工完成，系统目前还不支持。

基于自己的轮岗调研，并结合用户故事地图的呈现，果冻发现，在销售人员的日常线索跟进作业场景中，他们首先每天会拿一个小本子把待办任务整理好，并标记优先级；在收到消息通知后，销售人员还会把新分线索、即将掉库线索记录下来，更新到小本子中；每天工作结束前会回顾当天的跟进情况，并计划第二天的工作安排。

可见，系统已经无法很好地支持销售人员的当日工作管理，因此他们只能通过记事本自己管理工作。就针对线索掉库提醒的功能优化而言，单纯地提高通知频率是不够的，还需要从销售的完整工作场景入手，在各个环节都进行优化。

图6-8 电话销售核心场景（部分）的用户故事地图

经过思考，在“帮助销售人员及时掌握任务代办情况”这个思路下，除了提升消息通知频率，果冻还考虑增加当日待办清单任务聚合的能力，以增强销售人员对当天工作的管理，让他们和小本本说拜拜！

需要注意的是，对于纵向互补场景的分析，核心是找到需求点中没有考虑全面的相关功能点，用户故事地图只是帮助产品经理进行分析的手段之一，并不是唯一办法。很多时候，对纵向场景的分析，同样也要依靠结构化思维，以穷举缺失的功能点。

6.2.7 步骤五：设计产品方案

产品经理通过对原始需求进行充分分析后，确定了整体的解决思路，接下来，要设计具体的产品方案来帮助用户解决痛点，实现业务诉求。

要素11：已有方案

有些需求，并不一定要开发新的产品功能来解决，现有功能也许就可以在一定程度上直接或间接满足诉求。产品经理首先要对此进行判断，不要盲目地、匆忙地着手新功能的设计。如果需求优先级并不高，客户又很着急，那么通过一些已有功能部分、间接地解决问题，也不失为一个能尽快帮助到客户的好选择。

尤其是对于甲方自研自用系统的情况，研发资源有限，如果可以用一些变通的方式解决问题，并不一定必须开发功能。而且，在甲方工作的软件设计人员必须意识到，解决业务问题才是核心目标，软件产品只是为了解决业务问题采用的手段之一，有时候通过软件产品解决问题的投入产出比反而比较低。

要素12：功能需求

产品经理在分析原始需求后进行软件产品设计，首先要编写PRD，也即功能需求文档，提交给研发人员，以便其进入下一步开发工作。

除了增加掉库线索的提醒频率，果冻还设计了一个全新的待办事项面板，将销售人员每日工作中几个关键场景的待办事项聚合在一起展示出来，如图6-9所示。用户可以通过点击数字超链接，进入线索列表页，查看符合条件的线索记录。

图6-9 全新的待办事项面板

—“今日新分线索”展现的是当日新分的所有线索。

—“今日需联系线索”是指之前设置了待办提醒的当天待跟进线索。当线索被跟进并添加了拜访小结后数据就会被清除。

—“即将掉库的线索”是指1天内即将掉库的线索。当针对线索做了某些特定动作后，数据就会被清除。如果新增了一条即将掉库的线索，则消息中心会进行首次提醒，且将“即将掉库的线索”数字加1。

在面板中点击数字可以进入统一的线索列表页（当然也可以进入待办清单列表页），这实际上已经实现了先前豌豆提出的对消息中心各种改造的需求。在典型的B端产品设计中，消息中心只负责主动式消息提醒，待办管理应该通过其他的组件设计实现。

要素13：非功能需求

非功能需求（NFR，Non-Functional Requirement）是指软件产品在功能需求之外的功能特性，例如系统并发量、接口响应时效、安全性等指标。对于产品经理来讲，了解和关注这些指标即可。不过，在某些情况下，也可能需要在文档中写清楚，例如某些同步查询功能，要求最长响应时间不应超过30秒，并发量要至少支持30个并行查询。

【资源推荐】

软件质量评估国际标准 ISO/IEC 25010:2011对非功能需求做出非常详尽的定义，可查阅ISO官网进一步了解。

6.2.8 十三要素五步法的使用建议

至此，我们已经完整探讨了需求挖掘分析的十三要素和五步法。通过这五个步骤和十三个要素进行充分的需求分析，相信会帮助你洞察、探索需求的全貌。

作为产品经理，一定要分析需求背后深层次的原因，而不是马上上手进行功能设计。只有厘清了背后的问题，才能做出合理的方案决策，确定优先级，并结合产品规划进行通盘考虑。

当然，这套方法步骤较多，执行起来比较耗时，而且每个琐碎的需求都用这五个步骤分析显然也没有必要。更重要的是，通过对要素、方法的学习培养场景化的思维意识，以及全面、缜密的思考逻辑。经过多次训练后，思维模式和思考习惯会形成肌肉记忆，在以后的工作中，即便不再刻意地采用这套方法，依然会习以为常地把握住需求分析的关键要点。

同时，也要再次强调，B端产品成功需求分析的前提永远都是理解业务，如果自身业务知识底子不够厚实，学习再多的需求分析技巧也是枉然。