产品在收到用户反馈时，并不是一手信息，为了更加贴近用户场景，产品团队需要亲自去到客户现场调研，以便获得一手需求信息。那么，如何在需求调研时“拿下客户”？作者总结了相关步骤，希望对你有所帮助。
产品团队收到来自业务的反馈，大客户现在产品使用的挺好的，要是能进一步帮助客户提升业务运作效率就更好啦！
收到客户好的反馈，产品团队甚感欣慰。客户有更多的期望，代表产品及企业在持续向上⬆️生长，朝着越来越好的方向发展。
为了更好地服务好大客户，产品团队决定亲自去到客户现场调研，以便获得一手需求信息。
去客户现场前，产品团队做足了准备工作。为了获得客户的有效反馈，需要提前准备好产品demo演示方案，以便在客户现场可以获得更多有用的需求信息。确保最终的产品方案可以解决客户真实场景问题。
我们来看看，具体要做哪些准备呢？
（1）明确需求背景
当收到业务人员的需求反馈时，先与业务人员沟通确认需求背景。
主要了解如下四点内容：
1）客户现在的业务运作是什么样的？
2）客户是怎么使用产品的？（业务运作中用到哪些产品能力？）
3）客户的业务运作中存在什么问题？
4）客户想要通过产品，帮助其业务运作达成什么样的效果？
（2）业务分析
明确需求背景后，分析业务需求，找到需求场景的根本问题。梳理需求用户故事，明确用户角色，以及用户完成目标需要进行的活动。
身为产品人，摸透业务是工作中的重中之重。
（3）产品分析
完成业务分析后，进入产品分析阶段。该阶段主要明确能为用户解决什么样的问题。这里涉及到竞品分析、用户调研，从用户故事中提炼产品能力。
step1：将业务需求转化为产品需求
产品分析包括对目标用户、人群画像、需求定义等一系列分析。站在用户的角度，将用户的痛难点问题具象化地表达出来。再结合产品，分析产品还需要满足哪些能力，才能解决客户的问题，从而确定产品迭代范围。
step2：业务流程图
梳理流程图的目的是理清楚客户的业务是如何运转的。明确不同的用户角色在完成目标时，需要在各产品模块/功能间进行的操作及流程，从而明确产品模块/功能间的相互依赖和业务流转。
step3：产品架构图
梳理产品架构图的目的，是在明确需要解决什么问题的前提下，确定产品迭代方向，以及确定涉及哪些产品功能模块以及页面的改动。明确哪些信息需要展示给用户，以及用户在操作过程中存在哪些限制规则。
如需监控上线后用户的使用情况，需要做效果监控与数据分析，需考虑做埋点，定义数据指标。
（4）原型设计
完成业务和产品分析后，便进入原型设计环节。原型设计包括低保真线框图和高保真设计图。
绘制原型图的方法有很多，可以选择专业绘图工具（Axure、Balsamiq🙂、MasterGo、墨刀、Figma、摹客、sketch…等），或者可以用纸和笔画。
需注意⚠️：
1）不论选择哪种工具进行原型设计，其目的只有一个，就是将产品方案可视化，便于 UE、UI设计人员能清晰地理解你的产品方案，让设计人员帮你输出高保真设计图。
2）选择适合自己的工具更重要，有些企业为了便于产品与设计人员之间更好地协作，会要求产品与设计人员使用统一的在线协作工具，这时就可以根据公司要求选择。
（1）目的
为确保产品团队在客户现场的方案演示能顺利开展，让客户能很好地理解产品整体解决方案，让客户明白产品方案可以如何帮助 ta解决实际业务运作的问题。
在准备好产品demo方案后，提前准备好给客户现场演示方案的脚本。
（2）产品方案预演示
产品方案预演示主要由主导客户需求的产品经理讲解。预演示包括在产品团队内部演示，以及向业务人员演示。
1）产品侧预演示
先在产品内部进行demo方案演示，把产品团队成员当成客户去讲解产品方案。获得产品团队成员的有效反馈。
产品团队成员以客户的角色代入，反馈在整个演示过程中不理解的地方，以及提出建议要怎么讲解会让客户更好地理解。
2）业务侧预演示
通过向业务人员演示产品方案，获得业务人员的反馈。业务是贴近客户的人员，一定程度上可以代表客户的心声。
如果业务人员反馈听不懂，就需要考虑改进演示过程。如果业务人员能有代入感地听你讲解产品方案，那演示效果还不错哦。
（3）避免使用产品语言
在日常工作中，产品经理每天和开发、测试同学聊得最多的就是产品逻辑、产品规则。因为日常工作的惯性思维，导致产品经理在讲解方案时，会不自觉地先入为主讲解产品逻辑规则。
用这样的产品语言和客户讲解，客户大概率是听不懂的。因为客户无法代入场景评估产品方案，无法判定产品方案能不能帮ta解决使用场景问题。
在向客户讲解方案时，需要使用业务语言，而不是产品语言。从需求场景出发，确保客户有代入感地听你讲，让ta 能明白产品方案是如何解决ta 的场景问题的。
主导需求的产品经理作为主讲人，代表着企业及产品团队。在开始讲解方案前，先进行简单的自我介绍，体现你在企业的岗位+姓名，让客户对你有大概的了解，便于后续的协作对接。
在这之前，你已经进行过多次内部预演示了，做好了充分的准备工作。现在可以按照最终定好的演示流程讲解。
讲解过程需要注意：
1）控制时长
讲解时长要根据方案的复杂度以及内容量定义。确保核心内容讲解到位的前提下，控制讲解时长。预留更多的时间在客户答疑及讨论环节。
ps：当时演示时长大概在 10-15 分钟。
2）把握节奏
为确保演示过程的顺畅，在讲解过程中，需要控制客户提问的频率。如客户想要在过程中聊细节内容，可以告诉客户先把问题记录下来，演示完整体的方案后再统一解答、详细沟通。
演示完产品方案后，询问客户是否有不理解的地方，现在就是讨论环节。
在讨论过程中，能明确客户对方案的认可度。客户一般会问“我们这个场景要怎么处理？”，当客户谈及场景时，就是收集需求信息的好时机。
在客户讲解场景问题时，千万不要打断客户，先倾听👂客户的VOC。收集到足够多的信息，帮你做决策，再将其转化为产品需求。
在过程中需要做好信息的记录，我一般会用在线文档记录关键信息，同时全程录音。因为在 1-2 小时内，沟通的信息密度是很高的，没法记录全部内容。录音记录便于后续回溯客户反馈的信息，回去后有不清楚的点，就可以再听一遍录音。
全部方案演示完成后，确认客户对产品使用的急切度，从而确定上线预期时间。
如果客户反馈的VOC是：迫不及待要使用产品新能力了，期望能尽快迭代上线产品能力。
客户表达这个声音时，说明客户很认可产品方案。产品方案演示是成功的，能明确提供给客户的产品方案是能解决客户的业务问题的。
经过现场拜访客户，向客户宣讲产品解决方案的经历，总结了以下 3 点，有助于后续能灵活、游刃有余地应对客户问题。
交付物（产品演示方案）不仅代表着产品经理对外的形象和专业度，更代表着企业，你做好了，客户会更加信任企业，愿意继续和企业友好合作。
高质量的交付物，是客户成功的关键！
在向客户讲解方案时，需要使用业务语言，而不是产品语言。要注意从需求场景出发，确保客户有代入感地听你讲，让ta 能明白产品方案是如何解决ta 的场景问题的。
“说人话”，用业务语言表达，说能让客户听得懂的语言！
多听客户说，多听客户自主地表达。产品经理可以在过程中多记录信息，感受客户内心真实的想法，能更快地找到客户使用场景中的根本问题。
“对症下药”的产品方案才是真正能帮助客户解决问题的“有效良药”。
本文由 @Nana 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。