需求不是“听用户说了什么”，而是“理解业务真正缺了什么”。本文从产品经理的认知体系出发，系统梳理从需求发现、价值判断到落地复盘的关键路径，帮助产品人构建更扎实的需求判断力与业务穿透力。

上一篇文章，我们聊了“用户”，从外部用户到内部用户，搞清楚了“for who—服务谁”；见产品经理认知体系《用户篇》

接下来，自然要聊“for what—做什么”，也就是需求；

产品经理80%的精力都花在需求上：获取→分析→验证→落地→ 复盘，循环往复；

用户是抽象的，需求是具体的。用户是彼岸，需求是舵手。掌握舵手，才能驶向彼岸。

一、什么是需求

需求，就是用户在特定场景下的期望和要求；

它不是解决方案，也不是功能实现，而是要解决的问题或达成的目标；

先把需求说清楚，后续方案才会有针对性；

产品经理的第一要务，就是定义“什么是用户的需求”；

需求的定义，决定了后面如何评估优先级、可行性和价值。

二、需求收集

需求的来源，可以分为直接来源和间接来源

直接来源来自用户，包括内部业务方、领导，以及外部用户，常见有：

• 用户反馈
• 调查问卷
• 业务方反馈
• 内部规划/战略目标等

间接来源更多依赖产品经理的观察与推理，比如：

• 数据分析
• 竞品研究
• 行业趋势洞察

产品经理要有自己的“需求池”，记录需求的提出方、背景、优先级、业务价值、依赖项等，便于管理和排期；

无论间接需求还是直接需求，产品经理都需要经过分析论证，识别真伪，不能照单全收。

三、需求分析

需求方很多时候说不清自己想要什么，甚至未必意识到自己的真实需求；

产品经理工作核心价值之一，就是通过沟通、追问和数据验证等方式，发现用户的“真需求”；

常见误区：用户给出的往往是解决方案，而不是真需求例1：业务要做AI聊天功能

• 为什么要AI聊天？—方便和用户沟通
• 为什么要AI沟通？—客服太忙，响应慢
• 为什么客服太忙？——大量重复问题
• 为什么大量重复问题？——新功能上线，没有提前做FAQ
• 真需求：展示常见问题清单，帮助用户快速解决问题，而不是引入AI聊天

例2：用户期望商品能够被收藏

• 为什么要收藏？—方便以后看
• 以后为什么要看？—关注有没有降价
• 真需求：收到商品降价提醒，而不是一定要“收藏夹”这个功能；

常见的需求分析方法：

• 5Why分析法：不断追问“为什么”，挖掘用户背后真实需求
• 用户旅程（5W2H）：正序拆解用户在不同节点的痛点和诉求，提供对应解决方案
• 多维交叉验证：通过逻辑判断、数据验证、竞品比对来交叉确认
• demo测试：基于可视化的设计稿或者demo进行用户测试，验证需求真伪并收集问题

四、需求优先级

同一时间可能有多业务方提过来的多个需求，产品经理需要有一套标准来明确需求优先级，保证有限资源投入最重要事情

不同阶段，业务目标不同，对应的划分标准也有区别：

• 新功能上线：先保证核心链路跑通，非核心先放一放
• 快速增长期：优先做能覆盖更多用户的通用功能，高阶小众功能延后
• 成熟期：按项目分化，更注重商业价值和ROI，比如在我团队，电商所有功能都要求业务方提供带来的GMV，基于GMV排序
• 资源限制：大需求和小需求可以搭配推进，保证产出

常用方法：

• 二分法：重要/紧急，适合快速判断
• Kano模型：区分基本型、期望型、兴奋型需求
• RICE模型：用影响人数、影响程度、信心、投入成本，来量化优先级。
• 价值量化法：我做电商常用方法，强制评估需求对应的GMV增量，多业务部门PK

注意：价值量化是一种预测，预测就可能出错。要定期复盘，如果某个业务方总是夸大价值，下次就要打折扣对待。

五、方案设计

明确优先级之后，进入方案设计阶段，方案设计是解决“怎么做”的问题，产品通过PRD文档对研发描述清楚

方案需结合限定资源和技术边界，给出符合商业价值的解决方案，需考虑整体项目ROI

方案设计维度：

• 目标性：方案交付后预期目标是什么，影响了哪些指标变化
• 逻辑性：解决的是否是真实/系统性问题，当前方案是否是最优解决方案
• 完整性：多系统/边界场景/异常场景是否充分考虑
• 可扩展性：对可遇见的业务形态、复杂问题保留了扩展升级的可行性

交付物PRD核心字段：

