编辑导语：第一篇提到“产品认知能力”，在对产品有了基本认知后，那么对需求的理解和判断，继而转化为产品需求等方面，就都具备了洞察的“基础”；而接下来，产品需要进行下一个重要的业务工作，就是对手上的需求进行分析、拆解，这里就很考验产品的功夫；本篇，也将重点介绍产品经理的第2大核心能力：需求洞察能力。

一、什么是需求洞察能力

需求分2类：一个是用户需求，一个是产品需求。

前者就是大家所认知的“需求池”，任何用户都可以提出需求，但是真正能作为需求去进行迭代的只有是“产品需求”；它是经过产品经理综合评估和分析，认为可以作为产品项目后续成长的每一个发起点。

所以这里有一个核心能力表现的过程，就是产品经理是基于什么样的理由、依据去判断，并纳入产品规划当中。

需求洞察能力，主要分2个内容，首先是需求理解，因为先洞察之前就要对需求做理解；这里要求产品经理要懂得在需求收集过程中，能理解用户提出需求的背景、动机、场景及痛点。

其实有很多人就卡在这里，连用户反馈的需求都无法完整理解；一方面是基础认知不足，另一方面是没有完全去站在用户角度或场景去理解反馈的信息。

第二就是需求分析，在对需求有了充分理解之后，就需要判断这些需求的本质、价值等等。

用户提的需求也许会顺带解决方案，但到底是不是需求，是否有其他方式可以解决，这些都可以去分析了解的。

其次就是这些需求背后的动机、对项目的价值、投入成本等等；都是需要在转化为产品需求前进行初步的评估。

二、能力价值

我们每天都会收到很多需求反馈，面对这些大量的需求，如何去有效化处理是值得去锻炼提升的。

而通常在处理过程中，总会遇到这些情况：

1. 用户

在使用过程中反馈了一些需求，按照这些需求做了简单转化就排期上线，上线后发现并不能完全满足，还得持续迭代优化，结果这个功能模块越来越冗余。

其他用户也并不是很买账，更坏的是团队因此还质疑这些需求的价值。

2. 业务

在B端产品中，往往更多的是服务业务线用户，所以对业务场景的理解能否透彻十分关键。

但很多时候，面对业务线同事提出的一些需求，总是片面去了解，或者说对他们的场景无法很好的去理解，并且带着一系列的“未知”就去策划方案；最后结果发现上线后让业务同事使用，发现不能完全满足业务场景的使用；甚至偏离了方向，极大影响产品对外的口碑印象。

3. 领导

来自于上级的需求是很普遍的，但是由于两者身处的角色不同，日常工作内容不同，导致在认知信息上是有不一致的。

那么在收到来自上级的需求的时候，有些人按照这个方向就直接输出“产出物”，结果并不符合上级预期，被打回去返工。

这些都是因为没有充分理解上级的意图，并尽可能去获取更多的信息源，来做有效的需求调研。

4. 行业&竞品

关注市场的变化，是获取需求来源之一。

那么面对行业的一些举措，有些企业往往会选择盲目跟进，抱着“人有我有”的想法去执行。

但是每个需求都是有明确的背景和动机的，在面对竞争对手的需求变化，我们需要关注背后的真实动机；每个项目身处的环境不同在决策上都是不同的，所以在这个时候就需要做有效的需求甄别。

5. 小结

显然，不同的需求有不同的呈现方式，我们面对这些纷繁复杂的需求，首先需要学会“理解需求”。

大家常说的“同理心”，其实更多的是要站在用户的立场去思考这个需求的背景和目的，甚至完全可以化身为用户，“一笔一画”去还原用户的使用场景，来完全领悟其中的意图。

其次在充分理解之后，能直击需求的本质，也就是我们常说的“洞察”，用户提的需求到底是不是需求，他们反馈方案是不是就可以解决问题，是否还有其他的实现方式。

就好像一个经典故事，用户想出行更快一些，我们就提供“一匹马”，但实际“一辆车”是否才是更理想的方式？同时在这些需求之上，我们是否还能挖掘出更多潜在价值需求，通过整合实现更大的升级？

