产品经理不要做需求的传声筒，而是要做需求的翻译机。

不做需求的传声筒

一直以来C端的产品遵循以用户为核心，B端的产品也是以客户为核心，那什么才是以用户为核心呢，难道就是用户说什么，我们就要做什么吗？

福特汽车的故事告诉我们，用户需要的是一个更快的马，但是最后提供的是一辆汽车。如果我们根据用户说的去做，那就没有福特汽车的出现。

用户即便知道自己想要什么，也容易受到认知的约束，而给出局限的解决方案。在那个没有汽车都是马车的时代，用户的需求是更快的交通工具，而我们需要做的是通过用户的“需求”找到真正的解决方案。

所以以用户或者客户为中心是需要产品经理站在用户角度，去思考用户的痛点是什么，然后通过产品来解决的这个痛点。而不是当做需求的传声筒，把用户的需求传递给研发而已。把用户需求翻译为产品需求，这就是产品经理需要做的事情。

需求传声筒的危害

如果我们一味的听从用户的需求，没有弄清楚用户真正的意图，结果做出来的功能客户又不要，白白浪费了公司的成本和资源，尤其对于小公司这样的损失是非常严重的。

在早期流行手机发短信的时候，座机的使用比手机普遍，那是有用户提出，手机不是人人都有。但是家里一般都是有座机，为什么家里的座机不能提供一个发短信的功能呢？

后面做座机的公司，让研发团队加班加点，做出一个可以发短信的电话座机。满心欢喜的向客户推荐着新功能，卖出去了很多电话机。

后面回访客户发现，大部分的消费者压根就没用过这个功能，这下他们疑惑了：这么好的功能，为啥没人用呢？

其中，有位年轻的客户反馈说：我最近正在谈对象，有一次我用家里的座机给对象发了一条短信，没想到，家里的七大姑八大姨回来后一翻座机，都能看到我的短信记录，然后，我就不用这个功能了。

这家公司才恍然大悟：天啊！我忽略了短信是一个私密的功能，谁也不想把自己的秘密曝光在大众面前，然后赶紧回公司紧急撤销了这个功能。

如何做需求的翻译机

什么是用户需求与产品需求？

用户需求就是用户从自身角度，使用某一产品或服务过程中遇到的问题从自己的经验和想法中提出的需求。

产品需求是挖掘、提炼、分析用户真实需求，从而得出的具有普遍价值，并且符合产品定位的解决方案。解决方案可以理解为一个产品，一个功能或服务。

那用户需求与产品需求有什么关系呢？在苏杰老师的博客中介绍了一种分析模型：Y模型。

把用户需求翻译为产品需求的过程就是需求分析，通过原始需求，我们挖掘用户需求、分析需求，然后输出为产品解决方案。

无论是自己的创新想法，还是市场调研，或者说来自其他方面的需求，最终汇集到产品经理手里，我们需要从5个方面进行需求梳理：谁提出这个需求、需求背后的动机、用户故事（用户-场景-路径）、产品定位、可行性和实现成本等多重因素下，综合判断出最有”性价比“的需求。

决策哪些要做、为什么要做、怎么做，同时也要给出哪些不能做、哪些暂缓做、为什么不能或暂缓？

1. 谁提出的需求

首先需要了解这个需求是谁提出的。因为任何一个产品都是目标用户的，需要根据产品服务的对象，确定客户的等级，哪些是核心用户，哪些是边缘用户。我们最终服务的核心用户是谁，我们需要优先考虑这部分人的需求，而一些边缘人员提出的需求可能不一定会相应。

在面对to B或者to G产品中，掏钱买产品的用户成为客户，而真正使用产品的用户我们称为最终用户。客户与最终用户可能是同一个人也可能不是同一个人。例如钉钉，购买钉钉的是公司领导，而主要使用钉钉的是企业的员工。

我们需要分析出这个需求满足的用户是不是这个产品的目标用户。

比如：钉钉软件中，用户反馈很不喜欢群里面已读和未读的消息状态，但是这个功能钉钉依然保留，甚至是他的核心亮点。因为这个需求满足的是领导层的需求，我们需要优先考虑领导层，所以就牺牲了员工的一些利益。

2. 需求的动机

用户从来只是表达他想要的，但这不一定是解决方案。知道谁提出的需求之后，我们需要多问几个why，挖掘出用户为什么要提出这个需求，他是希望解决什么问题。只有了解需求真正的问题，我们才能提供合适的解决方案。

