本文来自微信公众号 “产品变量”，作者：亨哼，纷传经授权发布。

需求是一款产品在开发过程中始终需要面对的重要因素，那么需求从哪儿来？在对需求进行分析时又有哪些误区？

本文作者对以上问题进行了解答，并且推导出了“需求”环节的思维公式。知识付费

前段时间，我跟几位产品新同学讨论一个问题，产品经理的职责是什么？

大家七嘴八舌说了很多，有的说项目管理、有的说功能设计、有的说用户调研，当然，这些都是，其中有个同学回答说：“做需求”，产品经理就是一个做需求的。

我就问他，为什么是做需求呢，他说每一个需求，都是以上这些内容的总和，每一个需求，都包含了用户调研、功能设计、项目管理、资源协调，所以说，产品经理就是做需求的，这没毛病。

可是，做需求只是表象，再往深了想，做需求，其实也是为了解决用户或者客户的实际问题。

因此，我觉得说产品经理的职责是「解决问题」，更准确一点。“解决问题”是产品经理的职责，“做需求”是产品经理工作的主要内容。

那我们就说说“需求”。

需求这个话题聊的人太多了，不少前辈、大佬、专家，都深入阐述过，产品新人入门导师苏杰、刘飞、王诗沐、俞军几位老师，在他们的著作中，也用了大量的篇幅来讲需求。

站在前人的肩膀上，结合自己的一些思考，我也想同读者分享一下，我对于“需求”的理解。

本文从需求的概念、需求的科学理论，到需求的来源，结合做需求过程中的常见误区。

最后推导出“需求”环节的思维公式。全文万字，可能是非常完善的“需求”通识文章了，收藏转发再细看。

01

需求是什么？

生活中，我们经常会有一些行为，这些行为背后，是因为我们有相应的诉求。

临近夏天，天气越来越热，走在街上，忍不住买一根雪糕；

买了一屋子盲盒；

认识到学习的价值，购买了很多付费课程。

以上三个案例，都是最后表现出来的行为。这种行为，分别对应着各自的诉求：

买雪糕是因为热，想要获得降温快感的诉求。

买盲盒是满足收集欲和好奇心的诉求。

买课程是为了满足提升能力、缓解焦虑，然后找到更好工作，或者升值加薪的诉求。

这个“行为背后的诉求”，其实就是需求。所以我们可以给需求下一个定义：需求是行为背后的诉求。

基于这个定义，我们可以发现，任何行业，其实都有需求的概念，需求这件事，不仅仅存在于互联网产品上。

其他的建筑行业、汽车行业、纺织行业等等，都同样通过挖掘用户背后的需求，来实现产品的创新和进步。

对应到产品经理的职业上，我们这个“做需求”，做的是什么“需求”？

产品经理成长过程中，一套思考的全流程，应该是：归纳现象-发现问题-拆解问题-分类问题-提出解决方案-回归分析-发现新问题。

简化来讲，就是：发现问题——归纳核心痛点——解决方案。

这其中的“解决方案”，就成了产品经理工作中所要完成的需求。这是产品经理接触最多的工作内容，也是产品工作的核心。

只有通过优雅高效的解决方案，才能真正解决用户痛点，实现产品经理存在的价值。

02

两个需求理论

正因为“需求”是一个常悟常新的话题，在绵延的历史长河中，也有很多经典的、历久不衰的需求理论。

对于产品经理，有两个非常经典的需求理论，就是“马斯洛需求层次理论”和“KANO模型”。

马斯洛需求层次理论就不用多说了，初高中的时候课本里就提到过。

马斯洛把一个人的需求分为生理需求、安全需求、社交需求、尊重需求和自我实现的需求。

一般来说，这五个需求映射到产品上，则越是金字塔底部的需求，需求面越大，但ARPU可能越小，比如肚子不饿的生理需求，10块钱的炒粉就可以满足。

