文章主要介绍了需求挖掘的概念和工具，分享了关于需求挖掘的相关知识，与大家分享。

文（一）中提到，任何产品经理工作都是在对下面三个问题的解答：

1. 满足什么需求？（做什么？）——战略规划&需求挖掘：产品的初始想法来源于用户需求的挖掘，升华于对产业、市场、竞争环境的理解及相应的战略选择。进而基于产品战略，在更细致的纬度上挖掘用户需求；
2. 需求如何满足？（怎么做？）——产品设计&迭代规划：确定要做什么需求之后，还得策划满足需求的具体方式与时间，把“用户需求”转化为“产品需求”，这包括具体的功能细节、迭代节奏等；
3. 需求如何交付？（怎么交付？）——项目管理&上线跟踪：通过最有效的方式让团队理解需求，推进团队实现需求的最终交付，让用户的需求得到真正的满足。

作为本系列的第二篇，本文将先讲讲灵魂拷问一”满足什么需求？”的part1——需求挖掘。

01 什么是需求挖掘？

与很多互联网概念一样，“需求挖掘”同样没有所谓明确的定义。我们需要知道，“需求挖掘”并不是简单地收集需求提出者（包括产品经理自己）提出的需求，因为很多需求在被提出时，仅仅是一个简陋的想法或假设，因而需要通过一系列的分析、讨论，甚至进一步的调研与实验等过程，最终留下并适当调整其中需要在产品中满足的需求。

“敏捷”工作团队会把最终确定的需求以“用户故事”的方式来表达，结合百度百科对用户故事的概念简单说明下：

用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素（个人习惯则会加上“场景”作为其中的第四个要素）：

a. 角色：谁要使用这个功能。

b. 活动：需要完成什么样的功能或目标。

c. 价值：为什么需要这个功能，这个功能带来什么样的价值。

用户故事通常按照如下的格式来表达：作为一个<角色>, 我想要<活动>, 以便于<价值>

举例：作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”

“用户故事”是需求挖掘过程中一种有效的输出，写好用户故事是后续解答“怎么做？”“怎么交付？”的基础，甚至有的团队会以“用户故事”完全替代需求文档。

而除了作为需求挖掘过程的输出，实际上，我们也可以尝试换一下顺序，把你采集到的需求先化作用户故事，然后再去甄别需求真伪、判断需求优先级，这会让所有人更容易从用户的视角看待该需求：

“角色”是否重要？“价值”是否显而易见？“活动”与“价值”的逻辑关联是否合理？有没有获得该“价值”的更优“活动”？整个故事是否让人信服？……

比如说文（一）剧情中的小苗提出课程分销的需求，我们可以从多种不同角度来讲述用户故事：

• 故事1：作为一个<课程的消费者与潜在消费者>, 我想要<分销课程>, 以便于<在看课程之余赚取佣金>。
• 故事2：作为一个<xx类课程的兴趣者>, 我想要<能在微信收到好友安利的相关课程>, 以便于<低成本地找到潜在合适我的课程>。
• 故事3：作为<xxx公司的运营>, 我想要<产品上迭代分销课程功能>, 以便于<增加课程传播，进而增加销售额与整体效益>。

用户故事1，“角色1”是我们最需要服务好的角色；然后“价值1”，基于我们产品定位与用户画像分析，“赚取佣金”无论从需求用户群体范围、需求强烈程度、频率来说，都并没那么让人信服，同时某程度上偏离了产品定位本身（当然有些时候，这样的“价值”会成为兑换企业达成某些价值的工具）；而“活动1”考虑投入产出之后也不一定“香”，可能有更好的选择。

用户故事2，整个故事算是比较让人信服的，但实际上“课程分销“功能只是“活动2：<能在微信收到好友安利的相关课程>“其中一种达成方式，这种方式目标用户触达率能有多少？有没有其他的功能能更有效达成“活动2”？

