在产品开发的过程中，产品的内部、外部利益干系人会提出很多自己的期望；每个产品版本发布后，团队会收到用户的反馈意见。作为产品负责人，你会发现随着产品继续向前推进，收到的需求会越来越多，总有堆积如山的需求等待着团队去做。因此，判断某个需求做与不做，成为产品负责人需要做出的至关重要的决策。

产品决策要以“用户或客户场景驱动”为核心，即面对一个需求，首先，判断这是否是用户或客户真实的需求，以及这个需求是在什么场景下产生的。其次，如果是真实的需求，再进行竞品分析，分析同行竞品是否有这个功能。如果有，它们是如何设计来满足用户需求的？如果没有，它们可能会有什么考虑？如果我们要做这个功能，设计方案是什么，如何确保竞争力？最后，看内部资源是否具备条件，可以使这个功能在合适的市场窗口期推出。

整个过程如图8-18所示。

图8-18产品需求决策过程示意图

在很多企业里，产品的大量功能不是来自客户或用户的真实需求，而是来自于以下几个方面。

（1） 产品负责人自己的假设。产品负责人依据自己的经验和知识来判断某个需求是否应该做。然而，需要注意的是，判断某个需求该做的依据是什么？是有相关的用户场景经历，还是自己单方面的假设？很多时候，产品负责人自己都难以区分那是个需要验证的假设，还是已经被验证的结论。

（2） 对市场上竞品的模仿。很多负责人看到竞品有什么功能，自己就急忙做什么功能，这是最大的忌讳。产品要体现的是自己的核心价值主张，而不是别人的核心价值主张。大量地模仿竞品只能说明自己不自信，不知道做什么功能更好；或者说明人家的某个功能设计得太好了，我们无法超越和创新，只能跟风、抄袭。

（3） 年度战略规划。很多企业都会做年度战略规划，由于规划要汇报给高层领导，因此要做得高大上才行。然而很多贴近用户的功能没法拿得出手，因为那些不吸引高层的眼球，进而无法争取到这个产品所需的资源。于是，战略规划里的产品成了“航空母舰”，而实际上也许用户只需要一艘“小快艇”，一些用户不需要的设备也被装到了这艘“小快艇”上。

（4） 行业竞争。有些企业喜欢用“行业领袖”“业界第一”这样的目标牵引所有产品的发展方向，这使得产品负责人将注意力放到了虚荣的先进性上，而不是扎扎实实地以用户为中心。需要注意的是，先进性与满足甚至超越用户的期望不是一回事。比如，一个社交产品有先进的人工智能技术，可以智能化地向你推荐你有兴趣交往的人。但是如果连像聊天这样的核心基础功能都做得令用户体验感很差，那么即使人工智能技术再好也是白费。

（5） 领导指示。很多企业的产品，尤其是在ToB产品的Backlog里，经常有“某总”的一句话需求。诸如在某次汇报上，“某总”提出，应该做……，于是这句话就被录进了产品的Backlog里。而且有这样不成文的惯例：领导的职位越高，他提的需求的优先级就越高。

当然，上述渠道的需求并不是一律不该做。不管从什么渠道获得的需求，都要将其带到用户或客户的场景中去分析。即使需求成立，还要考虑档期，以及与其他需求相比，其优先级是否足够高，从客户价值角度分析，是否值得做等。所以，决定不做某项需求比决定做某项需求更困难，也更重要。

即便是用户或客户的原始需求，我们也需要小心甄别。以用户为中心，听取用户的反馈，并不意味着用户提出的所有的需求都要去做。根据经验，用户提出的需求里有70%都是不需要做的，但是我们要聆听用户全部的反馈，否则就无法筛选出来那些该做的30%的需求。

不管是什么类型的产品，我们都要仔细分析需求，比如，用户或客户要解决什么问题？这个需求在什么场景下发生，是不是刚需？具体来说，当面对一个需求时，我们可以做好以下工作。

1.还原需求

很多情况下，用户以为自己提的是个需求，其实这是他/她脑子里设计的解决方案。所以我们要分析用户需求的本质，思考用户提出的是需求还是解决方案。

我在做电子看板工具产品的时候，一个用户向我提出：“我希望产品有邮件通知功能，每天早上8点钟提醒我有哪些事情需要办理。”

