第二章：需求收集与管理

2.1 什么是需求

在我的产品经理生涯中，我始终认为，一切工作的起点和终点都是“需求”。如果我们对需求的理解出现了偏差，那么后续无论多精美的设计、多优秀的技术，都只是在错误的地基上建造楼阁，最终难免会坍塌。那么，到底什么是需求？让我们一起深入地探索它的本质。

2.1.1 学习目标

在本节中，我的核心目标是帮助我们建立起对“需求”的深度认知。我希望在本节学习结束后，我们都能具备一种“穿透”能力——能够穿透用户表面的只言片语，直达他们内心深处真正的、未被言说的渴望与痛点。

2.1.2 公司背景与项目背景

在讨论理论之前，我习惯先设定一个场景，因为脱离了场景谈需求，就如同无源之水。让我们虚构一个案例背景，以便更好地代入思考。

1. 公司背景
   我们是一家B2B生鲜食材供应商，通过自研的线上平台，为全国数千家餐厅提供每日的食材采购与配送服务。

2. 项目背景
   近期，平台的客服部门收到了大量餐厅采购员的抱怨，普遍反映我们的下单流程烦琐、效率低下。因此，公司决定立项，由我来负责优化平台的下单体验，提升客户满意度和下单频次。

2.1.3 什么是需求（案例）

好了，背景就绪。现在，作为这个项目的PM，我开始接触来自一线用户的声音。在我的经验里，这些声音（也就是最初始的需求）通常以三种面貌出现。

1. 案例1：用户以“提问题”方式给出的需求
   一位用户在App的反馈区留言：“每天都不知道我要吃啥，我怎么才能知道今天应该点什么外卖呢？”
   • 我的解读：用户提出的“问题”，是他目前面临的问题，或许我们可以推出一个简单的小插件入口，随机抽取今天应该吃什么？。
2. 案例2：用户以“提目的”方式给出的需求
   一位用户反馈说：“我每天吃饭的预算有限，希望平台能够让我自己快速点到20块钱以内的外卖。”
   • 我的解读：这位用户给了我一个非常明确的“目的”——“快速找到20元以内的外卖”。这是一个清晰的、待满足的诉求。我的工作就是思考如何最好地帮他达成这个目的，是增加一个价格区间筛选？还是专门开辟一个“平价专区”？
3. 案例3：用户以“提方案”方式给出的需求
   一位用户希望我们做一个“智能推荐”功能。他描述道：“只要一点就进入这个推荐，就提供价钱选择，还有结合自己的口味和当下季节以及哪个地方的给推荐性价比口碑最好的外卖，并且支持点击一下就自动付款下单的功能。”
   • 我的解读：这是一位“高阶”用户，他不仅提了目的，甚至帮我把完整的产品“方案”都设计好了。这恰恰是最需要我警惕和深度分析的情况。他这个宏大的方案里，其实包含了多个本质目的的集合：“我懒得选（要智能推荐）”、“我要省钱（要性价比）”、“我要好吃（要口碑好）”、“我要方便（要一键下单）”。我的职责不是照抄这个方案，而是将这些本质目的拆解开来，评估实现难度和用户价值，设计出更合理、更可落地的产品方案。

2.1.4 需求的常见形式

通过上面三个小案例，我们可以总结出，用户最原始的需求通常以三种形式传递给我们。我把它们整理成了下面的表格，方便我们记忆。

2.1.5 需求的定义

那么，综合以上所有，我来给出我对“需求”的最终定义。我认为需要区分两个概念：

1. 原始需求
   即用户直接表达出来的，未经加工的“问题”、“目的”或“方案”。它是我们工作的输入和起点。
2. 产品需求
   这是我们产品经理经过分析、挖掘、转化后，真正应该去做的东西。我对它的定义是：
   • 在特定场景下，为满足用户的本质目的，我们所设计出的一套完整的解决方案。