以上的这些产品实践，都无不体现了产品的这一核心能力：需求洞察能力；而能否充分具备这样的能力，对后续的产品规划和执行都有较大影响，如果一开始需求发起就有问题，那么结果无论如何都是不理想的。

这里就要求产品从业者，能否充分理解需求，并能举一反三或者过滤干扰需求信息，找到本质需求。

但其实很多人往往为了“偷懒”，或者认知缺失等等，总是了解片面的信息，连完整的需求内容都没有梳理清楚；并且在判断过程中也只是像“蜻蜓点水”那样，没有深入去剖析内在本质，就急急忙忙去策划上线。

在需求这一环，作为项目启动的起点至关重要，所以就需要产品能在这里找到真正的“产品需求”，让项目明明白白去执行，而不是两头不到岸。

三、培养方式

正如前面提到，对于需求的洞察，主要体验在理解需求，并从中挖掘真实需求。

那么就需要在“理解”和“分析”这2方面进行提升，理解的重要性在于能切身处地掌握需求内容；而挖掘分析就是在理解基础，对需求进行转化为有效产品需求的过程行为。

1. 理解需求

学会理解需求，不是简单去听用户反馈的声音，而是需要对他们各自角色背景下，了解其特定行为、动机及场景，并能完整还原他们的需求痛点

1）来源：用户反馈需求的来源，很大程度上反应了他们与产品之间常联系的互动类型。

2）角色：每个用户都代表了各自的角色；如果是C端的产品，例如微信，就有普通社交用户（发发微信、语音聊天等），也有消费型社交用户（公众号内容消费、电商消费等），不同的角色都代表了不同的需求属性。

如果是B端的产品，通过是由用户来代表某些业务线，所以B端的用户角色具有较明显的业务特性；譬如微信公众号平台，它更多是服务大批内容创作者的内容生产、运营等这一系列的内容业务链。

3）动机：每个需求都是有明显“利益诉求”的，也都是为了满足用户自身的某个需求。那么我们在收到这样的需求反馈后，就需要去揣摩对方的出发点什么，是什么原因让他们提出这样的需求，这些信息都是需要去获取了解的。

4）场景：用户和动机往往折射出需求的对应场景，而这里的场景是指用户提出需求的在什么“情景”下触发的，了解这方面的信息，有利于更好地帮助我们在需求分析时，能还原用户的真实场景去了解真实需求，加大理解效果

5）痛点：每个需求的背后其实都代表了一个用户痛点，在咨询时可以了解用户对这个需求的正反情绪。很多时候用户提的需求更像是解决方案，想让你去满足；这时候确实看起来是解决了问题，但都是短暂的。

实质也只是用户按照自身的想法去考虑，作为产品具备的信息全面性要更多些，这时候其实是可以作出更多有价值的建议；所以产品更需要去“关怀”用户的问题所在点，做到真正的“对症下药”。

6）现状：用户提出需求大多数是现状不满足需求，那么这里很重要的就是需要明确当前现状是怎么回事，它的解决方案是什么样的，为什么无法满足用户需求，而这些信息也是对输出新方案做一个有效对比。

对于一个需求，需要从各个方面去补齐相关需求信息，只有这样才能真正“吃透”需求，而在分析时就不会因为关键信息缺失，导致无法作出客观的结论。

在这里，可以通过借鉴“STAR法则”，在对做需求理解时是十分有帮助的。

2. 分析需求

既然已经充分理解需求，那么这时候就需要掌握如何拆解需求、并找到本质需求。

大家都说“洞察”，所谓的洞察就是能够在理解的基础上，很好地判断哪些是干扰信息、哪些是关键信息，以及这些需求“表面”背后的真实需求；并且能站在这个点上有更高的全局观去延伸需求的价值点，如何去服务更广大的用户群体。

1）价值性：我们在分析需求的时候，其实自身是带有明显“利益”诉求的，虽然我们是服务用户，并尽可能满足用户；但是评估需求的前提需要明确价值点，就是这样的需求能够产品项目或其他用户群体是否同样带来相应的正面效益。