KANO模型，是东京理工大学教授狩野纪昭(Noriaki Kano)发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

KANO模型把产品需求分成五类：

1. 基础型需求

基础性需求是一个产品最基础的功能，这个需求不能够被满足，则产品就不能正常使用，比如IM软件的打字聊天功能，美颜软件的拍摄功能等等。

2. 期望型需求

期望型需求的效果，是让用户满意度提升。比如微信聊天中的表情包，用户期望有一种俏皮的、不局限于文字的聊天方式，表情包恰好满足了用户这一点。

3. 兴奋（魅力）型需求

兴奋型需求也称为魅力型需求，是超出用户预期的，让用户满意度大幅提升的需求。

比如微信的“拍一拍”和动态表情，用户并没有这个功能的预期，但微信做出来之后，大家也玩儿得不亦乐乎。

还有当年的微信红包，用户突然发现微信中就可以直接发红包了，足不出户，就能完成拜年互动，于是，一个春节，借着红包的力量，微信支付一下子成为可以比肩支付宝的支付平台。

值得注意的是，这五种需求类型，并不是一成不变的，随着行业的进步，他们之间可能会发生转变。

比如微信红包在刚推出时，属于魅力型需求，但随着红包成为趋势，用户也要求其他社交产品做红包功能，这就变成了期望型需求。

4. 无差异型需求

无差异性需求则是用户并不在意的需求，无论有或没有，用户体验都并不会产生较大的影响，用户满意度也并不会提高或降低。

做无差异性需求看似是一个鸡肋的、无意义的行为，但在当下互联网产品大幅度内卷的情况下。

几乎每个平台类APP都在疯狂堆砌这些功能，试图抢占用户时间——打车软件做团购、团购软件做打车、地图软件做购物、工具软件做内容，这大抵就是做产品的岐路罢（当然，实际上也有公司战略的考虑）。

5. 反向型需求

顾名思义，反向型需求就是做了之后，用户体验和用户满意度会下降的需求。

在这里我忍不住要吐槽知乎，现在的知乎，充斥着各种小故事小短文，最关键的是，小故事读着正爽，来了一句“最低0.3元/天开通会员，查看完整内容”，掐死知乎的心思都有了。

值得一说的是，现在的互联网产品中，反向型需求一般是因为商业诉求同用户体验产生了矛盾。

做产品是为了盈利，追求效益无可厚非，而产品经理，就要在商业诉求和用户体验中反复横跳，做放纵与克制间的守夜人。

马斯洛需求层次理论，说得是人性。KANO模型，对应着产品功能。这两个理论经过多年的发展，其内涵已经足够丰富，许多新的产品理论，也大多脱胎于类似的理念，异曲而同工。

这些“新产品理论”中，梁宁老师格外推崇的“痛点爽点痒点”理论，是非常热门的概念。

痛点是恐惧，上班马上就迟到，迟到就要被扣工资，这时候地铁口有一辆共享单车，非常及时地解决了即将迟到的恐惧，这就是痛点；

爽点是即时满足，周六的早晨一觉醒来已经是中午，依然不想起床，躺在床上动动手指，外卖就送到家门口，暂时的快乐得以满足，这就是爽点；

痒点是虚拟自我实现，看着直播里的小姐姐，甜甜地说giegie你好厉害，你立刻幻想到了迎娶白富美，马上一个火箭送出去。

这就是因为满足了用户对于自己的虚拟想象，最近特别流行的“头上长摄像头”短视频，也是一样的道理。

03

需求从哪儿来？

了解了需求是什么，也学习了关于需求的理论，作为一名产品经理，归根结底还是要执行力。

那落到操作层面，需求到底从哪儿来？

需求的来源有很多很多，我把它们先归为两类。一类是正经来源，另一类是不那么正经的来源。

1. 需求的正经来源

在我看来，需求的正经来源，只有两个：用户和数据。

1）需求来源于用户

