（转）产品经理：需求做与不做,一念之间

作为产品经理，每日面临汹涌澎湃、扑面而来的需求，做的最频繁的决定就是Yes, or No,这是一个亘古不变的严肃问题。咋办？

答：以用户或客户场景驱动为核心，即可做出正确决定。

-----跟没说一样，因为大部分人还是不知道怎么操作！

 

 

惯例：从误区说起

 

在很多企业里，产品的大量需求不是来自客户或用户的真实需求，而是来自于：

 

1. 领导指示

很多企业的产品，尤其是To B的产品里，经常有“某总”的一句话需求。在某次汇报上，“某总”提出，应该做xxx，于是这句话就被录进了产品的Backlog里。而且有这样的不成文惯例：领导的职位越高，他的需求的优先级就越高。更极致的，有的企业的看板上增加了一个加急通道，命名为：领导先走（鉴于保密，不方便贴图，遗憾！）

2. 年度战略规划

很多企业每年有年度战略规划，由于规划要给高层领导汇报，因此要做得高大上。很多贴近用户的功能没法拿得出手，不吸引高层的眼球，也无法争取到资源来投入这个产品。于是，战略规划里的产品是艘航空母舰，而实际你只需要一个小快艇。既然规划了就得落地一些功能，因此就这样，一些不贴近用户的航空母舰式的设备安装到了一个小快艇上。

3.  行业竞争

有的企业，用“行业领袖”、“业界第一”这样的目标牵引所有的产品，导致产品经理的注意力转移到先进性上，而不是以用户为中心。这里要区分的是：先进性与满足甚至超越用户期望不是一回事。比如，你的产品有先进的人工智能技术，够先进，但是核心的基础功能不能黏住用户，也是白搭。

以上三点的根本原因是：企业做产品以领导为中心，而不是以用户为中心。

 4. 对市场上竞品的模仿

很多产品经理，看到竞品有什么，自己就急忙做进去，这是最大的忌讳。你的产品要体现的是你的核心价值主张，而不是体现别人的核心价值主张。大量地模仿竞品，说明自己不自信，不知道做什么更好，或者人家的某个功能设计太好了，你无法超越，只能抄袭。

5. 产品经理自己的假设

产品经理依据自己的经验和知识，判断某个需求应该做，这样无可厚非，但是，需要当心的是，你认为某个需求该做的依据是什么？是有相关的用户场景经历？还是自己单方面地以为？很多时候是产品经理单方面“以为”，但是他是那样地确信，连自己都难以区分那是个需要验证的假设，还是已经验证的认知。历史文章产品经理，不要浪费自己和别人的生命|产品洞见介绍了不验证假设的后果。

 

当然，并不是说以上渠道来的需求一律不该做，而是说：不管从什么渠道来的需求，要带到用户或客户的场景中分析是否成立。决定不做比做更困难，也更重要。

我们以用户为中心，听取用户的反馈，但一定不是用户所有的需求都做。什么都做的产品，就是个大杂烩的四不像，从而会失去竞争力，失去用户。按照笔者的经验，用户提的需求，70%都是不需要做的，但是我们还是要聆听那100%的反馈，否则无法筛选出来那些该做的30%的需求；如果是To B的客户已经购买的产品，情况有些不同，即使我们不做也要给出变通的解决方案，或者引导客户使用现有的解决方案。不论如何处理，哪怕采取外交手段，既不能让客户沮丧，也不能随便就妥协接纳，除非我们做的客户高度定制化的产品。

 

不管是什么类型的产品，面对一个需求，我们要仔细分析：用户或客户要解决什么问题，这个需求在什么场景下发生，是不是刚需。说起来容易，做起来难。问以下三个问题即可：

 

1、还原：用户提的是个需求呢，还是个解决方案？

 

通常，用户以为自己提的是个需求，其实是他脑子里设计的解决方案。

案例

曾经一个用户跟我提出：

“我希望你们产品里提供邮件通知功能，每天早上8点钟提醒我有哪些事务代办”。

这是个典型的解决方案。用户的真实需求是：

“我希望有个方法提醒我有哪些要做的事情，以便于我安排当天的工作。”

