当我们在做一个产品的时候，我们在研究人性，而不是说在研究一个产品的逻辑。
——张小龙
如果让大家总结“产品经理”这个岗位的关键词，“需求”一定是一个高频出现的答案。
身为产品经理，日常的工作中，离不开”需求“两个字：
- 对用户，你要调研ta的需求；
- 拿到调研问卷或者是数据之后，你需要分析ta的需求；
- 对研发，写完PRD画完原型后，你需要讲需求、提需求；
- 不同产线的资源冲突了，你需要对需求进行排序；
- 方案变化了，你又要改需求。
既然需求天天陪伴在身边，我希望在产出这篇文章的时候，对“需求”进行一次深入的反思，回答如下问题：
- 需求是什么
- 需求的来源
- 需求的特性
- 需求如何获取
- 需求如何分析
- 需求如何分类及排序
- 需求池包含哪些信息
1、需求是什么
在产品经理的工作语境中，在不同的场景下，“需求”分别指代不同的东西。需求，对应的英文单词有4个：Want、Needs、Requirements、Demand。
如果说这4个单词对应的关系，大概是：
Want→Needs→Requirements→Demand
Want：
- 用户想要某物的渴求或欲望。
- 是用户说ta想要的东西。
- 我们可以更精确地称之为”表层用户需求”
Needs：
- 用户欲望原始的动机成因，用户的心理诉求。
- 是产品经理分析出来的。
- 我们将之称为”深层用户需求“
Requirements：
- 根据Needs产生的对产品的设计要求。
- 是产品经理设计出来的
- 我们将之称为”产品需求“
Demand：
- 产品生产出来之后市场上的需求量。在经济学上，有清晰的定义：”一定周期内、一定价格水平下，消费者愿意并且能够购买的商品数量。
- 我们将之称为”产品需求量“。
举一个实际的例子：
I want a lot of money because I need happy.
表层用户需求为：希望得到更多的钱。
深层用户需求为：希望更开心。
产品经理主要做的事情就是：基于用户的want（表层用户需求），挖掘出needs（深层用户需求），设计出requirements（产品需求）。
孙陶然在《创业的36条军规》里说了这样一句话：
创业一定要解决真需求，不要做伪需求。怎么区分真需求伪需求？用中文不太好区分，但用英文就很清晰：伪需求叫want，真需求叫need。Want的东西，用户不一定会掏钱，need的东西，用户一定会愿意掏钱。所以need的东西，才应该是我们应该切入的事情。
2、需求的来源
关于需求，张小龙曾经说过：
需求不来自于调研，需求不来自于分析，需求不来自于讨论，需求不来自于竞争对手，需求只来自于对用户的了解。
需求来自于用户的心理诉求，也可以说是来自于人性，人性由先天天性+后天经历共同塑造。每个人的后天经历不同，这是造成人与人之间差异的主要影响因素。人的先天天性也不尽相同，但是却有一些共性是刻在骨子里，留在血液里，动物性的，我们可以基于此去探讨需求的一些共性：
2.1、人想要的是什么
所有生物的底层需求是繁衍和永生，它也是人类天性中最本源的需求。对于人类来说，有三种“永生”的形式：
- 个体的长生不老。
- 肉体泯灭，精神长存。
- 繁衍子孙。
没有人能够做到长生不老，少数人能够通过著书立说、丰功伟业达成精神长存的境界，绝大多数人都只能通过子孙繁衍将自己的DNA进行一代一代的传承。而人类的所有其他需求都是基于此衍生出来的。
很多世人忙忙碌碌为钱奔波，看起来是为了生活条件变得更好，它背后隐藏的目的则是：让自己有更好的择偶对象，让子女后代活得更好遗传信息得以更完善的保留。
肯定有人反驳：“我为自己而活”，还会有人举出一些显著的反例，比如丁克、同性恋等等。其实这些大多是由后天的经历影响产生。
条条大路通罗马，人类在多种路径上进行了为达成繁衍和永生的尝试，而需求，就存在于这些路径之上。接下来，着重探讨一些”需求的大多数“：
2.2、对于美的追求
美是什么
“美是什么”，这是一个千古之谜，很难回答，甚至诞生出来了一个叫”美学”的学科专门研究美。
伏尔泰认为有两种美：
- 一种是不稳定的，相对的。他说：“美往往是非常相对的，在日本是文雅，在罗马就不文雅；在巴黎是时髦的，在北京就不时髦。”，“相对的美”是一定时期，一定区域的人对于事物的共同看法，它具有区域性、时代性、动态变化性；
- 另一种则是普遍的，不变的。他说有些行为是全世界都觉得美。“普遍的美”是与种族、地域、文化无关的人类的共性认知，比如美食、舞蹈、景观、人体等。
总而言之， “美既是永恒的，又是可变的；既是稳定的，又是流动的，两者是对立的一。
美的产生
“相对的美”由一定时期一定区域的人的文化产生，而“普遍的美”与人类对性、食物、安全的需要密切相关。
匀称的身材，光滑的皮肤，丰满的乳房，颀长的双腿，证明这是一个健康的女性，能够为男性生育出健康的下一代；而结实的肌肉，粗犷的线条，深邃的双眸，证明这是一个有战斗力的男性，能够为女性和下一代提供安定的居所。这就是美。
人类看到新鲜的食物，会觉得它是美的；而面对一滩腐烂的食物，会觉得它丑。因为新鲜的食物能够给人带来营养，让人果腹生存下来，而腐烂的食物带有毒性，让人身体变弱甚至死亡。于是人类进化出来了大量与食物相关的美感。
很多人认为“热带稀树雨林”是很美的风景，因为这是人类的起源地，物产丰富，方便寻找食物，树木可以帮人遮风挡雨，崩腾的河流和宁静的湖泊为人类提供水源，特别适合人类的生活。
美的追求
美来源于人类对于性、食物、安全的需求，而大脑的奖励机制对于人类的美的感受会给予身体多巴胺的刺激，于是就产生了正反馈——美使我愉悦，我要追求美。
人类希望让自己变得更美：于是产生了美容、化妆品、服装等需求。
人类希望自己的后代更美：于是产生了教育、孕童产品等需求。
人类希望让游戏中的自己更美：于是产生了游戏中的氪金。
人类希望自己身边的环境更美：于是产生了装修、置物等需求。
人类希望去看到更美的景象：于是产生了旅游的需求。
…
2.3、马斯洛需求层次理论
基本任何一个稍微入点门的产品经理都会知道马斯洛的需求层次理论，他在论文《A Theory of Human Motivation》中提出，人类都潜藏着五种不同层级的需求，而在不同时期，表现出来的各种需要的迫切成都是不同的。这五层需求分别是：
- 生理需求(Physiological Needs)，包括性、水、食物、空气等，这是人类最最底层的需求。
- 安全需求(Safety Needs)，对自身安全、秩序、健康、资源的追求，避免恐惧、威胁、痛苦。相关的产品案例有：水滴筹、相互宝。
- 归属与爱的需求(Belonging and Love)，指期望与他人建立良好的关系，以及隶属于某一个群体的归属感的需求。相关的产品案例有：豆瓣小组、情感化设计。
- 尊重需求(Esteem Needs)，指成就、名声、地位，从这层开始，已经是比较高阶的需求了，相关的产品案例有：会员等级。
- 自我实现需求(Self-Actualization)，最高层级的需求，指人希望最大限度地发挥自身潜能，不断完善自己，挑战与自己能力相匹配的一切事情，从而实现自我价值。
1954年，马斯洛在《激励与个性》一书中，又基于之前的五层需求，提出了另外两层需求，分别是：
- 求知需求(Learning Needs)，指个人对周围世界的探索、理解，及解决疑难问题的需要，相关案例有：得到、知乎、百度知道。
- 审美需求(Aesthetic Needs)，指对对称、秩序、完整结构以及对行为完美的需要。相关的产品案例有：网易云音乐。
2.4、B2B价值要素金字塔
马斯洛需求层次理论分析的是人的需求，我们知道还有一类生意是toB的生意，那么我们B端客户——也就是某个组织的需求从何而来如何分类呢？
在《用户体验要素》介绍的产品五层结构中，我们知道所有的产品设计都是从核心层开始的，而核心层由两部分组成：用户需求和业务目的。业务目的其实就是我们身处的这个组织的需求，我们应该如何去了解它的需求呢？
Richard Hatheral(贝恩公司合伙人)基于他们30余年的数十项定性和定量研究，总结出了企业的40种价值要素，并将其归为五大类：
- 基本价值(Table Stakes)，它是企业价值要素金字塔的底座，包含：满足特定需求、可接受的价格、满足法律法规要求、满足社会道德准则。
- 功能价值(Functional Value)，主要满足用户在经济和产品性能方面的需求，长期以来，它都是传统行业的主要关注点，包含：提高营收、降低成本、提升产品质量、提升产品适用范围、产品创新。
- 便利价值(Ease of Doing Business Value)，主要为客户开展业务提供便利，包含：提高生产力、提高运营效率、提供可能性、提升员工关系、战略支撑几个模块。
- 提高生产力部分，主要是：节约时间、缩减流程、理清逻辑、提供信息、透明化。
- 提高运营效率部分，主要是：优化组织、简化、连接、集成。
- 提供可能性部分，主要是：赋能、多样性、可配置性。
- 提升员工关系部分：反馈机制、专业赋能、员工敬业度、员工稳定性高、组织文化
- 战略支撑部分：降低风险、扩大范围、灵活性、组件化
- 个人价值(Individual Value)，主要为涉及采购负责人的主观考量，包含个人价值和职业发展。
- 个人价值：有美感的设计、个人成长和发展、减轻焦虑、兴趣和激励。
- 职业发展：扩展人脉、职场竞争力、提升个人声誉。
- 理想价值(Purpose)，这一层包含：提升客户的愿景、给企业或采购者个人带来希望、增强企业的社会责任。
2.5、七宗罪
上面的内容探讨了美好、愿景，但是人类潜意识、底层中是有罪恶、原罪的。七宗罪是天主教对于人类原罪的归类，但丁在他的《神曲》中，根据恶行的严重性从轻到重，排列七宗罪：
人有七宗罪：色欲、暴食、贪婪、怠惰、愤怒、嫉妒、傲慢。
——但丁《神曲》
这些罪恶也能够诱发出人类的很多需求：
- 第七大罪：色欲(Lust)，对性爱的渴望，对刺激的追求，放纵自己的欲望，只注重肉体的满足，而忽略心灵的沟通。基于色欲的一些产品案例：pornhub、陌陌。
- 第六大罪：暴食(Gluttony)，从狭义上说，是浪费食物；从广义上说，是“沉迷”于某个事物，如酗酒、滥用药物、沉迷赌博游戏，过渡追求享乐。怎样利用人类的暴食？给用户沉浸式的体验，给用户持续性地满足。基于暴食的一些产品案例：会员超前看、用户激励机制。
- 第五大罪：贪婪(Greed)，希望占有比需要更多的东西，尤其指对金钱或权力的过度追求。当人们发现某样东西打折或促销的时候，就特别容易丧失理智和判断能力。怎样利用人性的贪婪？打折、免费。基于贪婪的一些产品案例：每日签到、打卡领红包、360免费杀毒、扫码一条街、购物满减。
- 第四大罪：怠惰(Sloth)，怠惰的一方面是：逃避现实、浪费时间、无责任心、懒惰；另一方面则是：更便捷的操作，更短的步长、更顺畅的体验。怎样利用人性的怠惰？由pull变push、缩短步长。基于怠惰的一些产品案例：截图监听、外卖。
- 第三大罪：愤怒(Wrath)，产生无理的愤怒，对人复仇，憎恶他人；歧视、过分的警戒心、对他人有伤害的意图也算是愤怒。怎样利用人性的愤怒？引战。基于愤怒的一些产品案例：Facebook 的前雇员 Frances Haugen 在辞职后接受了采访称，Facebook 一直在采用算法来推送让你感到愤怒的贴文。Facebook 的研究发现人在愤怒的时候，会更积极地回帖、消费、点击广告，因此平台并不打算改动这个算法。
- 第二大罪：嫉妒(Envy)，因对方拥有的比自己多而恼恨别人。怎样利用人性的嫉妒？延长用户的心理满足时间；制造焦虑感解决焦虑；基于嫉妒的一些产品案例：氪金抽角色、游戏私服里的一些托儿、在线教育。
- 第一大罪：傲慢(Pride)，七宗罪里面的傲慢，原指的是对上帝的不敬、对他人的凶残。我们可以将其理解为以自我为中心，因自己拥有的比别人多而傲慢，寻求优越感和荣誉感。怎样利用人性的傲慢？提供炫耀的抓手。基于傲慢的一些产品案例：QQ秀、分享朋友圈。
3、需求的特性
3.1 需求的变化性
产品经理最常被研发挑战的一个点就是：”你又改需求了“，产品经理经常会因此感到guilty，我想说的是：需求的改变是必然的，需求天生具有变化性。
站在Want的角度：很少有人能够想明白自己想要的真正是什么。
站在Needs的角度：因为环境的变化、人类心智的进化，用户/客户的底层需求是会随时间而变化的。
站在Requirements的角度：没有人能想出毫无漏洞的方案。如果发现之前设计的方案不合理，当然要尽快修正方案改需求。
3.2 需求的永恒性
需求具有永恒性：当我们聚焦到一个群体的时候，我们总能找到它的痛点，挖掘出需求；当一个需求被满足后，人们总会去追求更高层次的需求。
以微信举例，从简单的聊天工具，发展出朋友圈、微信公众号，到微信支付、小程序、企业微信，产品版图逐渐扩大，对应的就是需求→被满足→新需求这样的循环。
3.3 需求的不可满足性
在人类的需求中，能满足的需求远远少于不能被满足的需求，因为很多需求当前的科学根本就解决不了，比如长生不老。
在自然科学框架能够解决的需求里，ROI为正的需求远远少于ROI为负的需求。
可支持一个团队规模化运作的需求，远远少于不可支持团队规模化运作的需求。
3.4 需求的矛盾性
为了满足用户的A需求，可能会影响他的B需求。当我们在设计产品的时候，不光要解决眼前正在面对的问题，还要去思考可能受影响的因素有哪些？满足需求的代价是什么。
标准化与个性化之间的矛盾；用户体验与安全性的矛盾；
4、需求的获取
需求不能被发明，只能被发现，我们都是用着最新技术的山顶洞人。
—— 爱奇艺首任产品总监 高玮
产品经理应该建立一套稳定的需求收集机制，以保障能够收集到广泛、全面的需求，为需求分析的后续阶段奠定一个良好的基础。在用户、内部人员、数据分析、竞品处都可以获得需求。
4.1、从用户处获取需求
需求从根源上来说都是从用户处而来的，产品经理只有了解和熟悉所负责产品的用户，才能够找到用户真正的需求，打到他们的痛点，设计出让用户满意的产品。而产品研发团队在考虑问题的时候往往比较专业化，陷入逻辑细节里面，产生“不识庐山真面目，只缘身在此山中“的问题，理论与实际产生偏差，所以搭建起与用户的沟通通路，从用户处获取需求是非常有必要的。从用户侧获取需求的几个手段：
- 用户访谈
- 焦点小组
- 问卷调研
- 用户反馈
- 舆情监督
因为每一种方法背后都有非常多的细节可以讨论，之后可以专门写文章探讨，就不在此过多赘述，未来专门开文章详细探讨。直说几个关键点：
用户访谈可能遇到的挑战是：访谈流于表面拿到的信息不够完整和准确。
那么怎样才能拿到更完整的信息呢？
- 要：接受沉默，访谈留白。要给用户思考和回忆的时间。当用户说完了，不必急着追问，可以点头鼓励用户说出更多。
- 要：尽量使用开放性问题，而非封闭二元问题。
- 反例：您最喜欢A方案还是B方案？您是否喜欢这个方案？（不能挖掘用户更深层的想法）
- 正例：这两个方案您更喜欢哪一个？原因是什么？
- 不要：回答用户关于使用上的问题。
- 举例：用户问”这部分会展示什么内容？“，你先不用回答，而是反问用户”您希望这部分展示什么内容？“
- 要：围绕用户过往的经历，而不是未来的希望。
- 不要问用户”我们有一个XX新增功能，是XXX这样操作的，您觉得怎么样？会使用吗？“，因为它包含很强的引导性。
怎样得到更精准的信息？
- 要：同一个问题，多次追问。一定要确保完全了解用户说的话，如果遇到了不明确或者不理解的，就要刨根问底。
- 举例：问：”您需要一个什么更好的交通工具？“，答：”我想要一匹更快的马“，问：”您为什么想要一个更快的马？“，答：”因为这样能更快地到达目的地“。
- 要：交叉验证，横向对比。有些时候用户讲出来的观点不一定是经过了深思熟虑的，所以我们可以反问用户是否有例外。
- 要：现场总结向用户求证。把访谈人员自己理解的内容复述给用户听，让用户核实是否正确，如果有理解错误的地方，请用户指出来。
- 不要：问题太过模糊
- 反例：您对投资理财有什么看法？问题太过开放，用户容易敷衍了事。
- 正例：您购买过理财产品吗？当时主要考虑什么因素？
- 不要：在访谈过程中表露出失望或责备
- 反例：说出”没人会发现不了这个地方吧？“这种话。
怎样把控节奏？
- 不要：在无效的问题上纠缠。在倾听时如果有偏题现象，应该迅速拿回话语权。
焦点小组可能遇到的问题：
- 错误判断：被访问者可能不具有代表性，容易产生错误的判断，不能把小组座谈的结果当作决策的唯一根据。
- 主持难度：小组座谈是很难被主持的，高素质的主持人比较少，而又特别依赖于主持人的素质。
- 数据凌乱：由于提问和回答的非结构性，所以使得后续的分析解释比较困难。
问卷调研可能遇到的问题：
- 用户乱答问卷：通过题目间的交叉验证筛选出一部分明显乱答的用户。
- 问卷题目过于泛泛：在设计问卷前，想清楚问卷的目的，及期望拿到哪些问题的答案。
- 问卷题目和选项有误，没有统计价值。
- 问卷内容有偏向性、选项不完备
- 问卷不具有代表性
- 问卷没有逻辑，只描述情况，不解决问题。
4.2 内部人员提出需求
有些需求是由内部人员提出的。公司内的任何人都有可能对我们的产品提出需求。将这些需求进行归类，大致可以分为以下几类：
- 管理团队
- 职能部门
- 内部系统使用者
- 外部系统的内部用户
- 产品经理自己
我们经常会受到管理团队top-down的需求，往往是颠覆性的大需求，需要占用研发人员月度为单位的开发时间。在火花这几年，经历过的项目有：按学科拆分课程类型、视频关单、疫情调课、教师接入IM系统等等。老板们的方向感往往很强，但如果没有很好落地，就会虎头蛇尾变成烂尾。因此，当收到此类需求后，一定要明确需求的底层逻辑。如果自己认同这件事情的价值，那么就要落实细节逻辑，并充分利用老板的影响力引入资源，推动项目上线。如果自己不认同这件事的价值，一定要和老板说清楚。在推动此类需求时，还有一个禁忌：请不要只告诉相关干系人：“是某某某老板让做的。”而是要描述清楚事情背后的思考和价值。
每个职能部门都有自己的关键指标。为了达成这些指标，他们会想方设法利用公司内部的各种资源。作为互联网的关键内部资源之一，产研会收到各种职能部门的需求。在处理这些需求时，需要注意两点。首先，职能部门的员工在提需求时，往往只说出了“what”，我们需要挖掘出“need”，这样产生的需求可能并不是他们最初要求的，但却是他们更认同的。另一个要注意的点是，“屁股决定脑袋”。不同职能部门的关键指标可能会有很大差别，甚至可能相互制约。因此，在设计需求对应的方案时，要充分考虑代价。例如，Referral部门为了提高转介绍量，希望在家长端上推送push消息。然而，过多的推送消息可能会影响用户体验，这就造成了Referral部门和体验部门之间的利益冲突。在设计产品时，我们需要考虑这些冲突，让相关职能部门达成共识。
我们的CRM、ERP、SCM系统将有大量内部使用者。他们会对系统提出许多要求。在过去几年中，内部使用者是我们需求池的一个非常重要的来源。这些人也许在产品方面并不是那么专业，但是他们的每个反馈背后都对应着真正的痛点和改善机会，所以一定要重视他们。他们提出的需求，也许由于需求的不可满足性而无法解决，但我们也要向他们说明无法满足的原因。
外部系统的内部用户是一笔宝贵的财富。在产品冷启动时，他们往往是第一批种子用户；新功能上线后，他们往往是第一批“小白鼠”，在各项用户调查中也往往是常客。因此，列出这类人员的名单，他们将成为您非常宝贵的一份财富。
此外，还有一些需求是由PM自行提出的。对于自己提出的需求，最好找其他角色的伙伴，给他再讲一遍这个需求，这样，他们能帮助你看清需求的全貌，避免陷入自己思维的局部最小值。
4.3 从数据中挖掘需求
通过数据挖掘产品需求，可以进行“无中生有”，“持续优化”，甚至“意外收获”有意想不到的发现。
以下是一个通过数据“无中生有”的例子：
在线教育行业有一个非常重要的获取新客户的方式：转介绍。在读学员介绍自己的朋友过来成为新用户。在转介绍的玩法中，有个很重要的场景是在用户APP内生成一张包含二维码的转介绍海报，将它发到朋友圈内。朋友圈内的好友看到后感兴趣就会扫描二维码注册成为新用户。火花做了非常完善的转介绍功能，并且给了用户很多种朋友圈海报模板的选项。数据科学组的同事在分析转介绍的数据时发现了3个有意思的点：
- 不同海报模板被用户选择分享的概率是不同的。这可能是因为展示在前面的模板更容易被选择，也可能是不同阶段（新老生）的用户有不同的喜好，还可能是不同地域的用户有不同的喜好。
- 不同海报模板在朋友圈被扫码转化的概率也是不同的。这可能是因为朋友圈受众的喜好不同。
- 在读用户喜欢的海报模板类型与朋友圈受众喜欢的海报模板类型是不同的。
基于以上数据发现，他们将海报模板分成以下四种类型：
- 在读用户喜欢，朋友圈受众喜欢：明星海报
- 在读用户喜欢，朋友圈受众不喜欢：打折海报
- 在读用户不喜欢，朋友圈受众喜欢：潜力海报
- 在读用户不喜欢，朋友圈受众不喜欢：劣质海报
他们希望通过设计一套“赛马”排序算法，将在读用户分成几个聚类群组，然后在每个群组内找到对应的四种类型的海报，以推广明星海报；引导在读用户选择有潜力的海报；淘汰劣质海报。这样，最终可以提高海报的分享率和分享出海报的转化率。
再举一个“持续优化”的例子：
在线教育行业的获客成本很高。要想实现盈利，就必须提升用户的LTV，而留存就非常关键。在中国这个大背景下，能让孩子持续留存的一个基石就是要有好的学习效果。
为了提升学习效果，教服团队连同数据科学团队开展了一个“课次知识点薄弱报警”项目。通过孩子的课前、课中和课后行为数据，预测孩子可能存在的知识点掌握薄弱，生成报警工单，让辅导老师尽快干预。
为了达成最终的结果，我们定义了项目的三个关键点：报警准确、物料有效、执行给力。这三个点分别明确了三个数据：员工主观准确率、物料点击使用率和员工有效沟通率。每周观察复盘数据，提出了很多业务动作和产品改进点。
4.4 从竞品处习得需求
从竞品处获得需求可以通过桌面研究和行业研究来实现。
在桌面研究中，可以通过竞品的产品特性、功能、设计等方面来发现需求。
在行业研究中，可以通过分析竞品在市场上的表现、用户反馈、用户评价等方面来获得需求。
此外，可以通过竞品分析工具来分析竞品的流量来源、用户特征、用户行为等，从而发现潜在的需求点。在竞品分析的过程中，需要注意不要直接照搬竞品的功能或设计，而是要结合自己的产品特点和用户需求来进行创新和改进。
4.5 外部干系人的需求
从外部干系人处获得需求可以通过了解政策法规和行业规范来实现。
政策法规往往会对产品设计和功能产生影响，需要关注相关政策法规的更新和变化。比如双减后，主管部门对于在线课堂单节时长的限制、可报名学员年龄的限制、可购课时上限的限制，都带来了很多新的需求。
行业规范则可以帮助产品团队了解行业趋势和标准，从而更好地把握市场需求。
5 需求的分析
需求分析时，分析的是什么？
- 聚焦用户群体
- 挖掘底层需求
- 判断合理性
- 评估可行性
5.1 聚焦用户群体
要明确这是哪些人的需求。解决这个需求时，我们需要考虑哪些人的利益或体验会受到影响。
假设我们收到了用户的反馈，希望有请假的功能。那么我们需要深入了解：
是试听课程用户需要请假功能？还是正式课程学员需要请假功能？还是内部员工需要请假功能？
如果这个需求是在一次用户访谈中由已经上了一段时间课程的用户提出的，那么我们可以初步确定：请假需求是在读用户的需求。
5.2 挖掘底层需求
接下来，可以使用Why?Why?Why法挖掘出底层需求，也就是“Needs”。
请看下面一段对话：
- US业务团队反馈想做一个学员请假的功能。
- 为什么他们需要这个功能？
- 因为家长觉得没来上课也扣课时，自己吃亏了。
- 为什么学员不来上课也要扣课时？
- 因为哪怕学员没来上课，教师也要预留出这段时间留给孩子，占用了了教师的时间就要给教师工资。
- 为什么在孩子请假时，不提前告诉教师不要预留时间，这样就不用给教师工资了。
- 因为有些孩子请假后还会取消请假，再来上课。就会导致教师安排了别的事情，后来又得来上课。
- 为什么不限制一个允许取消请假的时间窗口期，如果超过了这个窗口期，就不许取消请假了。
- 之前都没做请假功能，自然就没想这么细。
- 为什么之前新加坡业务已经稳定运行了那么长时间也没有做请假的功能。
- 因为新加坡的政策是请假后可以免费补课。
- 为什么美国不能复用这个政策？
- 美国也是请假后可免费补课，但是因为用户习惯不一样，美国学生请假的频次比较多，且不好协调出补课的时间。
通过以上的反复追问 “why”，我们挖掘出了需求的本质并不是请假功能，而是：
- 学员家长：希望在请假时不扣除课时。
- 教师：因为需要耗费时间，所以需要支付工资。如果取消，请提前通知。
然而，“Why?Why?Why?”法可能会遇到一个问题，即最终聚焦到的需求点过于泛泛，范围过大，不够准确。曾经我和组内的小伙伴儿玩过一个游戏，就是不断问 “why”，最终所有的C端价值都落到了用户体验，B端价值都落到了公司赚钱。然而，问到这里，就没太大意义了。
5.3 判断合理性
当产品经理与业务或研发PK时，经常会听到：“你的这个需求不合理。”那么，什么才是合理的呢？为什么要说某个需求不合理？可以考虑以下三个问题：
- 是否会损害用户体验？
- 是否违背业务目标？
- 是否与产品定位不符？
每个业务团队都有自己的核心指标。为了达成这个指标，他们会提出一些需求。但是他们不一定有全局视角，提出来的需求就有可能会伤害到用户的体验。例如，增长团队希望提高转介绍率。他们发现每一次群发消息提醒，就会有一批用户去完成转介绍的动作，于是就提出了一个需求：希望从周一开始，每天给当周还未完成转介绍任务的用户推送提醒。然而，这种高频的提醒再叠加其他场景给用户的消息推送，很有可能会损害用户的体验。因此，这个需求并不是一个合理的需求。
每个业务都有当前阶段的重点目标，基于这个目标拆解，就会有很多小目标。然而，不同目标之间可能会存在一些冲突，例如易用性与安全性之间的冲突、转化率与利润率之间的冲突、线索量与转化率之间的冲突。如果一个需求有利于目标A，有损于目标B，那就要回溯到A/B共同的父级目标，看这件事情的综合收益是正还是负。例如，某一个免费试听课程渠道每个月能够带来2000个线索，端到端转化率为1%。如果将这个渠道的试听课改成10元付费的，那么线索量会减少20%，但端到端转化率会提升到1.5%。那么，是否要实现这个10元付费试听课的需求呢？
乍看下来，这个需求对Marketing的核心KPI也就是Leads量有损，但是对于Sales的核心KPI也就是转化率有利。我们往上追溯，Marketing和Sales共同的目标就是为了用更少的钱获得更多的用户。
这2000个线索需要40个销售去跟进，1%的转化率，最后会转化20个线索，客单价为8k元，而每个销售每个月的成本为8k元。那么这个渠道的获客成本为：40*8k/20=16k/用户
假设变为10元付费试听课，那么会进来1600个线索，需要32个销售，1.2%的转化率，最终会转化19个线索，这个渠道的获客成本为：32*8k/19 = 13.4k/用户
算下来，我们节约了16k20 – 13.4k19 = 65.4k，少获得了5个用户，那么这5个用户的获客成本为13.08k/用户，所以明显不划算。不应该做这个需求。
每个产品都应该有自己的标签和调性。如果某个需求与产品定位不符，有可能会让核心用户群体感到不适，最终导致用户流失。因此，在产品开发的初期，我们需要仔细考虑和定义产品的标签和调性，以确保产品和用户需求相符，并且能够吸引和保留我们的核心用户群体。
另外，我们还需要不断跟进用户反馈，并根据用户的反馈不断调整和优化产品的标签和调性，以确保产品能够持续地满足用户的需求和期望。以微信为例，当微信已经成为国民级应用时，很多人都看到了私域运营的商机，在微信里充斥了大量的微商，朋友圈里有很多广告，很多大企业的服务人员也会添加用户微信不定期地进行一些推广营销。微信团队努力顶住压力和诱惑，尽量减少微信生态内的商业化氛围，防止变味导致用户流失。
5.4 评估可行性
在一个需求被判定为合理之后，接下来就需要判定它是否可行。可行性分为三类：技术可行性、经济可行性和社会可行性。
评估技术可行性时，比较理想的情况是PM本身就了解技术框架和细节，自己是研发出身。否则，需要与研发团队进行初步预沟通，让研发伙伴帮忙评估。
经济可行性是指项目实施后的经济效益。在评估经济可行性时，需要考虑项目的成本、收益、投资回报率、现金流量和资金需求等因素。
社会可行性是指项目对社会和环境的影响。在评估社会可行性时，需要考虑项目是否符合法律法规、是否符合道德标准。社会可行性是保证项目可持续发展的重要因素。
6 需求的分类及排序
通过分类，我们可以将相似的需求放在一起，方便管理和排序。我通常使用以下三种方式进行需求分类：
6.1 战略-紧急-常规
每个季度需要确认三个左右的战略项目。这些战略项目通常是与关键业绩指标紧密相关的从上而下的项目，需要每周/双周对其进展进行评审。尽管这些战略项目通常属于重要但不紧急的项目，我们仍需要抽出固定的时间来完成它们，否则就会迷失方向：每天被琐碎事务所困扰。
紧急需求是特例，我们不能拒绝插入紧急项目，但也不能让所有项目都变成“紧急项目”，从而导致无法掌控。因此，我们可以制定一个紧急项目插入流程。如果想要打破现有的排期，优先完成某个需求，就必须获得某些领导的授权。
对于非战略、非紧急的需求，我们将其定义为常规迭代需求，每两周进行一次迭代。为了避免过多的细粒度需求过于零散，每个迭代都可以以打包的形式聚焦于一个主题。
通过战略、紧急和迭代的分类，我们可以有效地把控住需求的节奏感。
6.2 卡诺模型
KANO模型是东京理科大学教授Noriaki Kano在1978年发表的用来衡量产品功能与用户满意度的工具。根据产品功能的有无与用户满意程度之间的关系，可以将需求分为5大类：
- Must-Be，必备功能：如果没有此功能，用户会非常不满意；有此功能，不会额外增加用户的满意度。例如：员工能够通过话务系统与用户拨打电话沟通。
- Performance，期望功能：如果没有此功能，用户会不满意；如果有此功能，会提升用户满意度。例如：IM聊天工具里的常用话术功能。
- Attractive，魅力功能：如果没有此功能，用户不会觉得不满意；如果有此功能，用户会觉得很惊喜。例如：在处理学情沟通工单时，自动帮你生成孩子的阶段学情总结。
- Indifferent，无差异功能：无论是否有此功能，用户体验都不会受到什么影响。例如：给员工展示用户所在地区的天气预报。
- Rverse，反向功能：没有此功能用户会比较满意，有此功能会损害用户的体验。例如：员工每天首次登录系统，强制弹窗展示员工守则20秒。
应该最先做必备功能，再做期望功能，再做魅力功能，不做无差异功能和反向功能。
6.3 分象限法
当两个维度相交时，就会形成一个平面直角坐标系，拥有四个象限。
当两个维度分别为重要程度和紧急程度时，我们可以将需求分为重要紧急、重要不紧急、紧急不重要、不紧急不重要四类。
重要且紧急的需求通常指线上产品故障，需要紧急高优处理，甚至要为此加班。
重要不紧急的需求往往是对产品有重大改善机会，能够发展产品的核心竞争力。这种需求应该作为重点项目着重规划去做。
紧急不重要的需求一般是用户使用产品时遇到的一些小问题，可以快速解决，但对核心路径体验影响较小。可以按实际情况安排计划完成。
不重要不紧急的需求优先级相对靠后，可以等资源充足的时候去做。
当三个维度相交时，就会形成一个空间直角坐标系，拥有八个象限。
当三个维度分别为范围、频次、程度时，我们应优先处理覆盖范围广、发生频次高、影响程度深的需求。经常遇到的一个陷阱是，为了0.2%的异常情况花费80%的精力去覆盖，增加了99.8%的普通用户的操作成本，没必要。
6.4 按收益类型分类及排序
不同的需求目的可能不同。为了方便度量，可以将相同目的的需求放在一起，并使用统一的衡量指标。例如，所有提效类的需求可以使用使用频次单次节约时长的方式进行衡量，所有管理类的需求可以使用范围影响程度的方式进行衡量。因此，所有明确效益类的需求都可以统一按对利润率的贡献度来衡量。
将相同类型的需求放在一起统一度量后，就方便进行排序了。下图是我按收益类型进行需求分类的一个示例。
7 需求池
为了更有序地管理需求，并为需求管理复盘打下良好的基础，我们需要使用需求池这个工具。需求池一般包括以下字段：
需求名需求名字常见的问题包括：范围太大、模糊不清、口语化、有语病。例如：“CRM体验优化”、“聊天记录优化”、“CRM需支持LA操作补课”、“海外及港澳台标签删除流程”等等。
“CRM体验优化”到底是要优化什么？为什么不在名称中具体描述呢？如果我们把它改为“CRM内字体、字号、配色等视觉元素优化”，就会更加具体。
类似的问题还有“聊天记录优化”，到底是要优化用户侧的聊天记录功能还是员工侧的聊天记录功能？又是如何优化的？如果我们把它改为“员工侧查询聊天记录时增加关键词筛选项”，就会更加清晰明了。
“CRM需支持LA操作补课”这句话非常口语化，为什么不改成“CRM内增加为学员预约补课功能”？
“海外及港澳台标签删除流程”是个非常长的定语名词。我们要对这个流程做什么？是要修改流程？增加环节？删除环节？如果我们把它改成“海外及港澳台标签删除流程内增加主管确认环节”，就会更加具体。
一个好的需求名字应该具备什么样的特点？把它拿给三个小伙伴看看，如果大家都能看懂，而且名字在20个字以内，那就是一个好的需求名字。
模块
当需求池内容过多时，增加模块划分有助于分类和排序。如果一级模块过多，可以使用二级或三级模块。例如，在管理某个业务的全链路需求时，可以首先按照Portal划分一级模块：用户端、官网、市场端、销售端、教学端；然后，每个Portal又有相应的二级模块。以销售端为例：沟通通路、线索分配、跟进记录、试听约课、订单资产等。
来源
记录需求提出者是谁，方便明确关键干系人。
类型
按照本文第6部分描述的类型，标记需求的类型：是否紧急？是否重要？是战略项目、紧急项目还是常规迭代？
收益
在投入研发资源之前，需要明确需求的预估收益，并将其记录在需求池中。这个预估收益必须是明确可衡量的。
产品上线后，需要评估此需求带来的实际收益，并将结果维护到需求池中。这些信息在总结和回顾时非常有用。
状态
清晰地知道每个需求处在生命周期的什么阶段也有助于需求的管理，我将需求分为如下几种状态：
待启动 → 产品设计中 → 待提需 → 开发中 → 待测试 → 测试中 → 已上线，需求关闭，需求暂停。
优先级
按照第6部分的介绍，确认好需求的优先级，将其填入需求池内。在优先级这一部分，需要做到克制，避免整个池子都是P0。比较理想的状态是按照数字从小到大排列，避免出现并列的情况。
描述
大部分时候，仅从一个标题很难说清楚要做什么事情、它的背景及意义，可以添加一个”描述“字段，放入这些补充信息。
关键时间点
产品团队有可能会受到业务团队的吐槽：某某需求做了好久都没有上线，花费了太长时间了！为了避免遇到这种问题时说不清楚，需要记录需求的关键时间点，包含：入库时间、开始产品设计时间、产品设计完成时间、提交研发评审时间、开始研发时间、研发给出排期、开始测试时间、实际上线时间…这些信息在做项目回顾的时候是非常重要的信息。
相关文档
一个产品需求的落地涉及到产品、运营、业务、UI、开发、测试、数据很多个角色，将与需求相关的MRD、PRD、数据分析、项目规划文档均在需求池内，作为补充背景信息，有助于减少项目成员之间的信息差。
参考文献：
- 2万字 | 全面剖析需求的挖掘与分析
- A Theory of Human Motivation
- 深层次挖掘用户需求，马斯洛理论再进阶
- 深度挖掘用户需求？按这五个步骤做！
- 如何判断一个产品的可行性？
- Kano Model Wikipedia
- 《王慧文清华产品课》
- 《微信产品观》
- 《人类审美的起源，原来和性也有关》
- 《七宗罪解读 | 人性最深处的原始需求分析》
- 《需求分析五部曲：需求挖掘，从底层人性洞察用户需求》
- 《用户需求挖掘与分析的方法》