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

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

背景

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

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

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

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

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

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协议。