这个陈述是个典型的需求解决方案。用户的真实需求是：“我希望有个方法能提醒我有哪些要做的事情，以便于我安排好当天的工作。”至于是采取邮件通知的方式，还是其他方式，提醒时间安排在几点合适，这些都属于解决方案的范畴，需要深度挖掘用户的场景才能设计出合适的解决方案。如果我们直接做个邮件通知，每天早上8点钟定时发送邮件，那么这些邮件最终很可能成为垃圾邮件。因此，千万不要把用户提出的所谓“需求”直接收录到Backlog里，我们一定要做需求还原的工作。

2. 用场景化甄别出伪需求

用户提的需求会在什么场景下产生？对以下问题进行分析，就可以甄别出其是否为伪需求。

• Who：哪些角色参与。
• When：什么时候、在什么条件下发生。
• Why：要解决什么问题。
• HowOften：以什么频次发生。
• How：怎么发生。
  

还是拿我做的电子看板工具为例。曾经有用户向我的团队提出这样的需求：“我希望将团队看板的几个不同视图做切换，每天动态轮播。”团队觉得这个主意很好，就放到了Backlog里并向我提议。我了解后，与用户做了如下访谈。

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

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

我：那么您是希望在什么情况下看自动轮播呢？用户：每当我走过去的时候会看一眼。

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

用户：主要是开站会的时候，平时偶尔也会走过去看看。我：你们开站会的时候，主要看哪些东西？

用户：主要看用户故事的状态，然后看每个人名下的任务状态，最后看看Backlog里还有哪些重要的需求没有启动。一共三个视图。我：现在手动切换这三个视图有什么不方便的吗？用户：其实也没有，一键就切换了。

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

用户：如果有轮播，平时我路过的时候看一眼感觉会很不错。

通过以上访谈我们可以看出，用户提出的这个需求并不是他真正需要的。这是个典型的伪需求，用户对此并没有察觉。

3.判断是否是刚需、高频或大客户的需求

排除伪需求后，我们再来分析这个需求是不是刚需，即卡诺模型里的“必备属性”需求。如果是刚需，我们再判断用户对需求的使用频次。如果这个需求是刚需、高频，则应该做；如果这个需求是刚需、低频，则需要判断是否会带来其他方面的价值，比如对于ToB产品的大客户来说，虽然可能某个需求的使用频次低，但对于客户的商业价值很高，同时也会带来较高的收益，因此我们可能还是会选择接纳。

产品里的那些刚需、高频的特性是需要重点打磨的地方。例如微信的发送消息、发朋友圈等特性是典型的刚需、高频特性。因此，我们一定要重点打磨这类特性，给客户最佳的体验感。

4.判断是否解决了“更”的问题

与用户现有的解决方案相比，我们完成的这个需求有什么优势？是否带来了副作用？

一个大多数人都看不到的事实是，在绝大多数情况下，用户远没有其自己说的那么“痛”，因为他已经在用一些工具或者方法解决他遇到的问题。在这样的情况下，需求意味着更快、更便宜、更方便等。比如，微信比短信的即时通信方式更便捷。

如果你将需求做进了产品之中，却对用户现有的解决方案没有更大的超越，那么这个需求就白做了。

还是拿我做过的电子看板工具为例。我曾经深入客户中调研，发现一些客户雇用专门统计度量数据的QA人员，他们负责从各种工具里导出数据到Excel中，生成了大量的度量数据。对此，我迸发出一个想法：如果把一些核心通用的度量数据做到产品里，这些QA人员就可以解放了。客户听了我的提议非常高兴，于是我赶紧让团队去做。

这个功能上线后，我兴奋地向这几个客户通知了上线消息，客户点赞，还要求我们给他们的团队做培训，讲解怎么使用。但是过了一段时间，我查看了产品的运营数据，发现客户从没有访问过度量页面。于是，我回访了客户，客户说：“大家已经习惯了采用QA人员发布的度量数据报告，那个报告很全面，而且QA人员将报告发到邮箱里，我们只需要看邮件就可以，不用登录你们的工具看数据。”

结果是，这个需求没有达到原来设想的目的。究其原因，这个解决方案并没有更大地超越QA人员的报告。

5.判断是否是全流程的需求

如果需求只是全流程场景中的一部分，我们就要思考是否可以将其延展到全流程场景，如果不能延展，那么这个需求与用户现有的解决方案衔接起来是否流畅。

在上述案例中，如果我们将需求延展到全流程场景，那么产品不仅能生成度量数据，还可以定制化地生成报告的内容。这样的话，用户从管理需求、跟踪度量数据到接收数据报告的全流程所需就都实现了。可是如果我们只做了前两个部分，而没有解决第三个部分“接收数据报告”的问题，那么用户自然还是喜欢既有的解决方案。

