对用户沟通的4个阶段展开分析总结

对于B端产品的成功来说，做好用户沟通，了解用户习惯和目标是非常重要的。所以今天我想谈谈用户沟通我个人的想法。在产品迭代中，根据产品的输出过程，我可以将用户沟通分为需求沟通、方案确认、在线培训、产品灰测试等阶段。我将01用户沟通统称为产品经理与需求方之间的沟通阶段，从需求方提出的需求开始到产品方案的输出。主要是产品经理和用户根据当前产品使用过程中发现的问题或我/业务的目标和期望，沟通产品提出的需求和想法。现阶段最重要的一点是明确用户需要什么(用户需求)，为什么需求(用户价值)。1.用户需求挖掘通常需要一些指导才能获得真正的需求。你可能会问，作为一个用户，你应该最清楚自己想要什么，为什么要引导和引导什么？例如，在实际情况下，有一天，用户A提出用户职位中包含关键字“运输”的用户在填写用户信息时，需要强烈检查用户的“运输工具”是否已填写。如果未填写，则提示保存失败。那么，作为一名产品经理，你应该做些什么呢？您是否直接根据用户提出的要求，通过职位名称的判断，在填写页面上增加用户要求的验证？————(请在这里思考三分钟)-需求方说他真的想要他想要的吗？NO。在沟通过程中，建议用5W1H定位用户场景，用5Why挖掘用户的真实需求，充分了解现状(以后有机会再谈)。在刚才的例子中，您可以尝试通过以下简单的问答来真正明确需求。问：为什么这些用户必须输入“运输工具”？答:因为系统需要根据输入的“运输工具”收费，如果不输入，会影响工资结算。问:哪些用户需要根据运输工具收费？答:比如调度司机，派单人员。问:那你为什么要求岗位名称中有“运输”的人员必须填写？两者之间必然有什么联系？答:因为现在我给这些人取的岗位名称都有“运输”二字。问:你会一直对那个职位的命名负责吗？如果别人以后处理，他们知道这个规则吗？答：emmm..也许，所以其实用户的需求是控制要使用“运输工具”的用户输入项目，与岗位关键词无关。用户犯了以最终结果为需求的典型错误。2.需求价值挖掘需求价值明确要求需求方在提出需求时明确需求给业务带来的价值，最好是可量化价值。在这个阶段，我们需要明确问业务方实现这种需求能帮助你解决什么问题，带来多少好处。要知道，与需求相比，开发资源总是不够的，总有成堆的需求等待开发。因此，明确业务价值可以帮助产品经理更好地判断优先级，完成更好的产品迭代。在思考价值的同时，需求方本身也可以对需求进行更深入、更完整的思考，可能会有意想不到的发现。对于较大的项目需求，甚至需要明确每个功能点的价值，方便产品经理拆分需求。根据用户的需求，产品经理需要根据需求点进行评估和经验设计，以满足用户的需求。在方案确认后正式进入开发之前，需要与需求方进行最终方案确认，并通过文档演示向需求方展示需求的实现方式和效果，以确保业务问题能够真正解决。需要注意的是，除了明确的功能实现方法（满足需求）外，完整的产品方案还应包括预期的交付时间、交付范围和项目进度（灰色测试计划）。1.功能需求功能需求是指能够满足业务需求的整体方案设计，包括功能点、页面、交互等用户可以直观看到和感受到的内容，即我们通常定义的需求文档。这其实是基本内容，我就不赘述了。2.从用户的角度来看，他不仅关心自己的需求能否解决，还关心什么时候能解决，也就是我们提到的交付时间。因此，在沟通计划时，我们还需要根据实现的难度对业务方的在线时间进行初步估计。对于实现周期较长的需求，需求迭代通常需要拆分，此时需要明确每个迭代所涉及的功能点和交付时间。这里通常需要结合功能点的价值、业务痛点和迭代的完整性来指定。前两点很容易理解。迭代的完整性是指迭代上线后应该是一个完整且可用的功能，而不是等到下一个迭代上线后才能一起使用，因此分期付款的实现毫无意义。产品经理在收到需求后，即使难以实现，暂时不能实现或优先暂时搁置需求，也应明确答复业务方，做一切回应，一切找到，使需求方能够及时启动替代方案，避免产品实现过程成为业务瓶颈。3.产品经理在双方确认产品计划和上线时间后，需要确认项目上线后用户的灰度计划/运营计划。对于广泛的推广需求，为了避免全面上线带来的风险，通常会选择分区域或用户群逐步上线，称为灰度计划，简称灰度测试。灰测计划通常由业务方根据需求特点和业务覆盖面来定义。并在产品交付后开始按照灰测计划逐步推进，以确保实施的项目能够达到预期效果，收获项目价值。产品经理还有责任确保需求价值的实现来反映自己的价值，因此在这个阶段，双方也需要确定一定的后期操作计划。（悄悄地说，如果需求方不能明确运营和推广计划，他们可能不会像预期的那样“焦虑”。我们可能需要回顾产品的价值，看看我们是否需要为其他更有价值的需求安排资源。说实话，有时我们仍然会遇到需求方在需求阶段敦促在线，在线后没有开始使用，真的很头疼，所以早期明确是非常必要的）03人员培训产品正式在线，为了确保用户能够正确使用，达到使用效果。产品经理通常需要在线培训，并提供相关功能的操作说明。1.在在在线培训公司，根据沟通水平的划分，通常需求报告会通过各部门的收件人向产品经理报告。同样，需求计划的沟通通常由几位代表或负责人和产品经理确认。因此，在上线之前，还将涉及到对其他系统用户的整体培训，主要内容也将针对本次上线的功能点和变更点。(这里也偷偷说，在培训过程中要注意把握培训节奏，不要让培训成为需求收集会。相信大家都知道~~)2.操作手册SOP上线前，千万不要以为培训结束了就结束了。不要忘记更新操作手册。完整的操作手册可以帮助新用户快速掌握系统的使用，减少大量无效的沟通和询问时间。在上述方案的沟通中，我们提到产品经理和需求方有责任在早期明确运营和推广方案，以确保需求的实施。因此，在实际的灰色测试阶段，产品经理还需要花一定的经验来跟踪灰色测试的进度，以确保实施的项目能够达到预期的效果，收获项目的价值，并确保及时处理灰色测试过程中的异常。1.灰测试过程的异常跟踪和计划调整在一定程度上是为了在全面推广之前处理潜在的风险问题，避免问题的扩大。因此，在灰色测试阶段，产品经理需要更加*在线异常问题，及时反馈测试和技术异常处理，以免影响正常业务运行。此外，如果发生重大异常，需要重新评估异常点，提出解决方案，快速迭代在线，及时与需求方调整灰色测量计划，确保在线正常推广。此外，在这个阶段，产品经理还需要倾听更多的“用户的声音”，倾听那些“嘲笑的声音”，找到需求中的优化点，判断这些迭代是需求中的遗漏点，是否会影响业务运营，是否需要添加下一轮迭代。项目复盘结合用户反馈和在线数据，吸收pros和cons，扬长避短，减少后续迭代中的“坑”。良好的用户沟通机制可以帮助产品经理与用户建立稳定的沟通桥梁。从以上文章的长度也可以看出，沟通环节的核心实际上是需求沟通和需求挖掘。正确把握用户痛点，理解用户痛点，可以说是成功的一半。如果最初的方向错了，以后的沟通可能会走很多弯路，甚至直接走错路，造成开发资源的浪费。当然，后续的方案沟通、培训和*可以帮助产品经理在用户心中树立更好、更专业的形象。以上是本文的全部内容。我希望这篇文章能对你有所帮助。