产品经理工作中，有很多一部分就是沟通了——和运营、设计、开发、老板沟通等。那么在耗费不少时间的沟通中，产品经理能否从中找到一些总结经验以及汲取产品知识的方法，避免重复沟通但是又没学到什么东西。本文中，笔者就介绍了相关的方法，希望对你有所帮助。

01 我是谁

我是入行两年的产品人钟倾，一直做B端的产品，以后会一直往B端的方向发展。

02 问题

做B端产品两年下来，从实习生到初级产品经理，我发现很多需求都是通过运营人员反馈得到的，而沟通工作会占据大量的时间，剩余的工作时间也被一些评审会、第三方对接会瓜分。

时间长了我就觉得我只是在重复劳动，自己的产品技能并没有提升；而且还会出现大量的纰漏，需求没有整理到位，在评审的时候需求会漏掉；上线的时候没有通知到相关运营人，导致运营人员在服务不到位；然后下一波需求又来了，完全没有空隙去深度思考产品。

所以为了改变这个工作状态，我自己反思了整个工作的流程，发现我们大部分的时间用在沟通需求上，而需求又是联结用户和产品的纽带，所以我可以通过日常的需求沟通来不断练习产品的相关的技能，那么如何做呢？

03 如何做

1. 解析需求，思考产品

在沟通之前需要做的事情，对需求进行筛选，排除伪需求和bug型需求，筛选出有价值的需求；然后我们通过对产品的理解去解析这些需求，列举出可能的实现方案以及需求场景，对现有产品进行查漏补缺。

1）我们为什么要这样做？

• 对产品本身来说：筛选出对产品有价值的需求能更贴近用户，增加用户对产品的粘性。
• 对个人来说：加深我们对现有产品的理解知道我这个功能最终是为了满足什么样的场景，解决用户什么样的问题。

2）具体怎么实践？

我把需求分为四大类：bug型需求、体验优化型需求、伪需求、值得深挖的需求，通过对需求的分类能节约我们对需求筛选的时间，提高团队协作，提升我们的工作效率。

在分类的基础上，我们要对需求进行简单的处理。

①Bug型需求

线上出现的问题，偶尔出现的；或者是大面积问题急需解决。

自己先验证这个需求是否真实存在，通过跟研发协同，每周给出一个小版本来快速迭代这些需求，通过需求的方式来快速解决bug，让运营人员和用户能快速感知到自己提出的问题得到完善；

如果没有这个需求，需要转交给相关的技术支持人员进行单独排查，让他们协助运营人员解决单个用户的偶然性问题。

②体验优化型需求

用户在使用产品时，有些步骤会反复操作会影响到他们的工作效率，希望通过优化组件或者相关功能提示来达到节约操作时间成本。

这样的需求需要协同UE和UI人员，看看能不能优化操作体验，根据优化的程度对其进行排期。优化程度比较复杂，需要重新设计组件或者连同整个功能一起优化的，那么需要排进功能性优化的大版本；优化程度比较简单的，排进bug型需求小版本中尽快优化。

③伪需求

看上去跟值得深挖的需求接近，但是多次提出没有解决的、技术上无法实现、与用户行为相违背。伪需求容易耗费我们大量的时间和精力去思考，而且需要花费一些时间给运营人员解释。

这样的需求，我们要想清楚，以前为什么没有这么做，这个需求确实对产品起到非常大的优化作用，但是为什么我们一直没有实现，这时候就要请教相关技术人员进行咨询；根据需求设计出来的产品放到场景中是否符合逻辑，如果不符合逻辑说明，这与用户行为习惯相违背。

④值得深挖的需求

符合产品规划的，在产品设计中并没有想到的，对现在产品设计不满意的。

这样的需求，需要我们重点关注，在需求列表中也需要标注出来，然后我们对相关的场景和用户行为进行进一步的研究，与运营人员进行精准沟通，在确认需求后进行归档和排期。

2. 精准沟通，深挖场景

在进行沟通时最重要的就是知道用户想要什么和怎么使用。  

 1）我们能获得什么？

• 对产品设计来说：明确了需求的价值，完善了产品覆盖的应用场景，帮助用户解决问题；
• 对个人来说：增强同理心，通过了解用户行为，加深对场景的理解，对产品上的创新有更多的帮助；验证自己的想法，强化对产品的理解。

 2）我将提问形式分为两类

①直接提问

一般用于运营人员对需求描述缺少我们对需求判断的信息，比如用户使用场景或者具体的用户行为。

我们需要通过提问的方式引导运营人员表达超出用户的原话，或者通过实际案例来说明这个需求是如何产生的。

②反问法

一般用于运营人员描述了完整的用户行为或者用户场景以及功能需要修改的地方，这样我们通过反问对方你猜想的修改后的用户场景和需求理解是否正确来验证。