在产品开发的过程中，产品的内部、外部利益干系人会提出很多自己的期望；每个产品版本发布后，团队会收到用户的反馈意见。作为产品负责人，你会发现随着产品继续向前推进，收到的需求会越来越多，总有堆积如山的需求等待着团队去做。因此，判断某个需求做与不做，成为产品负责人需要做出的至关重要的决策。

产品决策要以“用户或客户场景驱动”为核心，即面对一个需求，首先，判断这是否是用户或客户真实的需求，以及这个需求是在什么场景下产生的。其次，如果是真实的需求，再进行竞品分析，分析同行竞品是否有这个功能。如果有，它们是如何设计来满足用户需求的？如果没有，它们可能会有什么考虑？如果我们要做这个功能，设计方案是什么，如何确保竞争力？最后，看内部资源是否具备条件，可以使这个功能在合适的市场窗口期推出。

整个过程如图8-18所示。

图8-18产品需求决策过程示意图

在很多企业里，产品的大量功能不是来自客户或用户的真实需求，而是来自于以下几个方面。

（1） 产品负责人自己的假设。产品负责人依据自己的经验和知识来判断某个需求是否应该做。然而，需要注意的是，判断某个需求该做的依据是什么？是有相关的用户场景经历，还是自己单方面的假设？很多时候，产品负责人自己都难以区分那是个需要验证的假设，还是已经被验证的结论。

（2） 对市场上竞品的模仿。很多负责人看到竞品有什么功能，自己就急忙做什么功能，这是最大的忌讳。产品要体现的是自己的核心价值主张，而不是别人的核心价值主张。大量地模仿竞品只能说明自己不自信，不知道做什么功能更好；或者说明人家的某个功能设计得太好了，我们无法超越和创新，只能跟风、抄袭。

（3） 年度战略规划。很多企业都会做年度战略规划，由于规划要汇报给高层领导，因此要做得高大上才行。然而很多贴近用户的功能没法拿得出手，因为那些不吸引高层的眼球，进而无法争取到这个产品所需的资源。于是，战略规划里的产品成了“航空母舰”，而实际上也许用户只需要一艘“小快艇”，一些用户不需要的设备也被装到了这艘“小快艇”上。

（4） 行业竞争。有些企业喜欢用“行业领袖”“业界第一”这样的目标牵引所有产品的发展方向，这使得产品负责人将注意力放到了虚荣的先进性上，而不是扎扎实实地以用户为中心。需要注意的是，先进性与满足甚至超越用户的期望不是一回事。比如，一个社交产品有先进的人工智能技术，可以智能化地向你推荐你有兴趣交往的人。但是如果连像聊天这样的核心基础功能都做得令用户体验感很差，那么即使人工智能技术再好也是白费。

（5） 领导指示。很多企业的产品，尤其是在ToB产品的Backlog里，经常有“某总”的一句话需求。诸如在某次汇报上，“某总”提出，应该做……，于是这句话就被录进了产品的Backlog里。而且有这样不成文的惯例：领导的职位越高，他提的需求的优先级就越高。

当然，上述渠道的需求并不是一律不该做。不管从什么渠道获得的需求，都要将其带到用户或客户的场景中去分析。即使需求成立，还要考虑档期，以及与其他需求相比，其优先级是否足够高，从客户价值角度分析，是否值得做等。所以，决定不做某项需求比决定做某项需求更困难，也更重要。

即便是用户或客户的原始需求，我们也需要小心甄别。以用户为中心，听取用户的反馈，并不意味着用户提出的所有的需求都要去做。根据经验，用户提出的需求里有70%都是不需要做的，但是我们要聆听用户全部的反馈，否则就无法筛选出来那些该做的30%的需求。

不管是什么类型的产品，我们都要仔细分析需求，比如，用户或客户要解决什么问题？这个需求在什么场景下发生，是不是刚需？具体来说，当面对一个需求时，我们可以做好以下工作。

1.还原需求

很多情况下，用户以为自己提的是个需求，其实这是他/她脑子里设计的解决方案。所以我们要分析用户需求的本质，思考用户提出的是需求还是解决方案。

我在做电子看板工具产品的时候，一个用户向我提出：“我希望产品有邮件通知功能，每天早上8点钟提醒我有哪些事情需要办理。”

