编辑导语：产品经理与用户之间沟通的成功与否，既关系着自身工作是否达标，也关系着是否能将虚化的需求转换为真实的产品。那么，产品经理该如何跟用户更有效的沟通呢？本文作者结合自己的经验分享了一些关于沟通的小技巧，供大家一同参考学习。

说话是一种本能，沟通更多的是一种能力，这种能力的高低会决定沟通的结果是有效还是无效。在产品经理与用户沟通的过程中，定义沟通有效的关键是产品经理是否能从用户身上得到真实的需求反馈。

“以用户为中心“是绝大部分老板和产品经理的口头禅，借以掩盖自身经常拍脑袋决策的事实，真正能把“以用户为中心”这句口头禅做到知行合一的少之又少。

产品经理作为企业与用户对话的关键桥梁，需要承担产品管理的职责。产品管理是以用户为中心，满足用户需求及维持企业长久的竞争优势。

这意味着产品经理需要同时对企业和用户负责，要在企业需求与用户需求间找到平衡点，让两者都能“有利可图”，而这也恰好是产品经理日常工作的难点之一。

产品管理包括需求管理，用户研究是需求收集最直接也最重要的来源，用户研究的形式有很多。比如在如今的大数据时代，很多企业放弃了与用户直接沟通，沉浸于研究各种第三方的调研分析报告。用户变成了众多数字的一部分，成为百分比中的分母或分子，影响着产品经理的决策。

当然这里并不是要否认调研报告对于趋势判断的重要性，但对于产品而言，抽象的趋势分析没有办法去帮助产品经理定义产品具体的细节，与用户的直接沟通，是产品经理必须要做的事情。具体操作层面，我个人比较推荐腾讯的“10/100/1000法则”：

10/100/1000法则：产品经理每个月必须做10位用户调查，关注100位用户博客，收集反馈1000位用户体验。

结合实际工作，我对该法则进行了稍微的改动：产品经理每个月必须和10位用户沟通、售后接待100位用户，收集分析1000条店铺用户反馈。该法则看起来简单粗暴，但却能直接了解用户对产品的关注点以及去分析背后的原因（需求）。

我参与过很多用户沟通、电话回访、入户访谈的项目，踩过不少坑，在做总结复盘的同时，我也常在思考究竟如何与用户沟通才是有效的。多年工作实践，我总结了一些关键点如下：

一、做好沟通前的准备

1. 找对沟通用户

判断是否找对了沟通用户，有两个标准：

第一：目标用户

第二：适合沟通

目标用户很容易理解，就是该产品项目选择的细分市场用户。而“适合沟通”的判断标准主要是和用户性格、口才相关，因为这类用户会主动去说出他想要的，对自身需求的表达也会比较清晰。那怎么去找到这种性格外向、口才又好的目标用户呢？可以在前期删选阶段与用户做一次简单的电话沟通，只要聊几分钟就基本可以判断出来。

2. 明确沟通目的

产品经理与用户沟通并不是漫无目的，想聊到哪里就聊到哪里，话题刹不住车是沟通过程中比较忌讳的。沟通内容要具体、有重点，需要按照一定的逻辑来进行，一份完整的沟通提纲建议包括如下内容：

（1）相互认识，向用户简单介绍本次沟通的目的（5分钟）

自报家门，主动出示工作名片或证件；

与用户签订双向保密协议，尽可能打消用户的疑虑，并且说明沟通现场记录（包括有录音和录像）都只用于企业内部后期信息整理，并不会对外泄露。

（2）了解我们的沟通用户（10分钟）

一般我们去和用户沟通，肯定是对用户的信息有基本的了解。但是在沟通正式开始前，还是需要用户花几分钟来介绍自己相关的情况，这样做的好处是既可以通过这段介绍拉近自己与用户之间的距离，也可以验证之前了解到的用户信息是否真实。

（3）了解用户在使用产品过程中的痛点及需求（45～60分钟）

正式进入沟通的主题，针对产品的维度提出一些问题让用户回答，采取开放式提问及情景式提问的方法，下文会详细讲到。

（4）未来购买可能性以及对产品的期望（10分钟）

如果未来还要购买同一款产品，用户是会选择现在的这款还是会有新的选择？用户对新选择产品有什么期待？

（5）新产品概念的验证（15分钟）

给用户展示新产品的一些概念（可以是图片、视频、模型等），验证概念的维度及购买的可能性

二、与用户沟通的基本技巧

沟通是一门高深的艺术，熟练的掌握沟通技巧有时能取得事半功倍的效果。

在产品经理与用户沟通的过程中，大多数情况可以认为是两个“路人”在谈论，如何消除“路人”彼此之间天然存在的陌生感和距离感，是产品经理在整个沟通过程中需要重点关注和把控的。

1. “想其所想，感其所感，帮其所需”

绝大部分用户对产品的理解肯定是片面的，他们作为产品的使用者对产品的认知只限于自身的使用场景和需求，并不需要去了解产品之外的信息。而产品经理或者企业高层还需要从行业趋势、竞争对手、市场、技术等维度去理解产品，所以，即便用户对产品的想法是狭隘的、片面的，产品经理也需要去充分的理解和包容。