所以，我的工作，从来不是对用户的“原始需求”照单全收，而是要经历一个“原始需求 → 本质目的 → 产品需求”的深度转化过程。这趟旅程的质量，决定了我们最终产品的成败。

2.2 需求如何收集

我们已经深刻理解了“需求”的本质，知道它藏在用户的只言片语背后。那接下来的问题就是，我们该去哪里、以及如何才能高效地把这些“藏着”的需求挖掘出来？

这就是需求收集的工作。在我看来，这绝不是一个被动等待的过程，而是一项需要我们主动出击、运用多种侦查手段的系统工程。

2.2.1 学习目标

在这一节，我的目标是为我们装备一套实用的“需求挖掘工具箱”。我将带大家梳理需求的来源，并详细介绍几种我最常用且行之有效的收集方法，包括但不限于竞品分析、用户访谈等。学完本节，我希望我们都能根据不同的目的和场景，自信地选择并运用最合适的工具。

2.2.2 需求的来源

在动手挖掘之前，我们先要画出“藏宝图”，明确需求可能藏在哪些地方。我习惯将所有的需求来源归为两大类：外部需求和内部需求。一名优秀的产品经理，必须同时对这两个方向保持敏锐。

1. 外部需求
   这类需求来自于我们公司“围墙”之外，是市场和用户的直接声音。它包括：

   • 用户：通过用户访谈、反馈、调研等直接获取。
   • 客户：对于B端产品，这是指付费客户提出的具体要求。
   • 竞品：通过分析竞争对手的动向和功能。
   • 市场/行业：宏观的政策变化、技术趋势、社会热点等。

2. 内部需求
   这类需求源自于公司内部的各个协作方，通常服务于公司的战略和商业目标。它包括：

   • 老板/管理层：基于公司战略发展提出的方向性要求。
   • 运营/市场团队：为支撑某项运营活动或营销策略而提出的产品需求。
   • 销售/客服团队：来自一线炮火声，为解决客户问题或促进销售而提出的需求。
   • 技术/设计团队：出于提升系统性能、优化架构、统一设计规范等内部优化目的提出的需求。

2.2.3 需求收集方式分类

了解了需求的来源，我们就要选择具体的“挖掘工具”了。在此之前，我先把这些工具（也就是收集方法）从性质上分为两类：定性方式和定量方式。想清楚用哪类方式，能让我们的目标更明确。

• 定性方式（Qualitative）
  我用它来回答“为什么”。当我需要深入探索用户的动机、感受、行为背后的原因时，我会采用定性方式。它的特点是样本小但洞察深。比如，我可以通过访谈，真正理解一个用户为什么对我的产品感到“不爽”。

• 定量方式（Quantitative）
  我用它来回答“是什么”和“有多少”。当我想验证一个假设、或者了解某个现象的普遍性时，我会采用定量方式。它的特点是样本大且结果可以被统计，能反映普遍规律。比如，我可以通过问卷，了解到底有百分之多少的用户认为我的产品“不好用”。

为了方便你理解，我总结了下面的表格：

2.2.4 常见的需求收集方法

在我的工具箱里，有许多种具体的需求收集方法。经过多年的实践，我筛选出了最高效、最常用的一批，它们几乎能覆盖我工作中90%的场景。这些方法包括：

• 用户访谈：通过对于用户的访谈掌握需求
• 问卷调查：通过发放调查问卷来调查
• 竞品分析：通过竞争对手身上所知
• 头脑风暴：与团队进行奇思妙想
• 观察法：观察身边的情况
• 实地体验（观察法）：对于实际地点去实地调研
• 数据分析：通过已有或网络的现成数据进行分析

在接下来的小节中，我将重点挑选其中几个最为核心的方法，为大家进行详细的拆解和说明。

2.2.5 竞品分析