这是一句每个产品经理都信口拈来的话。产品的存在，就是为了解决用户的问题，用户所面临的这些问题，肯定都得从用户当中去发现。

而对于产品来说，需求阶段是整个产品生命周期中的孕育期，需求能否准确命中，决定着一个功能乃至一个产品的生死。

2）需求同样也来源于数据

在数据时代的今天，每一个人都是数据大网下的一个节点，最关键的是，通过用户的数据，能够更好地发现用户的群体行为，从而找准大多数用户的真正需求。

某种意义上来讲，数据中找到的用户需求，比直接和用户访谈、调研得到的数据更真实。

为什么需求要来源于数据？是因为，“用户”是会骗人的呀。业内有一个非常经典的栗子：

索尼要为一款即将面市的游戏机做一个调研，请了很多目标用户来公司，收集用户对于样品的反馈。

其中一项就是询问用户希望这款游戏机是什么颜色（有黄色及黑色），很多人在被问及这个问题时，都答了黄色，索尼就认为，黄色的游戏机更收欢迎。

但最后，访谈结束时，索尼公司提出，用户可以从门口随意挑选一个颜色的游戏机带走，以感谢他们参加此次用户访谈，结果时候统计数据却发现，用户们在实际挑选时，纷纷选择了黑色的游戏机。

用户调研的需求具体生动，但有可能因为样本太小并不真实；数据分析得到的用户行为，样本足够统计准确，却略显僵硬并不鲜活。

其实，在做产品需求的过程中，用户和数据，都是为了更好地满足用户需要，应当两种来源结合使用、交叉验证。

用户是微观，定性；数据是宏观，定量。

2. 需求的不正经来源

虽然严格来说，用户需求都来源于用户和数据，但其实在真正的产品工作中，也有很多需求是来源于其他渠道，毕竟生活和工作不可能时时刻刻都处在理想状态。

我之所以称它们为“不正经来源”，倒也不是说这些来源不好，而是表示，它们不像用户和数据这样“科班理论”。

1）竞争对手

实际工作中，确实很多需求，都来源于竞争对手。

“我们为什么要做这个功能？是因为竞品这么做啦！这个功能为什么这样做？是因为竞品就是这么做哒！”这种想法当然不对，但也不是说，做需求不能看竞品。

相反，持续进行竞品的监控分析，能够获得很多需求灵感，而且，竞品的新功能也是在付出成本帮助我们去做验证，如果效果OK，那我们去借鉴参考，也不是什么坏事。

所以，需求来源于竞争对手，核心在于思考竞品为什么这么做，我们可以从中学习什么优点，辩证批判地看待竞品的动作。

2）产品经理拍脑袋

不得不说，挺多需求确实是拍脑袋拍出来的……原因挺多的，但也要尽量避免。

3）协同部门

尤其是体量比较大的产品，产品经理距离客户/用户的距离，其实没有那么近，一线的很多用户反馈，往往并不能直接传达给产品团队。

大多数情况下，是销售、客服、市场等协同部门的同事去响应。所以，协同部门就会定期向产品团队反馈需求。

协同部门提出的需求，一般分为两类，一类是“用户希望怎样”，一类是“我们（协同部门）希望怎样”。

前者，是一线协同部门把用户反馈过来的问题，传递给产品团队；后者，则是一线部门为了自身的KPI或者工作量，而提出的需求。

比如销售部门为了更好的售卖产品，就会不断反馈要求获得产品中更多的入口、更多的弹窗。

针对协同部门的需求，产品经理要做的，首先是要分类整理，判断哪些需求是产品真实存在的问题，哪些是协同部门对于产品规则理解不深刻的问题。

针对用户真实存在的问题，又要往深层次思考，用户的核心诉求是什么，进而根据优先级，提出产品方案。

4）客户直接提出的功能需求

有时候客户或者用户反馈问题时，会直接提出一些具体的功能建议：希望在XXX处做一个XXX功能。