同时我们还需要明确这些“价值点“应该如何去衡量，其标准又是如何建立的；如果无法去建立基准，就说明在未来的效果追踪是不可控的。

2）规模性：通常面对一个用户提出的需求，在理解清楚需求内容后，并不是马上就扔进产品需求清单进行排期上线；而是需要去做前期的调研，去印证是否有同样需求的用户群体。

无论是B端还是C端，我们都无法仅为一名用户服务的，这样只会沦为定制化产品；所以我们需要找到同类型的用户群体，从数据层面观察或用户访谈其是否有相似需求的潜在可能性。

通过这样的“群体性”挖掘，才能知道这样的需求其影响面有多大；当然也有些需求属于创新性，无法评估潜在规模，这种就例外只能小范围上线不断迭代继而明确路径方向。

3）重要性：所有的需求在经过分析之后，都是需要判断优先级的，什么是紧急又重要，哪些又是不紧急但重要的。

在这里借助常用的“四象法则”是常例操作，但这也只是面对常规需求；本质上需求是复杂的，带有潜在”利益性“并相互博弈，比如领导需求和项目需求冲突，业务需求和产品需求冲突，到底哪个优先、哪个延迟这些都是需要综合考量，得出一个合理符合现阶段产品规划的。

4）数据性：显然，几乎大多数的需求，都可以从“数据”层面找到一定的佐证依据（前提数据准备充足），比如当用户提出某个需求痛点，可以通过数据去印证在这个场景下发生的用户数量有多大，他们普遍的行为特征是否比较接近的。

又比如在某些特定场景下，用户集中在某些服务模块（停留时长、人数有明显高峰等），或者是明显漏斗转化较低的，那么就要知道是否这个地方发生的问题所在。

基于以上的判断，那么就可以输出相应初步的产品结论，是否纳入规划当中进行排期上线。

这时候的产品需求是经过了分析及充分评估，并且有大概产品方案支持的需求内容——那么这时候才算是真正的产品需求。

四、一些技巧

1. 平衡

如果是面向B端业务，那么所有业务线对自己的需求都是关注且紧迫的；这时候就需要学会平衡每个业务的需求，不能被业务完全牵着走，这样对产品规划会有极大影响。

那么每当这时候，就需要可以一起拉通多个业务，来集中评估各方的诉求，宣导团队的资源是有限性的；让业务之间来取舍他们之间的优先级，这就是让“决策”转移到业务自身上。

2. 替代

任何的产品解决方案都是有备选方案的，那么在当前无法尽快满足用户的前提；可以优先采用临时方案，先满足用户最核心的需求，把其他延伸性需求先砍掉，待到条件成熟在上线完整需求。

而这就是采用“替代”的方式，一定程度上去满足用户需求，这对挽留用户、提升用户口碑有极大帮助。

3. 延迟

这是一个不太“厚道”的方式，前面提到用户对他们自身的需求都关注比较强烈，受限当前的规划和限制条件，确实无法那无法尽快满足的情况，但用户是不会理解买账的；那么如何去“安抚‘用户情绪呢，把负面情绪尽可能降到最低？

这就靠一个“拖”字决，可以先给对方的一个明确信号：我们会做（类似先画个饼）。

但是由于一些原因（把这些问题夸大），需要稍微往后一些才能支持，那么这个往后的时间就可以相对灵活可变的，在这里也主要是安抚用户的情绪为主。

4. 小结

在一个完整产品行为中经过科学、客观的方式洞察产品需求之后，就意味着有了项目发展的“动力来源”。

但是如何把这些需求，在合适的时间上线又是另一个重要学问。

所以在完成“产品认知、需求洞察”这2个核心行为之后，就到下一个核心能力表现：产品规划能力；而下一篇也将围绕此能力做进一步的分享。

#专栏作家#

A.D，公众号：吾某，人人都是产品经理专栏作家。大数据分析产品经理，专注数据挖掘工作。

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

题图来自 Pexels，基于CC0协议。