前段时间，我和几位新来的产品同学讨论过一个问题：产品经理的职责是什么？大家说了很多，有的说项目管理，有的说功能设计，有的说用户研究，当然，这些都是，其中一位同学回答说：“做需求。”产品经理就是做需求的人。

我问他为什么要处理需求，他说每一个需求都是上面内容的总和，每一个需求都包含用户调研、功能设计、项目管理、资源协调等，所以产品经理按要求去做是没有错的。

然而，满足需求只是表面现象，如果再深层次思考，满足需求其实就是为了解决用户或者客户的实际问题。因此，我觉得更准确的说法是，产品经理的职责是“解决问题”。解决问题是产品经理的职责，“满足需求”才是产品经理工作的主要内容。

那么我们来谈谈“需求”。

关于需求这个话题，讨论的人太多了，很多前辈、大佬、专家都深入阐述过，产品新人导师苏杰、刘飞、王诗木、余俊等也在自己的作品中使用过这个术语，用了不少篇幅讨论需求。站在前辈的肩膀上，结合自己的一些思考，我也想跟读者分享一下我对“需求”的理解。

本文从需求的概念、需求的科学理论、需求的来源，结合需求过程中常见的误区，最终得出“需求”环节的思维公式。全文一万字，可能是一篇非常完整的关于“需求”的概括性文章，请大家保存转发，以便仔细查看。

1. 需求是什么？

在生活中，我们常常会出现某些行为，而这些行为的背后是因为我们有相应的诉求。

以上三种情况都是最终体现出来的行为，这种行为对应着他们自身的诉求：买冰淇淋是因为天热，想获得降温的快感；买盲盒是为了满足收藏欲和好奇心；人们买课程是为了提升自己的能力，缓解焦虑，进而找到更好的工作，或者获得升职加薪。

这种“行为背后的需求”其实就是需求。所以我们可以对需求做出如下定义：需求就是行为背后的需求。

基于这个定义我们可以发现，其实任何一个行业都是有需求这个概念的，需求不仅仅存在于互联网产品中，其他行业如建筑、汽车、纺织等也都需要有需求才能实现产品的创新和进步。

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

在产品经理成长过程中，整个思考的过程应该是：总结现象-发现问题-拆解问题-归类问题-提出解决方案-回归分析-发现新问题。简单来说就是：发现问题-总结核心痛点及解决方案。

这里的“解决方案”就成为了产品经理需要完成的要求，这是产品经理接触最多的工作内容，也是产品工作的核心，只有通过优雅、高效的解决方案，才能真正解决用户痛点，实现产品经理的价值。

2.两种需求理论

因为“需求”是一个不断变化的话题，在历史长河中有着很多经典而经久不衰的需求理论。对于产品经理来说，有两个非常经典的需求理论，分别是“马萨诸塞洛氏需求层次理论”和“KANO模型”。

初中、高中课本上都有讲到的马斯洛需求层次理论，这个就不用多说了，马斯洛把人的需求分为生理需求、安全需求、社交需求、尊重需求、自我实现需求。

一般来说，这五种需求映射到产品上，越靠近金字塔底层的需求，需求量越大，但ARPU值可能越小，比如不饿这个生理需求，10块钱一碗炒面就能满足。

KANO模型是东京工业大学的狩野典明教授发明的一种对用户需求进行分类和优先排序的有用工具，它以分析用户需求对用户满意度的影响为基础，反映了产品性能与用户满意度之间的非线性关系。

KANO模型将产品需求分为五类：

1. 基本需求

基本需求是一个产品最基本的功能，如果这个需求得不到满足，产品就无法正常使用，比如IM软件的打字聊天功能，美颜软件的拍摄功能等等。

2. 预期需求

预期需求带来的效果就是提升用户的满意度，比如在微信聊天中，用户期待一种不局限于文字的、好玩的聊天方式，表情包正好满足了这一需求。

3. 刺激（魅力）需求