这个来源能够收到的需求非常多，毕竟“人人都是产品经理”嘛，每个人都能对产品提点功能建议。

针对这种来源的需求，产品经理要做的，不是照单全收，而是得认真归类分析，找到问题背后的真实来源，进而提出优雅的产品解决方案。用户很热，想买雪糕。

但她正好在姨妈期，如果直接听用户的，就会导致她肚子疼，这个时候，产品经理可以带她去吹空调，解决“热”的问题。

“热”是核心问题，“吃雪糕”和“吹空调”都是解决方案，选择哪个解决方案，要结合具体的情况而定（风险提示：这里就是举个例子，谈恋爱不能太“产品思维”）。

你看，同样是用户提出的反馈，认真分析后找出需求，就叫用户访谈，就是正经的需求来源。

不加分析直接采用，就是不正经的需求来源，容易踩雷，你说有不有趣。

话说回来，这些不正经来源，其实深溯一下，很多也还是来源于用户和数据。

比如需求来源于竞争对手，其实只不过是竞争对手的产品经理完成了需求收集，这个需求，来源于竞争对手的用户。

需求来源于客户的具体建议，那也是表达出客户对于当前功能的不满，这种不满背后是什么样的原因，这个原因就是真正的需求。

无论是需求来源于老板还是竞争对手，产品经理都应该想一想，这个需求到底是从何而来。

老板提出了这个需求，那老板是出于什么样的考量？看似降低了这一个小功能的体验，但有没有可能，是为了全公司战略的联动？

竞争对手做了这个功能，有没有可能这就是竞争对手的产品经理拍脑袋拍出来的，我们到底要不要跟进？

04

需求的误区

既然明确了需求的来源，我们就可以推导出，一个需求的思维公式，从而快速准确地找到核心需求。

但在归纳之前，我们不如先用一种逆向思维，来看看“需求”阶段中的错误示范，五个常见的需求误区，这能够帮助我们更好的理解需求，避免走上弯路。

1. 误区一：自己代表用户

前段时间有一个问题讨论得特别火，“产品经理要不要变成自己产品的用户？”

有正方认为产品经理只有是产品的核心用户，才能更好地找到目标用户的痛点。

反方则认为，对于产品经理来说，冷峻理智地站在上帝视角，才是把产品做好的重要法门。

其实对于这个问题，往深层次思考其实是产品经理的同理心。

产品经理既需要客观全面的看待整个产品，也需要瞬间把自己切换到用户视角来提升体验和发现漏洞，对用户有同理心，能够站在用户的视角看待需求。

产品经理本身就是这样一个反复跳转的角色，小白用户、资深用户、产品上帝、老板视角，等等等等，这些角色可能每天都要转变几十次。

用户视角看产品，是发现产品问题的一个妙招，但过于依赖这个办法，就会走火入魔。

很多产品经理恰好是自己产品的受众，这是一件非常幸运和幸福的事情，但这种情况下，就要格外注意，你要做的功能，是你自己的需求，还是用户的需求？

在产品经理自认为自己是目标用户后，往往会陷入“我自己就是用户，我能代表目标用户群体”这个死胡同当中。

最后的结果当然是一场赌博，意外命中了群体需求，那就赚了；如果没赌中，可能就是一个鸡肋的功能，在后期做减法的时候痛不欲生。

这个误区归根结底还是需求调研不充分的问题，依赖主管臆断，陷入经验主义，导致需求偏向。

2. 误区二：确定了产品强行找用户

有人可能会觉得，这是一个很低级的问题，但就是这样一个低级的问题，几乎每时每刻都在发生。

理想主义的产品经理会以为，一个需求一定要来源于用户痛点，但现实是，每天都有无数的产品或功能。

是因为老板拍脑袋、公司要求强行创新、KPI压力负重、业务战略需要、圆之前融资画得大饼，而匆匆上马的。

