原标题：如何有效获取B端需求

很多产品同学在创业公司，可能因为话语权不够，所以导致可能开发直接对接需求。但需要明确的是，产品一定是对接需求的。产品经理这个岗位存在的意义就是因为需求的存在。用户需求不等同于系统需求，相信自己介入需求到开发中的价值。

调研需求之前，我们需要在内心有一个好需求的摸样，可以遵循GPSPAC原则。

• Goal目标：为什么要去做这个事情？
• Process流程：达成目标所需要的组织协调方式；
• Scene场景：流程中所有可能出现的状况（正常、异常）；
• Person人员：特定场景中涉及到的人/部门；
• Action行动：特定场景下的人进行的判断和动作；
• Check检查：对于人员所需要采取行动的检查（非必选）；

有了一个“标准”的答案在心里了，那么你在纷繁复杂的业务中调研需求的时候，就不会被业务牵着鼻子走，你会顺着你的标准来引导业务向你娓娓道来你想要的，去抓住GPSPAC。

二、获取B端需求

获取需求之前先明确需求的背景，明确需求的价值和厘清目前现在业务的现状。更重要的是识别需求的真伪性，不要被用户牵着鼻子走。不要只听一面之词，兼听则明。

2.1 获取需求

明确需求背景

需求背景是整个产品设计的前提，只有深刻了解背景里所存在的问题、及对应的用户痛点，才能把握好产品的设计方向。同时只有大家都认可这个背景的真实、有效和价值，才能够更好推进产品方案的落地。

完整需求背景的一般包含三个部分：用户、场景和需求。即用户在什么样的场景下，遇到什么样的问题/或者对于当前的产品产生了怎样的需要或者诉求。或者更深入一点，何人在何地，因为什么原因，用什么方法做了什么事情，做到什么程度/取得了什么结果。

5W1H具体指的是：

• 何因（Why）：原因
• 何事（What）：对象或什么事情
• 何地（Where）：地点
• 何时（When）：时间
• 何人（Who）：人员或责任人
• 何法（How）：方法或程序

此外，有的时候也会加入”多少”（How Many），用以进一步明确数量级和规模。这种方法鼓励从原因、对象、地点、时间、人员和方法这六个方面对选定的项目、工序或操作提出问题进行深入思考。例如，公司生产什么产品？这个产品在哪里生产？为什么要生产这个产品？这些产品是什么时候生产的？这些产品是由谁来生产的？以及这些产品是如何生产的？等等。这种多角度的思考方式可以帮助我们更全面地理解一个问题或者情况，从而做出更加明智的决策。

在产品设计的时候，应该就用“用户+场景+需求”的句式来反复确认，产品背景是否把握准确未偏离方向；向开发介绍的时候也应利用这种句式，逻辑清晰地向他们传达出功能背后的价值。

厘清现状

• 不解决谁会难受？
• 有多难受（最好有量化指标，比如：不做就要有多少人线下花费多少时间成本去做？错误率，风险等等）
• 多久难受一次（频次)
• 目前的方案是怎么做的

明确需求价值

• 这个需求从哪产生的？
• 解决了什么问题？
• 我们目前的资源足以完成这个吗？
• 这一块业务中最痛的痛点是什么？
• 为什么过去没做，未来不做，而是现在做？

注意：对于用户我们只挖掘问题，不挖掘方案；

2.2 需求的价值

生产效率的思考角度

