了解用户习惯和用户目标对于一个B端产品的成功来说十分重要

做好用户沟通，了解用户习惯和用户目标对于一个B端产品的成功来说十分重要。所以今天我想聊一聊关于用户沟通我个人的一些思路。在产品迭代中，按照产品的输出过程，我把用户沟通可以分为以下几个阶段，需求沟通，方案确认，上线培训，产品灰测。

01 用户沟通

从需求方提出需求开始到产品方案的输出期间产品经理和需求方发生的沟通我将其统称为需求沟通阶段。主要是产品经理和用户基于当前产品使用过程中发现的问题或者基于本人/本业务的目标期望而对产品提出的需求和想法进行沟通。在这个阶段最重要的一点是要明确用户到底需要什么（用户需求），他为什么需求（用户价值）。

1. 用户需求挖掘

通常用户需要一些引导才能得出真实的需求。你可能会问，作为用户，应该是最清楚自己要什么的，为什么要引导，引导什么？举个实际案例，某天用户A提出用户岗位中包含关键字“运输”的用户在填写用户资料时要求强校验用户的“运输工具”是否已经填写，如果未填写则提示保存失败。那么作为产品经理的你要怎么做，是否直接按照用户提出的要求通过岗位名称的判断在填写页面增加用户要求的校验吗？

————（此处请思考三分钟）————

需求方说他想要的真的就是他想要的吗？NO。

在沟通过程中建议用5W1H来定位用户场景，使用5Why挖掘用户真正的需求，同时需要完整了解现状（这个以后有机会我再展开聊）。

在刚刚的例子中，可以试试通过以下简单的问答来真正明确需求。

• 问：为什么这些用户必须要录入“运输工具”？
• 答：因为系统需要根据录入的“运输工具”进行派单计费，如果他们没有录入就会影响工资结算。
• 问：具体是哪些用户会需要根据运输工具派单计费呢？
• 答：比如调度司机啊、派单人员啊这些。
• 问：那为什么你提的需求是有岗位名称中有“运输”的人员要求必填呢，两者有什么必然联系？
• 答：因为现在我给这些人取的岗位名称都有“运输”两个字呀。
• 问：那岗位命名会一直由你来负责吗，后续如果其他人来处理，他们知道这个规则吗？
• 答：emmm…也许吧

所以其实用户的需求是，对于要使用“运输工具”的用户进行录入项目的管控，和岗位关键字无关。用户犯了把最终实现结果作为需求的典型错误。

2. 需求价值挖掘

需求价值明确要求需求方在提出需求时明确这个需求为业务带来的价值，并且最好是可量化的价值。

这个阶段需要明确得向业务方问出这个需求的实现能够帮你解决什么问题，带来多大的收益。

要知道，和需求量相比开发资源永远都是不够的，总是有成堆的需求等待开发。所以，明确业务价值可以有助于产品经理更好的判断优先级，完成更好的产品迭代。而需求方自身在思考价值的同时，也可以对该需求进行更加深入和完整的思考，可能会有意想不到的发现哦。

对于比较大的项目需求，甚至需要明确到每个功能点的价值，便于产品经理进行需求的拆分。

02 方案沟通

基于用户需求，产品经理需要根据需求点评估和经验通过产品方案设计来达成用户的需求。在方案确认后正式进入开发前，需要和需求方进行最终的方案确认，通过文档演示的方式向需求方展示需求的实现方式及效果，以确保可以真正解决业务问题。

这里需要注意的是，完整的产品方案除了明确功能实现方式（满足需求）外还应该包括预计交付时间、交付范围、项目推进进度（灰测计划）。

1. 功能需求

功能需求即指能够满足业务需求的整体方案设计，其中包括了功能点、页面、交互等用户可以直观看到、感受到的内容，也就是我们通常所定义的需求文档。

这点其实是属于基本内容，我就不再过多赘述了。

2. 交付时间及范围

站在用户的角度来说，他除了关心自己的需求能否得到解决外，他还关心什么时候可以得到解决，也就是我们提到的交付时间。所以我们在进行方案沟通时，也需要基于实现的难度给业务方一个初步的预估上线时间。

对于实现周期较长的需求，通常需要拆分需求迭代，此时则需要明确每个迭代涉及到的功能点和交付时间。这里通常需要结合功能点价值、业务痛点以及迭代的完整性来指定。前面两个点比较好理解，迭代的完整性是指此迭代上线后应该是一个完整的、可以使用的功能，而不是需要等下个迭代上线后才可以一起使用，那么分期实现就没有意义了。

产品经理在接收到需求后即使是对于实现难度大而暂时无法实现或优先级不高需要暂时搁置的需求，也应该明确的给予业务方答复，做到事事有回应、件件有找落，让需求方可以及时启动备选方案，避免产品的实现过程成为业务瓶颈。