• 版本记录：对每次需求文档调整点的记录，包含修改内容、修改原因，大项目必须有
• 需求背景：对需求背景和问题的描述
• 需求目标：对预期目标的描述，包含本期功能目标（跑通全流程）、时间目标（xx前上线）、数据目标（带来100wGMV）
• 业务流程：对用户动线、业务流程的梳理，新产品建议有，让技术团队充分理解需求
• 功能清单：结合业务流程，需要提供的功能清单，可区分优先级和迭代范围
• 需求详情：对需求详情的详细拆解，最好有时序图、状态机、原型图、交互说明、数据埋点
• 里程碑：核心节点交付核心功能
• 风险与依赖：如涉及外部系统，需简要明确外部系统的能力和交付节点

注：产品经理交付不止是需求文档，可能是流程、服务或资料，比如配套的合同、培训材料和FAQ话术

六、需求上线

需求分析过程尽管有数据和逻辑支撑，但本质上仍是假设，既然是假设就可能出错；因此，重大功能上线前需要逐步放量，预留调整空间。常见灰度方式：

定向内测：

• 邀请小部分核心用户使用，收集意见反馈，优化后推广到普通用户，适用于新产品上线

AB分流：

• 通过分流工具，随机抽取小比例用户先使用新功能，验证新功能是否明显带来数据提升，然后逐步放量，直至开放给全量用户

过程中监控数据变化，收集用户反馈，如发现重大问题，能快速回滚，减少影响

案例：

• AI工具Manus先内测3个月，基于核心用户反馈，经多次优化迭代后，放开给普通用户注册
• 商品详情页改版先灰度给20%用户，3天后发现核心指标（支付uv/商详uv）提升明显，放量到50%，一周后正向明显，覆盖全量用户
• “先用后付”功能先灰度给5%用户，结果逾期率太高，果断暂停，补充风控策略后再推进

七、需求管理

需求管理贯穿从收集到上线全过程，硬件产品或TOB交付类项目一般配置专门的项目经理，大部分软件公司由产品经理担任项目经理角色，负责整个需求的交付节奏和结果；

产品经理需要关注的事项：

• 基于计划管理，如需求复杂&时间紧急，由角色负责人倒排计划，逐步由粗到细，无计划不管理
• 依赖流程管理，比如需求评审、需求变更、需求发布上线流程，如果没有推动建立
• 做好信息同步，减少信息不对称，明确各个角色分工，建立对应项目群，避免点对点沟通
• 做好风险预案，重大或者复杂项目，需要有风险预案，在依赖方出现delay情况下，如何处理

常见的管理工具：

• 项目管理工具和配套的流程
• 需求评审会、交互评审会、技术方案评审会、测试用例评审会、项目周会、日会等

案例：

• 老板层面安排的紧急需求，一般采用时间倒排，需求交互技术测试当面沟通，同步进行，需求也可以先从粗粒度往细节优化

八、复盘改进

产品上线后，需要通过复盘对项目的结果做核对校验，发现问题，总结经验，复盘是产品经理最主要的成长机会

大需求大复盘，小需求小复盘，一般包括三个方面：

假设的验证：

• 上线后的产品是否精确命中了目标用户群体，满足了他们的需求，
• 当初全选用户的逻辑是否合理，对用户需求的把握是否正确
• 哪些地方产生了遗漏，后续如何改进？

目标的复盘：

• 预估的目标是否合理，当时预估的逻辑是否正确
• 目标是否达到，超过/未达预期的理由是什么，如何达成

方案的复盘：

• 对需求优先级排序是否合理，核心功能是否完整
• 方案的设计是否合理，逻辑性、扩展性、完整性是否有遗漏
• 下一步如何优化，哪些功能要重点完善

管理的复盘：

• 是否如期发布，哪些点是最大的卡点
• 下次面对紧急需求如何处理，需要沉淀或补充哪些流程

最终结果：

• 好的continuedoing，差的stopdoing，需要的startdoing

九、常见坑

常见踩坑点，重点关注：

• 没找到真实需求，把解决方案当需求
• 跳过需求定义，过早就入方案设计
• 优先级不清晰，项目需求频繁变更
• 没有明确目标，上线后无法验证
• 没及时复盘，没有沉淀方法论

小结

需求，是产品经理的核心战场，是产品经理能力和价值的外在体现；

先搞清“why—为什么做”，再定“what—做什么”，最后才是“how—怎么做”；

假设要写清，优先级要量化，交付要可验，上线要复盘；

需求管理做好了，产品方向不会跑偏，团队资源也能用在最有价值的事情上。

下一篇我们具体聊聊，如何行动，才能发挥和体现商业产品经理的价值。