我有一个观点：我们永远不应该闭门造车。竞品分析，对我来说，不是为了抄袭，而是为了站在巨人的肩膀上，洞察我们所处的“战场”格局，从他人的成败中学习，最终找到我们自己独特的取胜之道。

1. 竞品的定义与分类

首先，我们要明确谁是我们的“竞品”。我的定义很简单：任何正在与我们争夺同一批目标用户的时间或金钱的产品，都是我们的竞品。

在分析时，我不会把所有竞品混为一谈，而是习惯将他们分为三类，采取不同的应对策略。

• 直接竞品：这是最显而易见的对手。我们的目标用户、产品形态和核心功能都高度重叠。比如，如果我是做“美团外卖”的PM，那“饿了么”就是我的直接竞品。我们是在同一个赛道里进行着刺刀见红的肉搏。
• 间接竞品：他们的目标用户和我们有重叠，但是满足用户需求的产品形态或解决方案不同。比如，对于外卖平台，“方便蜂”“7-11”等便利店，甚至“叮咚买菜”这样的生鲜电商，都是我的间接竞品。他们都在解决用户“足不出户解决吃饭问题”这个需求。
• 潜在竞品：这类产品目前和我们没有直接竞争，但未来有可能凭借其资源、技术或用户规模，跨界进入我们的领域。比如，一个拥有海量流量的社交巨头，如果某天宣布要大力发展本地生活服务，那它就会立刻成为我最警惕的潜在竞品。

为了方便我们快速识别，我总结了下面的表格：

2. 竞品分析方法

明确了要分析谁，下一步就是“如何分析”。仅仅是截几张图、看几个功能是远远不够的。我需要一个框架来保证分析的系统性和深度。我个人最推崇的，是用户体验五要素模型。它能帮我像剥洋葱一样，从表到里地把一个产品彻底解构。

1. 表现层 (Surface)：这是最表层的，用户能直接感知的视觉设计。包括配色、字体、图标、布局的美感等。
2. 框架层 (Skeleton)：这是界面的骨架，决定了信息在页面上的排布。比如按钮放哪里，搜索框放哪里，导航怎么设计。
3. 结构层 (Structure)：这是产品的流程和信息架构。用户从一个页面如何跳转到另一个页面？产品的功能模块是如何组织的？
4. 范围层 (Scope)：这是产品具体包含了哪些功能和内容。比如，一个电商App，它的范围层就包括了商品展示、购物车、订单、支付等一系列功能。
5. 战略层 (Strategy)：这是最核心的，产品的商业目标和用户需求是什么？它为什么要做这个产品？

当我用这五个层次去分析一个竞品时，我看到的就不再是一个个孤立的界面，而是其背后完整的产品思考和商业逻辑。

3. 竞品分析的适用场景

我做竞品分析，从不是为了分析而分析，一定是带有明确目的的。以下是我认为最有价值的几个应用场景：

• 了解行业：当我刚进入一个新领域时，我会把市面上Top3的竞品，用五要素模型完整地分析一遍。这是我快速了解行业格局、用户现状和主流玩法的最佳途径。
• 产品设计：在设计某个具体功能时，比如“购物车”，我一定会去体验至少5个主流App的购物车是怎么设计的。我的目的不是抄，而是去归纳总结，了解业界成熟的设计模式，避免重复造轮子和踩坑。
• 寻找差异化：通过对主要竞品的优劣势分析（比如使用SWOT模型），我可以清晰地看到市场上的空白地带和未被满足的需求。这对于我们制定差异化竞争策略、找到自己的生态位至关重要。
• 方案验证：如果我的某个直接竞品上线了一个新功能，并且获得了很好的市场反馈，那它在某种程度上帮我验证了这个功能背后的用户需求是真实存在的。反之，如果竞品的功能失败了，那它也等于免费给我上了一课。

2.2.6 用户访谈

在我看来，数据能告诉我用户“做了什么”，但只有用户访谈能告诉我，他们“为什么这么做”。它是产品经理建立用户同理心、挖掘深层次需求的终极武器，没有任何工具可以替代。