刺激性需求也叫吸引性需求，是超出用户预期，大大提升用户满意度的需求，比如微信上的“点按”和动态表情，用户原本是没有想到的，但微信推出之后，用户却被吸引了，大家都玩得很开心。

那一年还有微信红包，用户突然发现，在微信上直接就能发红包，足不出户就能完成拜年，因此在春节期间，微信支付借助红包的力量，成为了与支付宝相媲美的热门支付平台。

值得注意的是，这五类需求并不是一成不变的，可能会随着行业的进步而发生变化，比如微信红包刚推出时是魅力型需求，但随着红包成为一种潮流，用户也要求其他社交产品也具备红包功能，从而成为一种预期需求。

4. 需求无差别

无差异需求是用户并不关心的需求，无论有无此类需求，都不会对用户体验造成很大影响，用户满意度也不会增加或减少。

满足无差异化需求看似无用且毫无意义的行为，但在互联网产品快速内化的当下，几乎每个平台型APP都在疯狂堆砌这些功能，试图抢占用户的时间。团购软件用来做团购，团购软件用来打车，地图软件用来购物，工具软件用来做内容。这大概就是产品发展的不同路径吧（当然也有公司战略的考虑）。

5. 反向需求

反向需求顾名思义就是实现之后用户体验和用户满意度会下降的需求，这里忍不住吐槽一下知乎，现在知乎上充斥着各种小故事、短文，最主要的是，我正津津有味地看着小故事，突然来了一个消息说“每天最低只要0.3元成为会员，即可查看完整内容”，看得我恨不得掐死知乎。

值得一提的是，在目前的互联网产品中，逆向需求一般都是业务需求和用户体验冲突导致的。产品是为了盈利而做，追求效率无可厚非，但产品经理需要平衡业务需求和用户体验，在中间来回跳跃，做放纵与克制之间的守望者。

马斯洛需求层次理论讲的是人性，KANO模型对应的是产品功能，经过多年的发展，这两个理论的内涵已经足够丰富，很多新的产品理论也大多源于类似的概念，目的是一样的。

在这些“新产品理论”中，梁宁先生特别提倡的“痛点、快感点、痒点”理论是一个非常流行的概念。

3.需求从哪里来？

明白了什么是需求，也了解了需求理论，作为产品经理，最重要的就是执行。那么对于运营来说，需求从哪里来呢？

需求的来源有很多，我将其分为两类：一类是合法的来源，一类是不太合法的来源。

1. 合法的需求来源

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

1）需求来自用户

这是每个产品经理都能轻松脱口而出的一句话，产品的存在就是为了解决用户问题，用户面临的问题必须从用户身上去发现，对于产品来说，需求阶段是整个产品生命周期的孕育期，能否精准满足需求决定了一个功能甚至一个产品的生死存亡。

2）需求也来自数据

在如今的数据时代，每个人都是数据网络中的一个节点，最重要的是通过用户数据，我们可以更好地发现用户的群体行为，从而发现大多数用户的真实需求。从某种意义上来说，在数据中发现的用户需求比直接对用户进行访谈、调查得到的数据更加真实。

为什么需求要从数据中来？因为“用户”是会骗人的。业界有个很经典的例子：

索尼准备针对一款即将发布的游戏机做一次调查，他们邀请了不少目标用户到公司来收集用户对样品的反馈。其中一个问题是询问用户希望游戏机是什么颜色（有黄色和黑色两种）。当被问到这个问题时，很多人回答黄色，因此索尼认为黄色的游戏机更受欢迎。但在采访的最后，索尼提出用户可以从门中任意选择游戏机颜色。我们去感谢他们参与用户采访，但在统计资料时发现，用户真正做出选择时，都选择了黑色的游戏机。

用户研究的需求具体而生动，但可能因为样本量太小而不真实；数据分析得到的用户行为虽然统计准确，但略显死板，不够新鲜。两种来源应该结合使用，进行交叉验证，才能更好地满足用户需求。

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

2. 非法需求来源

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

我之所以称他们为“非正统来源”，并不是说这些来源不好，而是说他们不像用户和数据那样“书呆子气”或“专业”。

