编辑导读：需要和需求虽然只是一字之差，但是状态是完全不同的。通常情况下，用户只会告诉我们他需要什么，而需求则是要将用户所说和用户所做相匹配，再去明确真正的需求。本文作者结合案例，对用户需要和用户需求这两个概念展开了分析说明，与大家分享。

业务方总会从四面八方提出各种各样的需求，多问一个为什么，或许能得到真实需求。

上个月一个例子：

业务方：能否在现在邀请中心的页面增加一个入口，可以保留上一个月的页面。

我：为什么要保留上一个月的页面？

业务方：不然用户等到8月份之后，怎么领取7月份的奖励呢？

我：7月份的奖励会在什么情况下，需要等到8月份才能领取呢？

业务方：就比如用户邀请好友报名正式课，但是我们的规则是限定要消课满一定数量才能获得奖励，所以就会出现这种情况。

我：那就应该是有一个领取历史奖励的入口，查看哪些奖励是还没有领取过什么、领取过什么，对吧？

业务方：对的。

一、需要和需求

从上面那个例子可以发现，需要和需求是两种不同的状态。通常情况下，用户只会告诉我们他需要什么，而需求则是要将用户所说和用户所做相匹配，再去明确真正的需求是什么。

需要集中体现为用户对于产品的不满。不满的原因有很多，通常是业务方觉得系统功能不能满足他们的使用场景、不方便不高效；家长觉得APP功能相较其他产品不够便捷，对比之下发现的不满。需要大部分都是自我感知，所以总是会听到“我觉得”、“我感觉”、“我认为”等开头语。

和需要不同，产品需求是针对一个具体的产品的具体行为下产生了可衡量的需要。需要是需求的前提，但是需求要将用户行为来衡量，现有的资源和需求达到效果之间是否匹配。

之前做过一个关于批量绑定的功能。当时听到业务方说“一个一个绑定太麻烦了，为什么不出一个批量绑定的操作呢”，只是想到业务方需要这个，ta的感知就是觉得“诶重复操作好多，一个一个操作好浪费时间”，所以就策划了这个功能。

但是等到功能真正上线后，并没有人去使用批量绑定。原因在于在绑定前，业务方都会仔细核对绑定信息，确保绑定正确，因此都会使用到单个绑定中的“查询功能”，所以也就没人去使用批量绑定功能了。

因此从这个功能后，凡是业务方提出的反馈，我会多问一个为什么：为什么现在的不行，、这个是用来做什么的，你一般会怎么用它，对现在工作有什么影响…

通过不断追问用户行为，获得真实需求。

二、追问用户行为，获得真实需求

在开始成为产品经理前，接触过黄金圈法则。这个法则帮助我从用户那里获取到需求。从外到内依次是what、how、why。

• what：是用户告诉我的需要。通常可以从日常交流、问卷收集、功能反馈中得到这些信息。
• how：是用户对某个具体产品的具体行为。也就是从这里开始，可以去衡量这是否是用户真实的需求。
• why：是用户内心真正的需求。用户行为背后的原因。为什么使用这个产品而不用别的产品。

用上个月的一个“采购数据”例子说明 使用黄金圈法则来练习获得需求的过程：

1. what

采购方希望将订单管理页面的班主任和CC信息删除。原因是他们觉得这4列数据（包括2列团队数据）都不怎么使用了，所以基本上可以去掉。

2. how

用户说要把数据去掉，通常都会询问为什么要这么做。这时候是了解用户使用场景的“好时候”。

采购方说他们通常用这个页面导出订单安排发货等事宜，所以只需要具备学员信息、收货人信息等关键信息即可（他们认为班主任信息是多余的）。当用户描述的行为和之前的功能相违背时，或许要更深入去求证。

继续询问后发现，班主任信息是在少部分家长因发货时遇到地址错误或收货信息不匹配等情况才需要去找对应班主任，联系家长确认才会使用到这些信息。但是现在采购不负责这一块了，加上之前采购都会导出Excel表交给对应负责人沟通，因此采购方觉得这项可以去掉。

3. why

沟通下来之后发现，采购方感知到“去掉这4列信息”的原因在于自己不对接这块了+使用频率变少了。但其实班主任信息是必要但不是主要。

因此真正的需求占页面篇幅需减少并置后，才能够让采购一打开页面就能在列表最主要位置看到想要的信息。

4. 方案

画好原型输出方案后，可以询问需求方对方案的意见，这样可以更好确认方案是不是符合需求方的使用场景。

三、告诉开发这是真实需求

在明确了业务方的真实需求后，同样也是需要告诉开发的。对于目前接触到C端产品来说，特别是做用户增长，开发和测试不仅仅是研发技术人员，更是需要他们去了解产品为什么做，怎么来的这个需求。

所以在写需求文档的第一步，要明确告知开发需求的背景、用户场景、需求分析、竞品调研。

• 背景：说明现在的问题是什么，现状与用户使用之间产生了什么（矛盾），会带来什么影响。因此需要开发什么需求，达到什么目标（尽量是具体的数值）
• 用户场景：描述在什么时候，什么人做什么事，达到了什么结果/产生了什么影响。这一部分也是在给产品开始写需求文档前的一次准备：这个需求的方案是否真的符合用户在这类场景的诉求
• 需求分析：是怎么发现这个需求的（角色提出、竞品参考、场景经历…）
• 竞品调研：针对需求方案，寻找竞品或者非竞品中能满足同样场景的功能参考。一来是可以看看别人的设计交互，能够结合到自身产品使用；二来也是能帮助自己判断这个需求的真伪性。

业务方每天都会将自己对产品的使用体验、家长反馈告诉我们，在接收到反馈的同时，需要从中提取需求、规整需求，多一步思考、多问用户行为。

本文由 @莫琳 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议