比如一个屌丝经常吃外卖的屌丝，突然想自己做个蛋炒饭，可是他不知道应该是先放蛋还是先放饭，于是就在百度贴吧发布一个帖子：蛋炒蛋是先放蛋，还是先放饭。很多人回帖：先放蛋。最后蛋炒饭没吃成，锅还糊掉了。他仰天大喊：你们都是骗子，为什么不告诉我要先放油。

这个例子告诉我们，其实他真正的问题不是先放蛋还是先放饭，而是他不会做蛋炒饭。

3. 用户故事

既然已经知道需求提出者会自觉/不自觉地对需求进行加工，那么当我们拿到这些构建于不同需求方自身经验之上的“半成品解决方案”时，务必不能直接开始考虑“怎么做”。而搞明白“为什么做”，在不明确需求的前提下谈方案，根本就是耍流氓。

我们可以从用户、场景、路径3个方面，梳理的用户故事。

• 用户：了解这个需求涉及到哪些人员，对同一个功能，可能存在多个不同的角色的用户，他们的需求可能不一致。
• 场景：分析这个需求是在什么场景下存在，穷尽所有可能的使用场景。
• 路径：在完成功能的梳理，那便是利用流程图将功能进行串联，梳理每个角色需要通过哪些环境才能完成这个任务。

经过需求确认之后，梳理出这需求故事：「什么样的用户」在「什么场景下」，遇到了「什么样的问题」，使用「什么路径」来解决。

例如下图中是信息查询平台中用户反馈的需求：

在这个用户需求中，涉及到了2个目标用户：申请查询人员和运营商反馈信息人员。

场景：申请查询人员，需要通过发起查询申请单，然后运营商跟进申请单的查询内容，反馈查询结果，但是目前查询专员发现运营商有部分反馈错误的情况。

路径：考虑到目前这2个用户之间，运营商是配合查询专员的工作，这个任务主要是查询专员来推动，所以需要由查询专员在原来的申请单上门，重新发起查询任务，以便运营商引起重视，重新反馈。

经过分析之后的需求故事：【查询人员】在【申请查询任务之后，运营商反馈结果】，会偶尔出现【运营商反馈的文件与查询内容不一致的情况】，需要让【查询人员在原来的申请查询任务上面，继续发起查询请求】。

4. 产品定位

我们需要考虑这个需求，是不是符合产品的定位与产品的边界，是不是在这个产品的服务范围内。

比如：考试系统中，我们依赖的是第三方的一个题库系统，通过从题库系统中抽题，来组装一套试卷，给用户进行考试。那么组装试卷的用户希望我们提供一个在线修改试题的功能，因为他们发现有一些试题存在问题，希望可以修改。

从这个考试系统的产品定位，这里负责的是组装试卷，进行考试。试题的问题，需要反馈到第三方的题库系统中，进行修改。

那么这个需求就是不符合产品定位和产品边界的，考虑到问题的出现，考试系统不会提供在线修改错误试题的功能，但是可以提供一个反馈试题问题的信息入口。

5. 可行性和实现成本

虽然现在产品经理一般不懂技术，但是在需求分析过程中，我们还需要考虑需求的可行性，已经实现这个需求的成本。

如果一个非常低频的需求，我们克服了技术难度，但是最后用户很少使用这个功能，那么就这是资源和人力的浪费。

比如：客户提出需要系统上传的文件支持在线预览和在线编辑的功能。首先用户上传的文件类型非常的多，比如word、txt、excel等。客户如果发现文件有问题可以删除错误文件，重新上传，并不是一个影响使用。

目前如果自己去开发在线编辑的功能成本肯定很多，如果调用第三方也是需要增加一笔费用，而客户目前并不想承担这笔费用。那这样的情况下，这个需求目前就是满足不了。

总结

大多数用户提的需求只是「自以为是」的解决方案，而不是产品需求。用户在使用产品过程中，会遇到令用户「体验不爽」的点，也就是「痛点」，此时用户会从自己的角度出发，基于自己的经验提出一个解决方案，这就是「用户需求」。

实际上，用户提出的解决方案往往能够简单地解决该用户遇到的问题，但其实这是一个个性化的解决方案，往往不具有普遍性。

用户遇到的问题具有普通型，但是这个解决方案不具有普遍性，产品经理的工作就是找到这个问题所在，找到一个能够满足绝大多数用户的解决方案，这个解决方案才是「产品需求」。

本文由 @瓜子 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。