1）竞争对手

在实际工作中，很多需求确实来自于竞争对手，“我们为什么要开发这个功能？因为竞争对手就是这样做的！这个功能为什么要这样做？因为竞争对手就是这样做的！”这种想法当然是不对的，但并不代表在制定需求的时候不能看看竞品。

相反，持续监控和分析竞品，能为需求提供很多启发。而且，竞品的新功能也在付出成本帮我们验证，如果效果还行，那我们学习一下也未尝不可。需求来自于竞争对手，关键是要思考竞争对手为什么这么做，我们能从中学习到什么优势，辩证批判地看待竞争对手的行为。

2）产品经理根据自己的想法做出决策

我必须承认，很多要求确实是一时兴起提出的……造成这种情况的原因有很多，但我们应该尽量避免。

3）协作部门

尤其是对于规模比较大的产品，产品经理和客户/用户的距离其实并没有那么近，很多一线的用户反馈往往不会直接传达给产品团队，大多数情况下是销售、客服、市场等协同部门的同事会做出回应。因此，协同部门会定期将需求反馈给产品团队。

协同部门提出的需求一般分为两类：一类是“用户想要什么”，一类是“我们（协同部门）想要什么”。

前者是一线协同部门将用户反映的问题传递给产品团队；后者是一线部门对自身KPI或者工作量提出的要求，比如销售部门会持续反馈，需要在产品里多开一些入口，多开一些弹窗。

对于协同部门的需求，产品经理首先要做的就是进行分类梳理，哪些需求是产品真正的问题，哪些是协同部门对产品规则理解不透彻的问题。深入思考用户最核心的诉求是什么，然后根据优先级提出产品解决方案。

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

有时候客户或者用户反馈的时候，会直接提出一些具体的功能建议：希望在XXX做成XXX功能，这个来源可以接到很多需求，毕竟“人人都是产品经理”，每个人都可以为产品提出功能建议。

对于这种需求，产品经理不应该全部接受，而应该仔细归类分析，找到问题背后真正的根源，然后提出优雅的产品解决方案。但她恰好处于生理期，如果直接听用户说，她会肚子疼。这时候，产品经理可以带她去用空调，解决“热”的问题。

“热度”是核心问题，“吃冰淇淋”和“用空调”都是解决方案，具体选择哪种方案，要看具体情况（风险警告：这只是举例，约会时别太“产品主义”）。

你看，同样是用户的反馈，如果我们认真分析，找出需求，这就叫用户访谈，这是正当的需求来源；如果我们不加分析，直接采纳，这就是不正当的需求来源，很容易踩雷。是不是很有意思。

也就是说，如果我们追溯这些非官方的来源，会发现其实很多都是来自于用户和数据，比如说需求来自于竞争对手，其实只是竞争对手的产品经理完成了需求收集，这个需求来自于竞争对手的用户；需求来自于客户的具体建议，也表达了客户对目前功能的不满，这种不满背后的原因是什么？这个原因才是真正的需求。

不管这个需求是来自老板还是竞争对手，产品经理都要思考这个需求从何而来。老板提出了这个需求，那么老板的考虑是什么？功能体验，但有没有可能是为了整个公司战略的联动？如果竞争对手开发了这个功能，有没有可能只是竞争对手的产品经理一时兴起想出来的？我们是否也要效仿？

4. 对需求的误解

现在我们确定了需求来源，就可以推导出一个需求思维公式，快速准确地找到核心需求。但在总结之前，我们先用逆向思维来看一下“需求”阶段的错误论证，五个常见的需求误区，可以帮助我们更好地理解需求，避免走弯路。

1. 误解一：代表用户

前段时间有一个热议的问题：“产品经理是否应该成为自己产品的用户？”有些人认为，产品经理只有成为产品的核心用户，才能更好地识别目标用户的痛点；另一些人则认为，对于产品经理来说，保持冷静和理性的鸟瞰视角，才是做好产品的关键。

其实，我们深入思考这个问题，其实这是一个产品经理的同理心。

