第三章：需求分析

在上一章，我们学会了如何像一名侦探一样，通过各种手段去“收集”需求的线索。但这些线索往往是零散的、模糊的，甚至带有误导性。如果我们不加处理就直接采纳，很可能会做出南辕北辙的产品。

因此，需求分析就是我们作为产品经理，对这些原始线索进行“勘察、推理、定案”的关键过程。这是整个产品工作中，最能体现我们逻辑思辨和深度思考能力的核心环节。

3.1 需求分析的定义

我们先从最根本的问题开始：到底什么才叫“需求分析”,我们可以来看一个案例：

上面这个案例，我们不难看出，当我们接到需求后，没有去了解需求的背景，深挖需求。很容易导致我们做出来的方案是不符合要求，导致大量的人力、时间、资源的浪费，我们应当去拆解用户的需求，如下：

3.1.1 什么是需求分析

在我看来，要理解需求分析，我们需要抓住它的“本质”和“过程”。

1. 需求分析的本质

我理解的需求分析，其本质是一个**“解构”与“重构”**的过程。

• 解构：是把用户提出的原始需求（无论是问题、目的还是方案）打碎、拆解，深入挖掘其背后真正的动机和未被满足的痛点。
• 重构：是在我们完全理解了本质痛点之后，重新组合信息，设计出一个真正能有效解决该问题的、合理的、可落地的产品解决方案。

简单来说，就是先想“为什么”，再想“怎么办”。

2. 原始需求与产品需求的转换

基于这个本质，我给需求分析一个最直接的定义：所谓需求分析，就是将“用户的原始需求”，转化为“可执行的产品需求”的全过程。

我们再来回顾一下这两个概念：

• 原始需求：是用户直接给我们的东西，是“用户想要什么”。它可能是“我想要个一键下单按钮”，也可能是“我希望能快速找到便宜的外卖”。它是我们工作的输入。
• 产品需求：是我们经过分析、甄别、权衡之后，最终决定要做的东西，是“我们应该为用户做什么”。它是一个包含了用户场景、核心问题、解决方案和验收标准的完整方案。它是我们工作的输出。

所以，需求分析就是连接这两者的桥梁，是那个至关重要的“转化”步骤。没有这个转化过程，我们就只是一个需求的“传声筒”，而不是一个创造价值的“产品经理”。

为了让这个区别更清晰，我总结了下面的对比表：

3.2 需求分析的时机

在我看来，需求分析并不是一个孤立的、只在特定阶段才进行的“仪式”。它应该像呼吸一样，贯穿我们产品工作的始终。不过，从实践上，我主要会在两个关键的时间点，以不同的方式来开展这项工作：1️⃣收集需求时 和 2️⃣收集需求后。

3.2.1 收集需求时的需求分析

1. 直接沟通进行需求分析

我把这个过程称为“实时分析”。当我在进行用户访谈、或是与业务方开会时，我绝不只做一个被动的记录员。我的大脑会高速运转，对接收到的每一个信息点，当场进行第一轮的分析、澄清和追问。

这种方式的好处是，我可以在信息最新鲜、上下文最完整的时刻，抓住机会深挖下去，及时地探究用户“为什么”这么想，而不是等会议结束、记忆模糊后，再自己去猜测。

2. 案例：物流公司时效需求分析

这个案例能很好地说明实时分析的价值。

• 场景：我作为一家物流平台的PM，正在访谈一位重要的企业客户。
• 原始需求：客户告诉我：“我希望你们的平台能提供一个功能，让我能在地图上看到我们货物的运输车辆的实时GPS位置。”
• 我的实时分析与追问：听到这个“方案”后，我没有立刻记下来就完事，而是当场追问：“这个想法很有意思。可以和我聊聊吗，您为什么需要看到车辆的实时位置？这个功能能帮您解决什么具体问题呢？”
• 挖掘出的本质目的：通过追问，我发现，客户并不真的关心车辆在哪条路上，他关心的是“货物到底什么时候能到”。因为他的下游客户总是在催问他送达时间，他需要一个准确的预期，来安抚客户、安排接货。
• 转化后的产品需求：因此，我将这个需求从“提供车辆实时定位”，转化为了“在订单详情页提供一个精准、动态的预计送达时间（ETA），并支持在临近送达时，向收货人发送提醒”。后者显然是价值高得多、也更贴近问题本质的解决方案。