这个陈述是个典型的需求解决方案。用户的真实需求是：“我希望有个方法能提醒我有哪些要做的事情，以便于我安排好当天的工作。”至于是采取邮件通知的方式，还是其他方式，提醒时间安排在几点合适，这些都属于解决方案的范畴，需要深度挖掘用户的场景才能设计出合适的解决方案。如果我们直接做个邮件通知，每天早上8点钟定时发送邮件，那么这些邮件最终很可能成为垃圾邮件。因此，千万不要把用户提出的所谓“需求”直接收录到Backlog里，我们一定要做需求还原的工作。

2. 用场景化甄别出伪需求

用户提的需求会在什么场景下产生？对以下问题进行分析，就可以甄别出其是否为伪需求。

• Who：哪些角色参与。
• When：什么时候、在什么条件下发生。
• Why：要解决什么问题。
• HowOften：以什么频次发生。
• How：怎么发生。
  

还是拿我做的电子看板工具为例。曾经有用户向我的团队提出这样的需求：“我希望将团队看板的几个不同视图做切换，每天动态轮播。”团队觉得这个主意很好，就放到了Backlog里并向我提议。我了解后，与用户做了如下访谈。

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

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

我：那么您是希望在什么情况下看自动轮播呢？用户：每当我走过去的时候会看一眼。

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

用户：主要是开站会的时候，平时偶尔也会走过去看看。我：你们开站会的时候，主要看哪些东西？

用户：主要看用户故事的状态，然后看每个人名下的任务状态，最后看看Backlog里还有哪些重要的需求没有启动。一共三个视图。我：现在手动切换这三个视图有什么不方便的吗？用户：其实也没有，一键就切换了。

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

用户：如果有轮播，平时我路过的时候看一眼感觉会很不错。

通过以上访谈我们可以看出，用户提出的这个需求并不是他真正需要的。这是个典型的伪需求，用户对此并没有察觉。

3.判断是否是刚需、高频或大客户的需求

排除伪需求后，我们再来分析这个需求是不是刚需，即卡诺模型里的“必备属性”需求。如果是刚需，我们再判断用户对需求的使用频次。如果这个需求是刚需、高频，则应该做；如果这个需求是刚需、低频，则需要判断是否会带来其他方面的价值，比如对于ToB产品的大客户来说，虽然可能某个需求的使用频次低，但对于客户的商业价值很高，同时也会带来较高的收益，因此我们可能还是会选择接纳。

产品里的那些刚需、高频的特性是需要重点打磨的地方。例如微信的发送消息、发朋友圈等特性是典型的刚需、高频特性。因此，我们一定要重点打磨这类特性，给客户最佳的体验感。

4.判断是否解决了“更”的问题

与用户现有的解决方案相比，我们完成的这个需求有什么优势？是否带来了副作用？

一个大多数人都看不到的事实是，在绝大多数情况下，用户远没有其自己说的那么“痛”，因为他已经在用一些工具或者方法解决他遇到的问题。在这样的情况下，需求意味着更快、更便宜、更方便等。比如，微信比短信的即时通信方式更便捷。

如果你将需求做进了产品之中，却对用户现有的解决方案没有更大的超越，那么这个需求就白做了。

还是拿我做过的电子看板工具为例。我曾经深入客户中调研，发现一些客户雇用专门统计度量数据的QA人员，他们负责从各种工具里导出数据到Excel中，生成了大量的度量数据。对此，我迸发出一个想法：如果把一些核心通用的度量数据做到产品里，这些QA人员就可以解放了。客户听了我的提议非常高兴，于是我赶紧让团队去做。

这个功能上线后，我兴奋地向这几个客户通知了上线消息，客户点赞，还要求我们给他们的团队做培训，讲解怎么使用。但是过了一段时间，我查看了产品的运营数据，发现客户从没有访问过度量页面。于是，我回访了客户，客户说：“大家已经习惯了采用QA人员发布的度量数据报告，那个报告很全面，而且QA人员将报告发到邮箱里，我们只需要看邮件就可以，不用登录你们的工具看数据。”

结果是，这个需求没有达到原来设想的目的。究其原因，这个解决方案并没有更大地超越QA人员的报告。

5.判断是否是全流程的需求

如果需求只是全流程场景中的一部分，我们就要思考是否可以将其延展到全流程场景，如果不能延展，那么这个需求与用户现有的解决方案衔接起来是否流畅。

在上述案例中，如果我们将需求延展到全流程场景，那么产品不仅能生成度量数据，还可以定制化地生成报告的内容。这样的话，用户从管理需求、跟踪度量数据到接收数据报告的全流程所需就都实现了。可是如果我们只做了前两个部分，而没有解决第三个部分“接收数据报告”的问题，那么用户自然还是喜欢既有的解决方案。