至于是邮件通知，还是其他方式，是早上提醒，还是晚上提醒，几点合适，这些都属于解决方案的范畴，需要深度挖掘用户的场景才能设计合适的解决方案。如果我们就做了个邮件通知，每天早上定时发送邮件，最终很可能成为垃圾邮件。

 

 

因此，千万不要把用户的所谓“需求”直接录到Backlog里，我们一定要做一个需求还原的处理工作。

2、场景化：用户提的需求，具体在什么场景下产生？

 

场景包括：

• Who: 哪些角色参与

• When:什么时候，在什么条件下发生

• Why: 要解决什么问题

• How Often: 以什么频次发生

• How: 怎么发生

通过对场景的刨根问底，你可以甄别出伪需求。

案例

笔者曾经做过电子看板工具的产品经理，有用户跟我的团队强烈提出：

“我希望将团队看板的几个不同视图切换，每天动态轮播。”

团队觉得这个注意很好，就放到了Backlog里。我了解后，与用户做了如下访谈：

我：听说您想要看板不同视图的动态轮播功能，请问您想要解决的是什么问题?

用户: 现在的看板需要手工切换不同的视图，不能自动播放。我们希望自动播放，不用我手工操作。

我：那么您是希望在什么情况下看自动轮播？

用户答：每次走过去的时候，看一眼。

我：您每天大概什么时候走过去看？

用户想了想，答：好像主要是站会的时候。平时偶尔会走过去看。

我：你们站会的时候，主要看哪些东西？

用户：主要看用户故事的状态；然后看每个人名下的任务状况；最后，看看Backlog里还有哪些重要的需求没有启动。一共三个视图。

我：这三个视图，现在切换的时候，手工有什么不方便的吗？

用户想了想：其实也没有，一键就切换了。

我：那么自动轮播在哪些地方帮助到你们呢？

用户想了良久：嗯…好像就是平时有轮播,我路过的时候看一眼感觉不错。

 

 

由以上对话可以看出，用户提出的需求属于“如果有这个需求感觉很好”，但实质他使用这个需求的场景频次很低，也不是刚需。这是个典型的伪需求，而用户强烈提需求的时候自己却没有发觉。

3、思考“更”：需求如果做了，与用户现有的解决方案比有什么优势？

 

   一个大多数人看不到的事实：在绝大多数情况下，用户远没有他自己说的那么痛，因为他已经在用一些工具或者方法解决他现有的问题。在这样的情况下，需求其实是一个“更”字：更快、更便宜、更方便等。比如：微信比短信的及时通讯方式更便捷，由于微信的解决方案对短信有极大的超越，导致微信颠覆了短信。

如果你将需求做进了产品，却对用户的现有解决方案没有“更”的超越，这个需求就白做了。而且，不是一个稍微“更”，而是极大的“更”。没有极大的超越，就不要着急做。

案例

笔者曾经做过一款企业协同电子工具产品，发布给客户用了一段时间后，笔者深入客户调研，发现一些客户雇佣专门统计度量数据的QA人员, 负责从各种工具里导出数据到Excel中，生成非常丰富的度量数据。我迸发出一个idea:如果把一些核心、通用的度量数据做到我的产品里，这个QA人员就可以解放了。客户听了我的提议，非常高兴。于是我赶紧让团队做。

过一个迭代后上线了，我兴奋地跟这几个客户通知上线消息，客户点赞，还要求我们给团队做培训，讲解在哪里看这些度量数据。但是过了一段时间，根据产品的运营数据，客户从没有访问过度量页面。我回访用户了解原因，客户说，大家已经习惯了QA发度量数据报告，那个报告很全面，而且QA发到邮箱里，我们只需要看邮件就可以，不用登录你们的工具看数据。

我汗颜，为啥跟当初访谈你们的时候说的不一样呢？！结果这个需求白做了，因为没有超越QA的手工报告。我替用户着想给他们节省一个QA人力，但是人家其实不差一个员工的成本。

 

说在最后，产品要功能要丰富起来很容易，对需求多说Yes即可，但是产品跟人一样，要胖起来很容易，要瘦下来很难（亲身经历！）。因为已经有用户在用，当你想去掉一些肉，就会有用户不开心。因此，决策的时候要小心，宁可不做，也不要多做！