1. 用户访谈的定义与流程

用户访谈的定义：对我而言，它是一场有目的、有结构的、一对一的深度对话。我通过这场对话，来探寻用户在特定场景下的行为、动机、态度和痛点。它是一种定性研究方法，我追求的是洞察的深度，而非样本的数量。

一场专业的访谈绝不是一次随意的聊天，它需要我进行精心的策划和准备。我通常会遵循一个六步走的流程：

1. 确定访谈形式：首先，我要决定访谈的方式。是成本较高但信息丰富的线下面对面？还是高效便捷的电话/线上视频？
2. 明确访谈目的：在开始前，我必须能用一句话说清楚“我这次访谈想解决的核心问题是什么？”例如：“探究用户在深夜场景下点外卖的核心决策因素。”
3. 用户筛选：我需要找到“对”的人。根据我的访谈目的，我会设定清晰的用户标准（比如年龄、使用频率、所在城市等），然后通过问卷或后台数据进行筛选。
4. 设计访谈问题：这是访谈的灵魂。我会提前准备一份访谈提纲，里面包含了一系列精心设计的开放式问题。
5. 邀请用户访谈：我会正式地联系并邀请筛选出来的用户，说明我们的目的、时长，并通常会提供一些小礼品（如礼品卡、代金券）作为答谢。
6. 结果汇总与分析：访谈结束后，我会立刻整理访谈记录，然后将多次访谈的结果放在一起，寻找其中反复出现的模式、观点和痛点，最终提炼出有价值的洞察。

2. 访谈问题设计要点

访谈的成败，很大程度上取决于我问题的质量。我设计问题时，会重点把握以下几点：

问题设置的方向：
我的访谈问题通常会遵循“现状 → 痛点 → 方案”的逻辑顺序展开，层层递进。

• 现状类问题：用于“破冰”，了解用户当下的行为和场景。如：“能带我回忆一下，您上一次点外卖的全过程吗？”
• 痛点类问题：用于挖掘用户的挫折和不满。如：“在刚才您描述的整个过程中，有没有哪个环节让您觉得特别麻烦或者不爽？”
• 方案/期望类问题：用于探寻用户的期望和潜在需求。如：“如果抛开所有限制，您心目中最理想的外卖App应该是什么样的？”

问题设计的方式：

• 多问开放式问题：我从不问“你喜欢我们的App吗？”这类可以用“是/否”回答的问题。我会问：“关于我们的App，你有什么样的使用体验和感受？”
• 不断追问：当用户提到一个关键点时，我最常使用的工具就是追问“为什么？”“可以再多讲讲吗？”“后来呢？”。这能帮我挖得更深。
• 避免引导性提问：我绝不会问“你是不是觉得我们的红包功能很难找？”。这会把我的观点强加给用户。我会问：“您平时会使用我们的红包功能吗？可以聊聊您使用它的过程吗？”

3. 用户访谈示例

我们还用外卖平台的案例。假设我的访谈目的是“了解白领用户在办公室选择午餐外卖的决策过程”。我的问题可能会这样设计：

• （现状） “您可以回忆一下昨天中午点外卖的经历吗？从你想到要点外卖，到最后拿到外卖，都发生了什么？”
• （痛点） “在挑选餐厅和菜品的过程中，有没有哪个环节让您觉得很纠结或者浪费时间？”
• （追问） “您刚才提到‘选来选去最后还是点了常吃的那家’，为什么会这样呢？”
• （期望） “如果我们可以帮您解决‘选择困难’这个问题，您希望我们怎么做？”

4. 注意事项及适用场景

• 我的注意事项：

  1. 多听少说：访谈的主角是用户，我的任务是引导和倾听。
  2. 保持中立：无论用户怎么夸奖或吐槽我的产品，我都要保持客观，不争辩，不解释。
  3. 事实与观点分离：记录时，要严格区分哪些是用户说的“事实”，哪些是我自己的“分析和判断”。