用户故事3，首先必须说明，这并非常规定义下的用户故事，因为该故事中的<角色>实际上已不是以产品用户来定义了，但引入这样的“企业角色故事”却往往能让需求决策更全面一些，因为所有需要在产品上满足的需求，都是以企业战略作基点的，具体下一篇讲完“战略规划”，你应该就能更深刻地理解我的意思。然后，具体来看看该“故事”：”价值3“似乎很合理，但当我们以公司的角度出发，考虑资源成本等因素（比如在企业无相关中台功能可复用支持的情况下，从0到1搭建复杂的分销体系的开发成本），便会发现”分销课程“功能可能还有更多讨论的空间。

所以，讲一个让团队信服的“用户故事”，才能证明你对需求分析清楚了，这才能挖出需求放进需求池，告诉团队咱们要做什么，这即是“需求挖掘”过程所要达到的目标。

关于具体的需求（用户故事）分析“套路”，本篇先不展开，坑先留着，这非常值得独篇地、系统地输出分享。

02 需求挖掘工具

接下来讲讲三个大家可能都耳熟能详的词：用户调研、数据分析、竞品分析。这些都是产品经理常用的需求挖掘方式，几乎所有需求都来源于这三种工具（当然，需求方自身的产品直觉实际上也可以算第四种）。

2.1 用户调研

引用百度百科定义：

用户调研，指通过各种方式得到受访者的建议和意见，并对此进行汇总，研究事务的总特征。

本文重点说说几个用户调研过程中的常见误区（其中结合了《梁宁产品思维30讲》中的一些观点）：

误区1：把用户访谈当用户调研。

用户调研并非就要找来一个个真实的用户，面对面访谈，用户访谈只是用户调研其中的一种方式，其他方式还包括像：调查问卷、社区论坛等。

误区2：把用户的意见当用户的真实需求。

绝大多数用户并不懂得系统地说出体验，而只会表达情绪，你需要体会对方的情绪和潜意识，而不是直接问ta想要什么，更不应把ta的意见当真需求。

误区3：把个体的意见当整体的意见。

每个个体都是独立而鲜活的存在，个体的意见有时会存在片面性。

谨记，用户调研的首要原则是：清空自己，接纳别人的世界观。只有这样才能从用户调研中准确挖掘用户需求，让团队做正确的事。

2.2 数据分析

数据是指导产品经理做各种决策的重要依据。数据驱动产品迭代过程大概可以这样表达：假设/提问-确定评估标准-实验-分析总结，之后估计会再单独讲讲。

文（一）剧情里，PM小刘根据“搜索转化漏斗”挖掘新需求，其中“转化漏斗”就是很常用的数据分析工具，主要用于分析流程每一步的转化与流失情况。

本截图来自：sensorsdata

需要注意的是，数据统计类的需求也是需求，每次产品迭代都应明确数据需求，要统计什么数据？具体的统计逻辑是怎样的？呈现方式如何？……有了有价值的数据才能做有价值的数据分析，进而作为需求真伪与价值高低的判断依据。

2.3 竞品分析

竞品分析似乎是最没技术含量的一种需求挖掘工具？有时企业们甚至会直接对竞品进行一番“临幕”操作，并且言之凿凿：“遵循用户习惯”、“成熟的东西都是趋同的”、“直接抄过来才快”……

所谓“知己知彼，百战不殆”，不得不说竞品们确实是产品经理找灵感、挖需求的好地方，基本上每条赛道都有那值得你紧跟、关注的竞品，新玩家对成熟玩家的追赶更是如此。例如支付宝、百度等各家的“小程序”也都紧跟着“微信小程序”而来。

无论你说大家是在相互借鉴学习，还是直名抄袭，这不重要，重要的是别为了跟而跟，最后忘了自己的定位，跑偏入坑，本末倒置。这种盲目的“学习”实际上不止出现在功能范围层面，有时甚至是产品战略层面的“学习”，这则更显不智，具体下一章讲“战略分析”再来谈谈。

03 小结

产品经理想要给团队解答“做什么？”，就必须要学会如何正确地做“需求挖掘”——利用需求挖掘工具，基于产品战略（下篇讲），分析用户需求，讲好你的用户故事。

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

题图来自Unsplash，基于CC0协议