3.2.2 收集需求后的需求分析

1. 集中分析需求

当然，光有实时分析是远远不够的。在完成了当周的用户访谈、回收了所有的调查问卷、或者整理完用户反馈后，我会专门安排时间，进行一次“集中分析”。

在这个阶段，我会把所有零散的、原始的需求信息汇总到一起，像一个侦探把所有线索都钉在白板上一样。我会开始寻找它们之间的关联、共性，试图发现那个隐藏在多个表象之下的、更宏观的、系统性的问题或机会。

2. 案例：用户反馈需求分析

• 场景：我作为一款社交App的PM，每周都会定期整理来自应用商店、社区的用户反馈。
• 原始需求（集合）：我看到了大量看似独立的用户抱怨。
  • 用户A说：“你们的视频加载太慢了！”；
  • 用户B说：“视频看着看着就卡住了”；
  • 用户C说：“上传一个视频要等半天”。
• 我的集中分析：如果我只看单条反馈，可能会分别给技术团队提“加载慢”、“播放卡”、“上传慢”这三个独立的、零散的问题。但当我把它们放在一起集中分析时，我发现了一个共性——我们产品的整体视频处理和分发链路，可能存在系统性的性能瓶颈。
• 转化后的产品需求：基于这个判断，我最终定义的产品需求，就不是一个个小修小补，而是一个系统性的优化项目：“优化视频处理架构，提升视频在不同网络环境下的加载和播放流畅度，将平均起播时间缩短30%”。这个需求，显然比解决单个用户的抱怨要有价值得多。

总而言之，这两种时机的分析，各有侧重，缺一不可。我将它们的区别总结如下：

3.3 需求分析的步骤

到目前为止，我们已经定义了需求分析，也明确了进行分析的时机。那具体到一项原始需求，我究竟是如何一步步把它“解剖”清楚的呢？

在我的工作流中，这个过程被严格地划分为三个步骤：

• 第一步：需求澄清；
• 第二步 ：需求甄别；
• 第三步：需求的优先级排序。这三个步骤，层层递进，缺一不可。

我们先来看第一步，也是所有分析的基础——需求澄清。

3.3.1 需求澄清

每当一个原始需求摆在我面前时，我从不急于判断它的好坏、真伪，我做的第一件事，永远是：把它弄清楚。

需求澄清，对就我像一名侦探在审视案发现场，我需要通过反复地询问和探究，把这个需求的所有模糊、不确定的信息，都变得清晰、明确。为了系统化地做到这一点，我随身携带着一个强大的思维工具——“WHY-WHO-WHAT-HOW”框架。

我们以外卖平台的案例来逐一拆解这四个关键问题：假设我收到的一个原始需求是“我想要一个‘智能营养餐’功能”。

1. WHY（为什么）

这是我首先要问的问题：我们为什么要做这个需求？ 它能为用户带来什么核心价值？它又能为我们的公司带来什么商业价值？

• 对于“智能营养餐”这个需求，WHY可能是：
  • 用户价值：帮助对健康有追求的用户，解决“不知道怎么吃才健康”以及“计算热量和营养成分很麻烦”的痛点。
  • 商业价值：通过差异化的健康服务，吸引高价值用户，提升平台的品牌形象和用户粘性。

如果一个需求的“WHY”我都答不出来，那它基本上就可以被直接否决了。

2. WHO（用户是谁）

第二个问题：这个需求我们是为谁而做的？ 我需要清晰地描绘出目标用户的画像。

• “智能营养餐”的WHO，绝不是“所有用户”。它的核心用户画像可能是：
  • 一线城市的年轻白领；
  • 有健身习惯或正在减脂的人群；
  • 关注生活品质、愿意为健康付出一定溢价的用户。
• 明确WHO，能帮助我在后续的设计中，始终围绕着这群核心用户的审美和习惯来进行。

3. WHAT（什么问题）

第三个问题：我们具体要解决一个什么问题？ 我需要把用户的痛点用清晰、无歧义的语言描述出来。

• 对于“智能营养餐”，WHAT不是“用户想要一个功能”，而是要解决用户的本质问题：
  • “用户因缺乏专业知识，难以判断不同外卖的营养成分和热量是否满足自己的健康需求。”
  • “用户因工作繁忙，没有时间去自己计算和搭配每日的营养摄入。”