产品经理需要客观全面地看待整个产品，也需要时刻切换到用户视角，改善体验，寻找漏洞。需要对用户有同理心，能够站在用户的角度看需求。你跳转的角色有新手用户、资深用户、产品大神、老板视角等等，这些角色一天可能变换几十次。

站在用户的角度看产品是发现产品问题的好方法，但过分依赖这种方法容易陷入执念。很多产品经理恰好就是自己产品的受众，这是非常幸运和幸福的事情，但这种情况下，你要特别注意，你要开发的功能是自己需要的还是用户需要的？

产品经理认为自己是目标用户之后，往往会陷入“我自己就是用户，我能代表目标用户群体”的死胡同。最后的结果当然是一场赌博，如果不小心击中了群体需求，那就算赚了。如果赌输了，可能就只是一个没用的功能，后期做减法的时候就会很痛苦。

这种误解最终源于需求研究不足、依赖主管假设和经验主义，从而导致需求偏差。

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

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

理想主义的产品经理会认为需求一定是来自用户痛点，但现实是，每天都有无数的产品或功能因为老板的冲动、公司的倒逼创新要求、KPI压力、商业战略需要等各种因素被创造出来，前几次融资都看好，但项目却匆匆上线。

我之前做过一个产品，因为老板觉得小众音乐未来会有很大市场，要提前做一个产品占领市场，所以我们就立了一个创新项目。需求是什么？我们甚至开始为这个项目招产品经理，已经确定了方向。

但现实是，产品的痛点和需求并非来自于实际的用户群体。我们只能根据竞品做出一些功能，然后开始思考哪些用户可能会喜欢这些功能。通过逆向思维，我们确实可以找到类似的用户群体。MRD和PRD中都写着目标用户群体。但事实是，这些“功能上线后确定的目标群体”根本没有使用产品的动力。结局自然是可以预见的，公司花了好几万块钱打造了一个产品，补贴一停，用户就走了，产品被抛弃了，后来业务调整，产品停产了。

需求必须来自用户，哪怕是老板的要求，也要尽力平衡好公司策略和用户痛点，先有需求，再有产品，顺序不能乱。

3. 误区三：只抓表面，没有深入思考需求背后的动机

当我们接到一个需求的时候，我们需要思考其背后更深层次的动机。

我刚开始做产品的时候，经常被用户的反馈牵着鼻子走。用户经常会说“这个功能有问题，要这样或那样做”。我以为很有道理，结果就被误导了。但不应该这样。当用户或老板提出需求时，我们需要深思他们为什么提出这个需求。是不是有更多的期望没有得到满足，或者这个功能的流程逻辑是否存在漏洞？

用户反馈往往带有主观影响，一些有思想的用户在反馈时也会带上假设性的解决方案，毕竟“人人都是产品经理”，但作为专业的产品经理，我们需要理性思考，挖掘需求背后的动机，才能解决更多核心问题，提升更多用户的体验。

我在之前关于网络销售的文章中引用了“卖钻头讲孔”的故事，其实这个故事我是从王诗木老师的《产品幕后》中学到的。

如果客户要买钻头，我们要知道他要的是打一个孔，他真正的需求就是打一个孔，如果我们能给他提供一整套的打孔解决方案，那不是更符合客户的意愿吗？思考需求动机是专业的产品经理绕不开的事情。

4. 误区四：以偏概全，陷入小众用户的自我约束

对于产品经理来说，因为产品要服务很多用户，即使是同一个目标用户，也会因为用户圈子不同而存在需求差异，产品经理不可能去迎合每一个用户，所以必须在功能性上面进行取舍。

小众用户的需求是不是真正的需求?当然，即使是小众需求，也应该纳入产品经理的需求池中。

但到底做不做、什么时候做、怎么做，我们还是要想清楚，相比“代表用户”的误区，小众需求确实击中了需求，但小众需求无法和大众市场对接，从更宏观的角度看，性价比并不高。