我之前做过一个产品，是因为老板觉得小众音乐在未来很有市场，应该做一个产品提前占位，就立项了一个创新项目。

先定了小众音乐这条赛道，才开始想满足什么需求，甚至才开始为了这个已经定好了方向的项目招聘产品经理。

但现实情况是，产品的痛点和需求并非源自实际的用户群体，只能根据竞品先做了一些功能，然后开始想，哪些用户可能喜欢这些功能，这样倒推回来。

确实能够找到一个差不多的目标用户群体写在MRD、PRD里。

但事实呢，这些“先有了功能后定下来的目标群体”本身没有任何的动力使用产品。

结局自然是可预料的，公司砸钱砸出来几万用户，补贴一停用户就流失，产品就这么不了了之，后来业务调整裁撤了。

需求还是一定要来源于用户的，即使是来自老板的要求，也得在公司战略和用户痛点当中尽力周旋，先有需求后有产品，这个顺序不能乱。

3. 误区三：只抓住表象，不能深层次思考需求背后的动机

在拿到一个需求时，我们要思考，这个需求深层次的动机是什么。

我刚做产品的时候，经常会被用户提得反馈牵着走，用户经常会说，“这个功能有问题，应该这样做那样做”，我一听还觉得挺有道理，就被带跑了。

但其实不应该这样，用户或者老板在提出一个需求的时候，我们要深层次地想一想，他们为什么提出这个需求，是有更多的期待没有被满足，还是这个功能的流程逻辑有漏洞。

用户的需求反馈往往带着主观的影响，一些有想法的用户在提反馈的时候，也会带上一个设想的解决方案。

毕竟“人人都是产品经理”，但作为职业的产品经理，还是要理智地思考思考，把需求背后的动机挖掘出来，才能解决更核心的问题，才能提高更多用户的体验。

之前在写互联网销售的文章中，我引用过“卖钻讲孔”的故事，其实这个故事是从王诗沐老师的《幕后产品》中学到的。

客户要买一个钻头，我们应该看到他买钻头是想打一个孔，他的真正需求是打孔。

我们如果能够给他提供一整套打孔的解决方案，是不是更加符合客户的心意？这样深挖需求动机的思考，是职业产品经理所不能绕开的。

4. 误区四：以偏概全，以孤例代表整体，陷入小众用户的自我束缚

对于产品经理来说，因为产品要服务的用户很多，即便都是同一类目标用户，也会因为用户的圈层而产生需求的差异。

产品经理不可能面面俱到每一个用户，因此就必然要在功能上予以取舍。

小众用户的需求是需求吗？当然是，即使是小众的需求，也应当纳入产品经理的需求池当中。

但是否要做、什么时候做、怎么做，这三个问题还是要想清楚。

相对于“自己代表用户”这个误区，小众需求确实是命中了需求，但小众需求无法与大众市场相连接，从更宏观的视角来看，性价比并不高。

做一些小众需求，的确能够产生比较不错的口碑，但把过多的精力和资源放在小众需求上，某种程度也是在伤害主流用户的体验。

需求的把握同样需要遵循二八法则，即优先满足80%用户的主流需求，优先考虑更大众化的痛点，保证大多数用户的体验。

至于小众需求怎么处理，有两种思路。

一种是先暂时延期，等到大众需求基本满足，产品主流用户增量见顶，开始寻找额外增量的时候，通过满足小众群体的需要，来寻求产品突破点。

另外一种则是找到小众需求和大众需求的相通之处，深入挖掘深层次需要，既提高了主流用户的体验，同时也用一种更加优雅的方式解决了这些小众需求。

5. 误区五：需求确实存在，但不符合产品整体目标

我们常说产品经理是CEO的预科班，做一家公司，必须要明确公司的目标、愿景，对于一个产品来说，思考它的整体目标是一件至关重要的事情。