通过沟通我们能获取比较详细的场景信息和用户行为，明确了需求的价值，然后我们进一步深挖场景。

3）如何进一步深挖场景？

①列举满足用户需求后产生哪些有可能的结果，根据列举的结果再反过来思考功能是否能满足用户达成这些结果。

对于需求的解决方案有很多种，在我们还没有定下来最终解决方案的时候，我们需要思考的是每种解决方案带来的后果，以及对前后流程有什么样的影响，你考虑的越周全，最终定下来的最优解就能越贴近用户。

②思考产品中有没有其他类似的应用场景。

在我们平时生活中其实也会遇到很多相似的场景，我们能更好的把自己想成是一个用户，将自己的遇到的场景带入产品中，将更多场景综合到产品中，增强产品的通用性。

③根据用户操作数据统计，分析跟该需求相关功能的指标。

需求对应的功能会产生大量的数据，数据分析是支持我们为什么要改善的强有力的证明，比如这个功能下一步跳出的数量和继续点击的数量进行对比，如果相差很大说明用户在这边的操作让他们放弃了，那么是什么让他们放弃的，是我们需要继续思考的问题； 如果相差不大，是不是用户觉得使用这个功能的效率不是很高，浪费了用户很多时间，或者是没有按照常规的操作接着往下走。

通过数据我们能找出用户行为超出常规逻辑的地方和出现异常的地方，能帮助我们对场景更加深入思考，慢慢完善用户使用逻辑，让用户觉得使用产品时又快又高效。

根据上面三步，我们能从需求中看到更多复杂的使用场景，将这些场景通过功能快速解决用户工作中遇到的问题，用户才会觉得这个产品是在帮助他达成目的。

3. 及时归档，及时反馈

归档也是整理，最简单的是整理产品需求，最复杂的是整理产品规划，所花费的时间肯定是成倍增多，但是规划总是从一点点小需求开始积累，不积跬步无以至千里，不积累需求无以成就好产品。

整理看似简单，但是也是产品流程中最最重要的也是最容易被忘记的一环。

如果我们没有整理的习惯，那么随着产品越做越深入的时候，会缺乏整体思维，很难发现需求与需求之间的关联，容易偏离产品核心。

当我们整理的技能不断强化，养成良好的习惯， 我们能发现用户需求出在哪里，根据收集到需求，加强对现有产品的理解，丰富产品使用场景，为后面产品做出新规划；同时也方便我们自己了解产品规划进度，及时跟进未完成的需求。

1）那么我们整理时候需要什么呢？

需求整理需要两样关键文档：需求池和需求文档；

①需求池

归档未到研发阶段的需求；每天抽出十分钟进行整理；通过需求池我们统计出，容易出需求的功能模块，以及用户的思考方向，能为我们下次产品规划提供很好的支持；

②需求文档

管理线上运行产品需求以及正处于开发阶段的需求；每周抽出一个下午进行整理；通过需求文档，我们方便掌握需求进展，以及产品规划实现程度。

需求整理看似简单其实是最需要我们自己不断练习的技能，是帮助我们理清产品逻辑的好工具。有了好工具，也需要我们利用好需求文档向运营人员及时反馈。因为运营在提出需求之后会需要我们的及时反馈，对于他们来说客户的提出的需求会有一个时效性，我们给出的反馈越快越精准，那么他们给到客户的反馈就越快越好，用户就不容易失去耐心。

 2）那么如何反馈呢？

我把两种方式结合起来使用：文档记录和一对一解释。

①文档记录

把拿到的需求和对应的处理情况通过文档的形式记录下来，给到运营人员。方便运营人员有需要的时候及时查看，也能在运营人员急需的时候给出回复。

在自己的需求池中增加“是否反馈”的属性，帮助自己完善这个步骤。越到后面你会发现很多运营人员愿意相信你，找你解决问题；在以后的工作配合会越来越默契。

②一对一解释

遇到伪需求的时候，我们需要将完整解释跟运营人员说明白，让他理解，给他提供较为合理的说辞，照顾用户听到时候的感受。

反馈无论在什么时候都是容易被忽略的，特别是忙起来的时候，给出反馈不仅能提升自己工作效率和团队协作，也是对自我整理一种监察机制。

04 总结

我通过对日常需求沟通总结出的一些经验，当然其中还有更多值得深入探讨的空间，希望通过我的总结能帮助大家更好的总结自己的日常工作。

尽管被沟通工作占据了大部分的工作时间，但是通过思考、沟通和整理，产品技能不断提升，通过量变达到质变，那无论多么枯燥重复的工作你都能从里面汲取到跟产品有关的知识。

也希望大家能与我分享更多的经验。

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

题图来自Unsplash，基于CC0协议