产品经理不做客服，怎么能说了解用户？

上个月，笔者负责的新产品上线，为了深入用户中，及时了解用户需求，解决用户问题，笔者做了一个月的产品客服。在与大量用户面对面的沟通中，感触良多，尤其对如何理解、识别、满足“用户需求”，有了全新认识。本篇文章就跟大家分享一些我的收获。

背景

笔者负责的是一个B端产品，产品上线后的推广由另外一些同事负责，笔者则专注于客服工作，每天在十几个微信群来回切换，解答、处理用户提出的问题。所以本文侧重B端产品的介绍，希望对做C端的产品经理也能有一定启发。

第一部分：B端产品经理，如何深入用户中？

做产品时，为了避免臆想用户需求，产品经理一方面需要做自己产品的重度用户，另一方面需要把自己的触角伸到其他用户当中，去倾听他们真实的声音。对于B端产品经理，我们经常处于比较尴尬的境地——自己并不是产品的目标用户，更别谈重度用户了。所以只剩一条路——深入到用户中，了解用户真实的使用场景和想法。

对于B端产品，当产品上线后，最高效深入用户的方式就是做客服和远程指导。

客服沟通

**
做客服可以直接与大量用户面对面沟通，直面用户问题，既能了解用户问题、需求背景，不囿于表象，又有足够大的样本量，快速发现共性问题，避免样本量少导致的主观因素影响。

远程指导

**
远程指导是在无法理解用户使用场景、不能快速定位问题时使用，借此方式可以清楚的看到用户要完成某个任务时的操作路径、习惯。很多小白用户，因为对产品不理解，会作出很多你想象不到的操作，远程能让你看到用户是如何认识产品的。

第二部分：用户问题分类，区分对待

产品上线初期，用户使用产品过程会出现大量问题，大致可以分为产品bug、操作问题、业务问题、需求四大类，不同类型的问题，应对方式会有差异。产品经理面对这些问题时，不应该一视同仁，而是要能够从不同类型的问题里提取为后续产品迭代提供方向的信息。

1. 产品bug

这类问题不必多说，直接影响产品在用户心中的形象，需要快速定位、快速解决。对于新的产品，用户大多还是有一定宽容度的，但不能无止境的透支。所以为了不让产品在用户心中“信用账户”余额过快消耗，团队要快速响应，快速解决。当时公司领导甚至要求上线初期“bug不过夜”，所以那段时间我们每天都要发新版本，以修复这些漏洞。

2. 操作问题

这类问题是指用户对产品某些名词、操作不理解，或者操作出错导致无法完成任务的问题，例如我要看XX应该在哪看？我要XX应该怎么操作之类的。

用户出现操作问题的根本原因有两个：

（1）视角差异
**

左侧是产品经理以自己的理解做的设计，用户则以右侧的视角看产品，我们以为用户很容易就能理解，实际他看到的可能是另一幅模样。

（2）遗漏部分场景
**
我们在产品上线后的第二个迭代，增加了“自动保存”功能，用户编辑一条信息详情时，如果没点“保存”按钮，直接退出或切到其他页面，系统会自动把当前最新的内容进行保存。上线这个功能的目的就是为了方便那些忘记点“保存”的用户，以免填写的心血付之东流。

一般来说，这个功能可以提升用户体验，解决用户困扰，但当我们上线这个功能后，却给用户造成了另一个更大的问题——信息覆盖。

出现这个问题的场景是：我们产品对于同一条信息，多人都有编辑权限。当多人同时打开同一条信息时，其中用户A进行编辑，保存退出了，另一个用户B页面还在那里，也没有刷新。所以用户B页面信息还是旧信息，当用户B退出信息编辑页面后，因为系统的“自动保存”功能，就导致旧信息覆盖了用户A编辑的新信息。

当时我们一直以为用户没保存成功，保存功能有bug，测试又无法复现，无法修复。导致用户对产品信心有很大动摇，都不敢继续使用了，直到一家公司在这个场景下使用时我们才发现，于是当天就把“自动保存”功能去掉了。

所以，如果产品设计之初有些场景没考虑到，也会造成用户的一些操作问题，但如果想一开始就把所有场景都设想到，那也不现实。能够思考到多少用户使用场景，一方面需要产品经理功力和经验，另一方面还是需要产品经理深入用户，及时发现那些被遗漏的场景，快速调整产品策略。

3. 业务问题

**
这类问题是用户因为对业务不了解导致的对产品中名词、规则的不理解。对于很多专业性较强的B端产品，都会遇到这种问题，如果是小白用户，这类问题更突出，而产品经理能做的，就是多些提示、多些名词解释，让用户尽量明白些。但要想解释清楚所有内容，那是不可能的，B端产品业务的专业性决定了较高的使用门槛，所以这类问题产品经理可以适当减少投入精力。

4. 需求

**
因为用户能够与产品经理直接接触，可以方便的提出自己的需求和想法，所以笔者做客服期间收到用户提的各种需求、面对这些需求，自然不能照单全收，纳入需求池后，如何识别真伪需求？如何识别共性还是个性需求？如何判断需求优先级等等一系列问题，将在第三部分分享我的一些想法。

在这里要说的是，这些需求无论如何处理，都要给提出人一个回复，以增强用户的参与感，让用户感觉自己也参与了产品的设计，以鼓励用户提出更多好的建议。

第三部分：思考与收获

这部分是笔者做了一个月客服后的思考与收获，主要是从产品视角，对一开始做得不足的地方的反思。

1. 需求层面

（1）“完美主义”陷阱
**
业务方、产品经理在产品设计阶段，很容易陷入“完美主义”陷阱。总想着把需求做细，权限控制精准，因此制定的业务规则过于复杂、过于细致。导致产品开发周期变长，产品上线后，用户使用既不方便，又难以理解。