正如前面所说，产品经理会面临各种各样的需求，有真需求、有伪需求，有大众需求、有小众需求，有商业需求、有性能需求，面对这么多需求，如何取舍如何排序就是一个关键的问题。

对于这些数不清的待办需求，产品经理要做到心中有数。需求池当中的这个需求，能否在产品长期目标的主线上发挥作用。

如果需要开启一个支线的产品目标，那这个支线的投入和产出又是如何。产品经理不仅要为用户体验负责，也需要对产品良性发展负责。

可能会有同学说，思考产品长期目标是产品总监的事情，新手期产品经理做好自己的事情就可以了。

但其实，即使初级产品经理没有权力做出产品目标的相关决策，至少也可以把自己放在更高的视野做做沙盘推演，学会用更大的视野思考整条业务线的宏观目标，对于一个产品经理的成长，会非常有帮助。

05

需求的思维公式

我们根据需求的定义、来源、误区，可以抽象出需求的思维要素。

我给出这样一个公式：需求=目标人群+场景+痛点/问题+解决方案

一个完整的需求，应当是有特定的目标人群，在特定的场景下，发现特定的问题，并提出针对这个问题的解决方案。

任何一个需求，都不能脱离这四个组成部分。

1. 目标人群

目标人群代表着“什么人”的问题。任何一个产品，都一定是面向某一个群体，而不是面向所有人，因为人和人的诉求，不可能完全一致，会因为性别、年龄、学历、收入水平、从事行业等许多因素，产生差异。

因此，一个需求面向的人群一定是有一个范围的，比如“找互联网工作的人”“骑行爱好者”等等。

2. 场景

即使是圈定了目标人群，也并不能说，这个目标人群的用户群体在任何时刻都存在这个需求，场景就是“什么时候”有这个需求。

就以打电话这个需求为例，打电话是“需要和他人远程沟通”这个场景下的诉求，其他时候，用户是不需要打电话这个功能的，我们不能苛求用户所有时刻都在打电话。

场景还有一个重要特性，就是用户具体怎么使用这个功能。比如用户在支付时进行扫码，就是在“支付”场景下，用了“扫一扫”的功能。

有时候，用户天然产生的场景不够多，那我们就可以创造场景。

比如支付宝为了更多的使用场景，投资了哈罗单车，提供了支付宝直接扫码就可以骑车的功能，于是，就创造出了一个新的使用支付宝扫一扫的场景。

3. 痛点/问题

明确了目标人群和场景，还要知道，这一些人 在 这个场景 下，遇到了什么问题，只有把问题找准了，才不会马屁拍在马蹄子上。

比如：西二旗上班的白领（目标人群），出了地铁口距离公司还有一公里，马上就要迟到了（场景），走路来不及，打车打不到（遇到的问题）。

这个时候，帮助用户快速到达公司不至于迟到，就是要解决的问题。

4. 解决方案

找到了问题，那就要提出需求中最核心的“解决方案”，产品终归是要解决用户问题的。

要不然，找到了一堆问题，一个都不解决，那依然没什么用。这一群人，在这个场景下，遇到了问题，你打算用什么方法解决。

值得注意的是，解决方案不一定有一个，而且大多数情况下，是有多个。产品经理就要在这多个解决方案中，找到最合适的那个。

还是白领迟到这个例子，最后一公里，走路来不及，打车打不到，我们可以给一个共享单车的解决方案，也可以给通勤摆渡车的解决方案。

分析之后发现，上班高峰容易堵车，摆渡车依然有迟到风险，所以，最后给用户提供了共享单车的解决方案，帮助用户解决了问题。

一般情况下，大部分需求，都可以用这个思维公式进行提炼。但任何产品理论都是教科书式的知识，在实际工作中，还是要灵活应用，具体问题具体分析。

以上，就是关于“需求”模块下，我的总结、分析和思考，逐渐形成的一点小体系。

但依然不够完善，我也会在后面的工作中，持续反思完善。