• 整体协同链路的效率提升 。(如报销到放款时间降低，退款时间降低等，管理痛点）
• 单位生产资料的产出提升或单位产出的成本降低 。(如销售访客数的上升，一个客服接电话数的上升，操作痛点）
• 规模化下决策难度降低或准确率提升。(如数据报表，业务诊断，智能化工具等，决策痛点）

不同解决方案的不同价值定义

• 数字化：定性为主（定性如跑通流程，全链路可视）, 定量为捕（如反馈时效提升等）。
• 自动化：定性+定量，以定量为主。
• 智能化：必须定量。

定性：以完成特定的任务或动作为考核方式，如流程跑通，能够看到数据等，主观性强。

定量：以达成特定的数值为考核方式，如100万gm,获得100个新客等，客观性强。

2.3 识破伪需求

真需求还是伪需求，want or need？

用英文就可以清晰地区分：伪需求叫 Want，真需求叫 Need。Want的东西用户不一定会掏钱，Need 的东西用户一定愿意掏钱。所以识别出 Need 的需求是需要优先实现和满足的，减少或者不做What需求。

要想获得真需求，就要搞清楚用户要通过产品达到什么样的目的，产品经理需要跳脱既有的思维和主观的判定，同时也不能轻信用户直接反馈的解决方案，要不断地问为什么，去挖掘背后真正的原因。对单个需求通常可以问以下问题，识别出需求的不同，进而进行优先级排序：

• 需求强度：用户是否痛？有多痛？
• 需求频次：多久痛一次？
• 持续时间：是否持续地痛？
• 广度：有多少用户有类似的痛点？
• 付费意愿：用户为此痛点付费的意愿如何。

挖掘真需求的理论方法

• 挖掘需求的理论方法有很多，比如用户调研、数据分析、竞品分析等等。其中用户调研包含核心用户反馈、问卷法、访谈法、实地调研。
• 在分析客户的需求的时候，要懂得无视他们想要的东西，去探究其内心真正的渴望，如此才能给出更好的解决方案，或者说是用户真正需要的东西。

总结：

什么是“伪需求”？

• 缺乏充分的使用场景，看似有用实则没有相应的适应场景；
• 可有可无，并不解决核心痛点的“增量需求”；

如何识别伪需求？

• 需求收集阶段，不光听用户的说辞，要找到真实的使用场景、说辞背后的动机；
• 从动机入手设计解决方案，而不是拿用户提出的“设计”直接作为解决方案；
• 原型阶段，做用户测试，倾听用户的使用感受；
• 重要功能，灰度上线/试点上线，避免集体翻车；

1.如何判断项目的紧急程度？ 短期不做会不会死？

2.如何判断项目的重要程度？”长期不做会不会死？

3.优先级=(重要程度+紧急程度)/研发成本

4.是否影响到主流程的继续运转？如果没有，那就可以有相对充裕的时间进行调研；

5.是否必须修复功能才能满足业务需求？例如页面的数据导出功能出问题，用户无法导出数据，那么可以直接从数据库中导出数据并提供给用户，在这种情况下，主流程不受影响。

3.2 优先级准则

1.高优高价值：需求价值为先，即高价值的需求优先做;

2.领导很关注：高层级及”大噪门”酌情考虑,即老板需求和高压力的需求适度提高优先级;

3.分配要合理：小中大需求合理调配，即保证资源充分利用的基础下小中大需求齐头并进（建议235或226的比例分配）；通常需求的价值与需求大小成正比；

4.各方要对齐：充分沟通，分配透明，即优先级的安排需要与各方充分沟通，尽量达成一致，并且及时将进度与优先级同步所有关联方；

总之，需求优先级的排布是一门艺术而不仅仅是技术。

3.3 需求池的管理

需求四象限时间管理法

P0重要紧急；

a.处理方法：立即去做；

b.饱和后果：压力无限增大、危机；

c.原则：越少越好，很多第一象限的事情是因为他们在第二象限时没有被很好的利用；

P1重要不紧急；

a.处理方法：有计划去做；

b.饱和后果：忙碌但不盲目；

c.原则：集中精力处理，投资于第二象限，做好计划，先紧后松；

P2不重要紧急；

a.处理方法：交给别人去做；

b.饱和后果：忙碌且盲目；

c.原则：放权给别人去做；

P3不重要不紧急;

a.处理方法：尽量不做；

b.饱和后果：浪费生命；

c原则：可当做调节身心，但是不能沉溺于这个象限；

P0需求量控制在不超过25%；

P1保持长期投入，每个迭代预留一定的资源（建议小于20%）；

注意：需求的优先级不是一成不变的，每当有新需求的加入，或者业务的变化，同时伴随着需求池的更新，更是对业务的再思考。

需求池需求的类型

1.功能改进类需求

2.体验提升类需求

3.BUG修复类需求

4.新增功能类需求

5.其他需求

秉持宽进严出的准则

四、如何分析B端需求

第一步：业务部门、岗位及职责梳理。

第二步：业务流程梳理。

第三步：业务流程确认。

第四步：3W1H法则，系统功能点拆解。

第五步：系统流程图的出具。

五、需求的交付和落地

理清逻辑并将逻辑准确无误地同步到开发，是产品的基本工作,越复杂的需求越需要这样。如果因为产品自身的局限性，担心产品逻辑不是最理想方案或者可行性问题，那可以在方案完成前提前与开发leader/核心开发沟通。否则，让开发对产品逻辑自由发挥，就是在为后面迭代或者后人埋坑。

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

题图来自Unsplash，基于CC0协议