• 适用场景：我通常会在项目的早期探索阶段大量使用用户访谈，因为这时我对用户和问题还很模糊，需要建立认知。此外，在新功能的构思和验证阶段，我也会通过访谈，向用户展示原型或概念，来快速获取反馈。

为了方便我们回顾，我将用户访谈的核心要点总结在下面的表格里：

2.2.7 实地调研

如果说用户访谈是“听其言”，那么实地调研就是“观其行”。在我看来，这是两种方法最大的区别。很多时候，用户说的和他实际做的并不完全一致，而实地调研，就是让我有机会亲眼去见证这种差异，发现那些连用户自己都未曾察觉的隐性需求。

1. 实地调研的定义

对我而言，实地调研就是产品经理亲自进入用户的真实物理场景中，通过近距离观察和亲身体验，来理解用户行为和背后动机的一种研究方法。

它包含两种核心形式：

• 观察法：我像一个“隐形人”，在不打扰用户的前提下，静静地观察他在特定场景下是如何与环境、工具（包括我们的产品）进行互动的。
• 实地体验：我亲自扮演用户的角色，走一遍他完整的任务流程，切身感受他在每个环节的顺畅与阻碍。

2. 如何进行实地调研

一次有效的实地调研，需要我像导演一样，精心设计整个过程。我通常会遵循以下四个步骤：

1. 进入场景：这是第一步，也是最关键的一步。比如，我要研究餐厅后厨的采购流程，那我就必须真的穿上工作服，走进那个潮湿、繁忙的后厨，而不是坐在办公室里想象。
2. 用户角色：进入场景后，我要明确我的角色。我是作为一名旁观者去“观察”？还是亲自上手，作为一名“学徒”去“体验”整个下单、验货、入库的流程？
3. 观察体会：在场景中，我的所有感官都要打开。我会重点观察：用户在做什么？他使用了什么工具？他与其他人是如何协作的？他在哪个环节面露难色？哪个环节的效率特别低？如果是我自己体验，我会记录下每一步的感受。
4. 持续进行：一次调研是远远不够的。我会选择不同时间、不同类型的场景（比如高峰期与平峰期的餐厅后厨）进行多次调研，以确保我看到的不是偶然现象，而是普遍存在的问题。

3. 实地调研适用场景

实地调研虽然强大，但成本也很高，所以我必须在最需要它的地方“对症下药”。以下是我最常使用它的几个场景：

• 挖掘需求：当我要为一个全新的领域（比如智慧农业）设计产品时，我对用户的真实作业环境一无所知，这时实地调研是建立基础认知的唯一途径。
• 理解需求：当用户向我提了一个我无法理解的需求时，比如“你们的扫码枪不好用”，我会直接去他的仓库，看他到底是怎么用的，问题出在哪里。
• 效果验证：我的新功能上线后，我会去现场观察用户是如何使用它的，是否符合我的设计预期，有没有出现我没想到的问题。
• 寻找问题：当我的产品数据出现异常，比如某个环节转化率突然下降，我会去实地观察，看看是不是用户的线下操作流程发生了变化，从而导致了线上的问题。

实地调研是我们产品经理走出办公室，拥抱真实世界的最佳方式。我把它总结为以下要点：

2.3 需求管理

对我来说，如果说需求收集是“狩猎”，那么需求管理就是“庖丁解牛”和“精细烹饪”。我需要一个系统化的流程和工具，来处理我收集到的所有“食材”（需求），确保最有价值的部分能被优先端上“餐桌”（进入开发）。这个系统的核心，我称之为**“需求池”**。

2.3.1 学习目标

在本节中，我的目标是带大家学会如何搭建和维护一个健康、高效的需求池。我将分享需求池应该包含哪些关键信息，需求在池子里会经历怎样的生命周期，以及我始终坚持的管理原则。学完本节，我希望我们都能成为一名思路清晰的“需求管家”。