4. HOW（现状如何）

最后一个问题：用户现在是如何解决这个问题的？ 了解用户当前的“野生”解决方案，能帮我判断痛点的强度，并为我的设计提供灵感。

• 对于“智能营养餐”这个需求，用户当下的HOW可能是：
  • 自己去网上搜索食物热量表，估算着点餐。
  • 下载专门的健康App，手动记录自己点的外卖，再查看营养分析。
  • 干脆放弃点外卖，选择自己做饭或吃价格昂贵的成品健康餐。
• 这些笨拙、耗时、昂贵的现状，恰恰反证了我们这个新功能潜在的巨大价值。

我将这个澄清框架总结为一张表，它是我分析任何需求前的“必填清单”：

只有把这四个问题都回答清楚了，我才会认为，这个需求已经被我“澄清”了。接下来，我才会进入分析的第二步：需求甄别。

3.3.2 需求甄别

我把需求分析的第二步称为**“需求甄别”**，或者叫“真伪需求判定”。我的核心任务，是判断这个被澄清后的需求，到底是一个能为多数用户创造巨大价值的“真需求”，还是一个看似有理、实则虚幻的“伪需求”。

投入资源去做一个伪需求，是我认为对团队最大的浪费。

1. 需求真伪判定的三个标准

为了避免凭感觉做判断，我建立了一套自己的“甄别滤网”，它由三个核心标准构成。一个有价值的真需求，通常需要至少满足其中两个，甚至是全部三个标准。

• 普遍性 (Universality)
  这个问题是否具有广泛的代表性？在我的目标用户群体中，遇到这个问题的用户规模有多大？是只有一小撮人有这个特殊的毛病，还是绝大多数用户共同的困扰？我追求的，是能让尽可能多的目标用户受益的需求。

• 痛点性 (Painfulness)
  这个问题给用户带来的“痛感”有多强？如果这个问题不被解决，用户是否会感到非常沮丧、烦躁，甚至愿意付费来解决它？我常用“是‘痒点’还是‘痛点’”来区分。挠痒痒的需求可做可不做，但治病止痛的需求，用户才会真正买单。

• 高频性 (High Frequency)
  用户遇到这个问题的频率有多高？是每天、每周都会遇到，还是每年甚至几年才会遇到一次？高频的需求，意味着我们的解决方案能被用户频繁使用，这对于培养用户习惯、提升产品粘性至关重要。

2. 伪需求判断案例分析

我们来看一个经典的案例，学习如何运用这三个标准来甄别伪需求。

• 场景：我是一家“母婴社区”App的产品经理，我们的核心业务是为新手爸妈提供育儿知识交流和社交的平台。

• 原始需求：社区里有一位非常活跃且有影响力的用户，她强烈建议我们增加一个“儿童防走丢手表”的功能。她的设想是，用户可以在我们的App里购买一款儿童手表，并随时查看孩子的位置。

• 我的甄别过程：这个需求听起来非常“刚需”，因为儿童安全是天大的事。但我们必须冷静地用三个标准来审视它。

  1. 普遍性分析：所有家长都关心孩子安全，这是一个普遍的情感。但是，“需要通过一个App内嵌的硬件功能来随时追踪孩子位置”，这还是一个普遍的需求吗？我的判断是，只有其中一部分极度焦虑的家长才会有此强需求。因此，需求的普遍性较低。
  2. 痛点性分析：“孩子走丢”这个场景，痛不痛？当然痛，这是天塌下来的痛。所以，痛点性极高。
  3. 高频性分析：一个正常的孩子，在父母的看护下，“走丢”这件事发生的频率有多高？谢天谢地，这是一个极低极低的概率。所以，需求的高频性极低。

• 我的最终结论：这是一个“低频、非普适的超强痛点”需求。更重要的是，它涉及到硬件、供应链、地图服务等，这与我们“社区内容”的核心能力相去甚远。因此，尽管它听起来很有吸引力，但我会判定，对于我们这个母婴社区App而言，这是一个“伪需求”。它是一个真实存在的问题，但它不应该由我们这个产品来解决。

我将这三个标准总结为一张自检表，每当我分析需求时，都会在心里为它打分：

只有通过了这道严格的“安检门”，一个需求才有资格进入我分析流程的最后一步：优先级排序。

3.3.3 需求的优先级