我曾经和一位技术大咖去参加用户访谈，用户提到的功能，技术大咖要么就直接告诉他这个实现不了，要么就说技术成本高，要么就说竞品已经做了但是效果不好……用户的建议一直被否定，后来导致用户都不敢再表达自己的观点。

把自己当作眼前的用户，想其所想，感其所感，帮其所需，其实就是自身”小白转换“的过程。即便用户提到的产品功能或者需求暂时实现不了，我们也可以去引导用户说出需要这个功能背后的原因，他真正需要解决的痛点在哪里以及他理想中的解决方案是什么。产品经理需要思考的是在技术上有无替代的方案，即便不能完全实现，能实现80%，对用户来说也是一种可以接受的。

2. 多听多记少说

在与用户沟通的过程中，主角永远是用户。产品经理要尽可能的让用户说的更多，特别是用户对于产品使用场景的描述以及在遇到问题时会下意识做出什么反应。

在用户描述场景的过程中，“人、时间、地点”三个要素需要兼顾到，如果用户遗漏了，可以提醒用户补充。而用户在遇到问题时的下意识反应和解决方案，则需要更细致的记录。很多时候产品的“创新”灵感就是在这个时候产生的，来自于用户”创造“的解决方案有时往往也是最贴近用户的。

3. 科学的提问

开放式提问是最基本的用户沟通技巧，这里就不多说。科学的提问还包括“情景式的提问”方法：

• 情景式提问：通过提问了解及确认用户痛点存在的场景
• 过去式提问：了解用户过去是如何解决这个痛点的?是否有什么困扰？
• 现在式提问：了解用户现在如何解决这个痛点的？
• 将来式提问：了解用户在理想情况下，解决这个痛点的方法是什么？

情景式提问的好处在于用户痛点和解决方案是相对闭环的，并且按照时间线全部由用户来提供他已经做到的或者想要做到的解决方案。

举个真实案例：

某产品经理想了解用户在往洗衣机里面添加洗衣粉时可能会遇到什么问题，借以改进衣物清洁类产品的体验流程。

情景式提问：您平时会在什么时候往洗衣机里面添加洗衣粉？您在这个时候会遇到什么问题吗？

（用户回答：“一般我会在把衣服全部放进洗衣机后，再往里面加洗衣粉，这个时候我主要是不好控制洗衣粉的量，你看这个袋子开了一个口子，就这样往里面洒，有时候多了有时候少了，多了我就把洗衣粉从里面拿一些出来……”）

过去式提问：那您以前是怎么解决这个问题的呢？有什么困扰呢？

（用户回答：“凭手感，看衣服的多少按经验去放，但是有时候我老公会放多，洗完后衣服上就全是洗衣粉的味道”）

现在式提问：那您现在是怎么解决这个问题的呢？

（用户回答：“我现在在洗衣粉的袋子里面装了个小勺，需要的时候就用勺子，我自己估算的3件衣服放半勺，5件衣服就放一整勺，也不知道是不是科学……”）

将来式提问：在理想状态下，您希望如何解决这个问题？

（用户回答：“如果有那种定量的洗衣粉就好，它是一小包一小包的，规定好3件衣服就放一小包，6件衣服就放2包，放进去就好了”）

后来该品牌推出了可根据衣服数量定量投放的洗衣凝珠产品，在用户体验流程非常创新，成为了市场爆款。

三、与用户沟通过程的要点

1. 适当闲聊

适当闲聊的前提是找到共同的话题，可以从用户感兴趣的话题入手，比如用户的穿着、饰品、服饰、家装、宠物等方面。

2. 用心倾听

产品经理要充分给予用户发表自己观点和想法的权利，找出用户话语中的逻辑以及合理性，并在过程中收集自己需要的信息。并且要不断的向用户传递认可的信息，比如点头等，让用户能够得到最积极的反馈和尊重。

3. 观察与记录

除了提问，产品经理也要具备一定的察颜观色能力，关注用户的微表情及语气，并且在用户说到某件事、提到某个场景的时候，表情和语气的变化，都需要记录下来。

4. 还原用户场景

在沟通过程中，可以请用户按照他平时的习惯全流程的使用一次产品，并且在过程中请用户随时说出他感受不好的地方。

有的产品问题只有在平时使用中才会注意到，比如洗衣机的电源线，产品经理在定义产品的时候，会默认电源线是长期插在插座上的，所以在机身上没有设计挂电源线的位置，但是很多用户因为洗手间的插座数量少，洗衣机每次用完后都要拔下电源线，这种情况下，电源线就没有地方挂了。

5. 结束沟通

与用户沟通完成后，需要对用户表示感谢。在取得用户同意的前提下，产品经理可以添加用户的微信，后期如果针对用户的痛点需求有了对应的概念，可以第一时间发给用户进行验证。

6. 沟通记录第一时间整理

结束一次用户沟通，产品经理需要尽快梳理沟通过程中的记录并同步给项目团队，主要整理内容如下：

1. 该用户的画像
2. 各场景下用户的痛点/需求是什么
3. 产品概念验证的结果

四、重申与用户有效沟通的几个要点

1. 找对沟通用户
2. 明确沟通目的
3. “想其所想，感其所感，帮其所需”
4. 多听多记少说
5. 科学的提问
6. 观察与记录
7. 还原用户场景

作者：右边的问号，八年硬件产品经理，公众号：右边的问号

本文由 @右边的问号 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议