2.3.2 需求池定义

需求池，顾名思义，就是一个用来汇集和管理所有需求的“池子”。我把它定义为：一个用于统一记录、跟踪和评估产品所有相关需求的中央数据库。它是我管理产品的“唯一事实来源”，我通常会用Jira、Trello或一个功能强大的Excel表格来搭建它。

为了让这个池子有效运转，我记录的每一条需求，都必须包含一些标准化的信息字段，其中最重要的包括：

• 产品模块：这个需求属于哪个功能板块？（如：登录注册、订单流程）
• 需求描述：用清晰的语言描述用户场景、痛点和期望。（What & Why）
• 优先级：这个需求有多重要？（我常用P0/P1/P2/P3来划分）
• 需求提出人：这条需求来自谁？（如：用户A、销售部、老板）
• 需求类型：这是一个新功能、体验优化、Bug还是技术需求？

2.3.3 需求状态

进入我需求池的每一条需求，都不会石沉大海，它会拥有一个清晰的生命周期。我会通过“状态”这个字段来追踪它的进展。一个标准的需求生命周期流程如下：

1. 待确认：这是需求的入口。所有新收集到的、未经我详细分析的需求，都先放在这里。
2. 已确认：经过我的分析，确认这是一个真实、有价值的需求，但还没想好什么时候做。
3. 规划中：需求已通过评审，并被正式排入某个版本迭代的开发计划中。
4. 已完成：需求已开发、测试、上线。这是它旅程的终点。
5. 已拒绝：经过分析，我认为这个需求价值不大、或与产品方向不符，决定不做。给需求一个明确的“死亡”结果，同样非常重要。

2.3.4 需求池的作用

我之所以如此看重需求池，是因为它为我、为整个团队都带来了巨大的价值。

• 管理需求：它是所有需求的统一入口和视图，避免了需求散落在邮件、微信、会议纪要里，造成遗忘和混乱。
• 维护需求：我可以随时查看任何一个需求的状态、优先级和负责人，对整个产品的迭代节奏了如指掌。
• 回溯需求：当未来有人问“我们当初为什么要做这个功能？”时，我可以立刻从需求池里调出当时的背景、分析和决策过程。它是我们产品决策的“历史档案”。

2.3.5 需求池管理原则

一个只进不出的需求池，很快就会变成一个令人绝望的“需求坟场”。为了保持它的活力和价值，我始终坚守两条管理原则：

1. 有进有出：需求池必须是流动的。我需要定期（比如每周）审视池中的需求，推动它们的状态向前流转。要么进入规划，要么明确拒绝，绝不能让大量需求长期停滞在“待确认”状态。
2. 宽进严出：对于需求的“进入”，我持开放态度，鼓励各方提出想法，所以入口要“宽”。但对于需求的“输出”（即进入开发），我必须严格把关，基于用户价值、商业目标、投入产出比等因素进行严苛的筛选和排序。

我将需求管理的核心要点，总结在下面的表格中：

2.4 本章总结

在这里我附上需求池模板供读者使用

最后，我们来回顾一下整个第二章的核心脉络。我认为，一名合格的产品经理在处理需求时，必须走完这三个密不可分的步骤：

1. 认知需求：首先，我们要能透过现象看本质，深刻理解“什么是需求”——它不是用户说的原话，而是能解决用户在特定场景下本质痛点的方案。
2. 收集需求：其次，我们要主动出击，运用竞品分析、用户访谈、实地调研等多种手段，从内外部多个渠道，系统地“如何收集需求”。
3. 管理需求：最后，我们要建立并维护一个动态、健康的需求池，对所有需求进行科学的“需求管理”，确保我们永远在做最有价值的事。

掌握从认知、收集到管理的完整闭环，是我们做出成功产品的基石。