满足一些小众需求确实能产生比较好的口碑，但把过多的精力和资源放在小众需求上，也会一定程度上伤害主流用户的体验。需求的把握也需要遵循80/20法则。即优先满足80%用户的主流需求，优先解决比较大众的痛点，保证大多数用户的体验。

至于如何处理小众需求，目前有两种思路，一是暂时推迟，等到大众需求基本满足，产品主流用户的增量已经见顶，开始寻找额外增长的时候，再去满足小众群体的需求来寻求产品突破；二是寻找小众需求和大众需求的共通点，深挖深层次需求，这样既能提升主流用户的体验，也能用更优雅的方式解决这些小众需求。

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

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

前面提到，产品经理会面对各种各样的需求，有真需求、假需求、大众需求、小众需求、商业需求、业绩需求。面对这么多的需求，该如何取舍？排序是一个关键问题。

产品经理需要对这些无数个待处理的需求有一个清晰的认识，需求池里的这个需求，是否能在产品长远目标的主线上发挥作用？如果需要开辟一个分支产品目标，那么这个分支的投入和产出怎么办？产品经理不仅要对用户体验负责，更要对产品的良性发展负责。

有同学可能会说，思考产品的长远目标是产品总监的职责，新手产品经理做好自己的事就行了。但其实，即便初级产品经理不具备产品目标相关决策权，至少可以把自己放在更高的层次上，做沙盒模拟，对于一个产品经理的成长会很有帮助。学会用更广阔的视角去思考整个业务线的宏观目标，对于一个产品经理的成长会很有帮助。

5.需求思维公式

基于需求的定义、来源、误解，我们可以抽象出需求的思维要素。我给出一个公式：需求=目标群体+场景+痛点/问题+解决方案

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

任何需求都离不开这四个要素。

1. 目标群体

目标人群指的是“谁”的问题。任何产品一定是针对某一特定人群，而不是所有人，因为人们的诉求不可能完全一致，会有性别、年龄、学历、收入等差异，导致差异的因素有很多，比如水平、行业等。所以一个诉求一定是针对一定范围的人群，比如“寻找互联网工作的人”、“骑行爱好者”。

2. 场景

即使确定了目标群体，也不能说这个目标群体的用户群体在任何时候都有这个需求，场景是“什么时候”有这个需求。就拿打电话的需求来说，打电话是一种“需求”，在“远程与他人沟通”的场景下，用户在其他时间并不需要打电话这个功能，我们也不能要求用户时刻打电话。

场景化的另一个重要特征是用户如何使用功能，例如用户在支付时扫码支付，在“支付”场景下会用到“扫一扫”功能。

有时候用户自然生成的场景不够多，我们可以创造场景。比如支付宝投资哈罗单车来拓展使用场景，提供用支付宝扫码骑自行车的功能，目前已经上线了支付宝扫码骑行的新场景。

3. 痛点/问题

明确了目标人群和场景之后，你还需要知道这些人在这个场景中遇到了什么问题，只有正确识别问题，才能避免马虎了事却一事无成。

比如，一位在西二旗上班的白领（目标人群）上班快迟到了（场景），因为他离地铁站有一公里远，走路也走不了，打车也打不到（遇到的问题）。要解决的问题是让用户快速到达公司，不迟到。

4.解决方案

问题找到之后，就应该提出需求中最核心的“解决方案”，毕竟产品就是为了解决用户的问题，不然发现一大堆问题却一个都没解决，那也是白费力气。这种场景下，如果遇到问题，你打算怎么解决呢？

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

我们举个白领迟到的例子，最后一公里走路来不及，打不到车，我们可以提供共享单车的解决方案，也可以提供通勤班车的解决方案，我们分析之后发现上下班高峰堵车的风险很大，班车还有迟到的风险，所以最后我们给用户提供了共享单车的解决方案，帮助他们解决问题。

一般来说，大部分需求都可以用这个思维公式来细化，但是任何产品理论都是课本知识，实际工作中需要灵活运用，具体问题具体分析。

以上就是我在“需求”模块下经过总结、分析、思考逐渐形成的一个小体系。但还不够完善，我会在今后的工作中不断反思、完善。