举个例子：我们在设计角色权限时，把权限控制得比较细，每个角色能做的操作都做了明确的限制，也投入了比较多的精力开发这个功能。但上线后发现用户抱怨很多，感觉这也不能做，那也不能做，每走一步都很小心翼翼，生怕一旦写了什么东西，下次就改不了了。后来我们不得不把部分权限放开，或增加新的有更大权限的角色去完成某些特定操作。

所以，我们考虑产品规则时可以细致，但定义这些规则时，应把握的原则是给用户更大的空间、更多的权限、更自由的操作，尤其是产品初期，没有对用户和业务场景足够的了解，很容易把“理想的规则”变成“体验的制约”。

（2）需求的“二律背反”性
**
需求的“二律背反”性是指同一个功能，对不同的用户会产生截然相反的影响。

对于B端产品，不同角色的需求冲突更频繁、更明显。

我们做需求调研时，业务方需求里有两个很类似的概念，需要填写，只是填写时间不一样，代表含义没差别。产品上线后，很多填写者对这两个概念不理解，也不明白为什么要有两个概念类似的值，给填写造成困扰，增加工作量。所以作为填写者，他们希望能去掉其中一个。

但提这个需求的是管理者，管理者希望管理更精确，于是导致需求上的冲突，最后还是牺牲了填写者的需求，保留了这两个类似的概念。

每个产品，每增加一个功能都要考虑清楚，这个功能给10%的用户带来好感的时候是否会给90%的用户带来困惑。有冲突的时候要聪明，分情况避免，当无法避免或找不到折中方案时，就需要识别这个需求相关角色的重要性，做出取舍，并想办法补偿被牺牲角色，减少抵触心理。

每个功能不一定要用得多才是好，而是用了的人觉得好才是真正的好。

（3）“沉默的大多数”
**
在微信群里做客服，很容易被活跃用户蒙蔽，让产品经理误以为他们提的需求是优先的、紧急的。“叫得响”的用户会掩盖沉默用户需求。

尤其是B端产品，这个现象更明显，影响也更大。因为我们与各个公司对接人沟通会更多、更频繁，对接人在反馈需求时，会出现“领导需求优先、对接人需求优先”的情况，而其他角色的需求会有意无意的弱化甚至忽略。

所以在收集这些需求时，需要把需求提出人的角色也记录上，回头整理需求池时，就能一目了然的发现哪些角色需求被弱化了，然后针对性的调研被弱化的角色需求，主动沟通，了解这部分用户的使用痛点。

（4）无处不在的“墨菲定律”
**
“墨菲定律”是指只要系统有这个可能，那一定有人会这么操作。

这个道理其实很简单，也很早就明白，但直到深入用户中后，才深刻体会到，如果一个操作没有定义好或含糊过去，就一定会有用户挖出来，成为你产品的槽点，并且造成这样或那样的问题。

所以产品经理们，定义需求时，一定要定义清楚哪些能做，哪些不能做，不要含糊处理，否则一定会成为后面的坑。

2. 体验层面

（1）并不是路径最短的就是最好的，而是最容易理解、最符合习惯的才是最好的
**
设计任务操作流程时，我们会尽量把每个任务的流程设计得最短，本着“能少一步就少一步”的原则，让用户少做操作，提升体验，在多数情况下，这个原则是对的，但当“路径短”与“习惯”冲突时，我们要优先符合用户“习惯”。

我们产品中有一个配置用户角色的功能，其中有个角色的配置方式和其他四个角色配置方式不一样，第一个版本中，笔者把这五个角色都放在一个地方设置，不过这样会导致那个特殊角色配置流程变长。为了让路径最短，第二个版本笔者就把这个角色与其他角色配置地方分开了。

这样调整后，发现用户并不买账，他们其实没怎么感知到路径的缩短，而对这种不好理解的设置非常介意，导致我们要花很多时间一遍一遍的解释。

所以，对于体验，要重新认识。

• 体验是用户主观的综合感受，这个综合感受很复杂，影响因素很多，不同的变化对综合感受的影响程度也不同，但结果只有好或不好。原则冲突时，要认清影响更大的因素，优先满足；
• 用户只有好理解了，才能好操作；
• 每个人都喜欢在自己的舒适区中，这个舒适区就是用户习惯，在舒适区内的路径最短才是好的体验；
• 能感知到的优化体验，才是好的体验，否则用户不会买账；
• 习惯 > 易理解 > 路径短。

（2）用户是懒的，但是可以规范的
**
用户永远是懒的，永远都会找最习惯、最近、最便捷的方式，但并不意味着放任自流。

在微信群里做客服，能够与用户实时沟通，实时反馈，但也会造成问题多的时候出现遗漏的情况，所以我们都会建议用户重要问题发送邮件，避免因遗漏造成更大的问题。

这个原则做产品同样适用。如果让用户改变习惯所获得回报是值得的，那我们就需要这么做，在用户可接受范围培养甚至调整用户习惯，以换回更大收益。

（3）“用户思维”知易行难
**
体验的好坏与产品经理的用户思维强弱息息相关，但用户思维是一个知易行难的事，因为你绝不可能代表所有用户，每个用户阅历、角色、使用产品目的、场景都不一样，产品经理无法成为那个人，只能尽量“还原”那个人。

“如果我是用户”这句话，应该换成“根据我对用户的了解”，这个过程才是用户思维提升的过程。

好了，我要去做客服了，有人艾特我了。

作者：周翔，起点学院深圳1609期产品经理实战训练营学员
本文由 @周翔 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于CC0协议。

转载自 人人都是产品经理 作者@周翔 原文地址