经过了“澄清”和“甄别”，我们现在手上拿到了一份“真需求”清单。但现实是，我们的研发资源（人力、时间、金钱）永远是有限的。我们不可能同时满足所有人的所有需求。

因此，优先级排序，就是决定“我们下一步应该先做什么，再做什么”的艺术和科学。在我看来，这是产品经理最重要的决策，没有之一。一个正确的优先级决策，能让我们的产品价值最大化。

1. 四象限法则

当我面对一大堆需求，感到千头万绪时，我用来理清思路的第一个工具，就是经典的**“四象限法则”**（也叫艾森豪威尔矩阵）。我通过“重要性”和“紧急性”这两个维度，快速地对需求进行一次粗分类。

• 重要且紧急：这是最高优先级，是那些“着火了”的需求。比如：线上支付功能出现重大Bug、服务器宕机。我的原则是：马上做，调动一切资源，立刻解决。
• 重要不紧急：这是最能体现我们产品经理价值的区域。这些需求关系到产品的长期发展和核心战略，比如：架构优化、新功能探索、用户体验的系统性提升。它们没有明确的deadline，最容易被我们拖延。我的原则是：计划做，必须主动地、有计划地把它们排入我们的产品路线图。
• 紧急不重要：这些是日常工作中最大的干扰。比如：某个领导临时想要一个不重要的数据、某个非核心客户的一些小报怨。它们看起来很急，但对我们的核心目标贡献不大。我的原则是：授权做或快速应付，看能否让团队其他人帮忙，或者用最小的代价快速解决。
• 不重要不紧急：这些是价值最低的需求。我的原则是：尽量不做或直接拒绝。我们必须学会对这类需求说“不”。

2. 优先级确定因素

四象限法则帮我做了初步的划分，尤其区分出了“重要不紧急”这个价值区域。但当我有多个“重要不紧急”的需求时，应该先做哪一个呢？这时，我需要引入更多的因素来综合判断。

• 性价比（成本与价值）：这是我最看重的因素。我会粗略地估算每个需求的“投入产出比（ROI）”。即，这个需求需要耗费多少开发资源（成本）？它又能带来多大的用户价值和商业价值？我总是在寻找那些“四两拨千斤”的、低成本高价值的需求。
• 符合战略规划：这个需求是否与我们公司本季度或本年度的战略目标相符？一个再酷的功能，如果脱离了公司的战略主航道，那它就是一个“漂亮的干扰项”。我必须确保我们的开发资源，始终服务于公司的战略大方向。
• 长短期价值：我需要在“短期见效”和“长期投资”之间做出平衡。有时为了提振士气或达成某个KPI，我会选择一个能快速上线、马上看到效果的需求（短期价值）。有时我也会选择一个用户完全感知不到的“后台架构重构”项目，因为它能为我们未来几年的开发效率打下坚实的基础（长期价值）。

3. 确定需求优先级的注意事项

最后，我想分享几点我在无数次优先级PK中，总结出的经验和教训。

• 需求变动性：我必须承认，优先级不是一成不变的。市场环境在变，用户需求在变，我们必须保持敏锐和灵活，定期（比如每两周或每月）回顾和调整我们的产品路线图。
• 全局主动性：我不能只做一个被动接收和排序需求的人。我需要站在整个产品的视角，主动地去规划那些能建立长期壁垒的、系统性的项目，而不是被各个业务方的“紧急”需求牵着鼻子走。
• 真实需求基础：我的所有优先级判断，都必须建立在我们在3.3.1和3.3.2节所做的“澄清”和“甄别”工作之上，即必须是真实的、有价值的需求。绝不能因为某个领导声音大、或者某个客户会吵，就轻易提高他的需求的优先级。
• 需求选择搭配原则：一个健康的版本迭代，就像一顿营养均衡的饭。我通常会搭配着来，比如“一个大的新功能 + 几个重要的体验优化 + 一些历史Bug修复”。这样的版本，既能给用户带来惊喜，又能提升产品的稳定性，还能让团队有成就感。

我将优先级排序的要点，总结为下面这张表：

到这里，我们需求分析的三个步骤就全部完成了。一个需求，只有经过了澄清、甄别和优先级排序这“三堂会审”，才有资格最终出现在我们的产品路线图上。

最后，我们附上产品需求文件模板供产品设计师快速完成需求分析的任务