很多时候我们都会遇到一种“你就这么做”的需求，如果处理不好，很可能给自己挖一个大坑。作者总结了3个步骤，希望可以帮到你。

最近工作中总是接到一种需求：我要 XX功能，这么做就行！

也就是需求提出者直接带着解决方案找过来，这种需求在产品的工作中十分常见，如果处理不好，很可能给自己挖一个大坑，这篇文章聊一下可以如何接这种需求。本文的描述是基于自己的 C端经历。

从业务部门的一个需求说起

在家办公期间突然接到业务线老大的一个语音，开门见山的和我说：现在我们做的直播，想要在直播过程中和用户增加互动，需要在直播中加上答题功能。

具体方案：一次最多 5道题，主持人发起，(此处省略 500字)，甚至后台怎么配合都给我说了，然后紧接着问我：什么时候能做完上线？

这种直接带解决方案的需求在产品的工作中，经常会碰到，尤其是业务主导，业务方比较强势的公司中更为常见。如果我们直接执行会怎样呢？

产品经理直接从解决方案出发会碰到的问题

对于这种需求，有时可能习惯性的就跟着提出者的解决方案走，直接讨论解决方案的逻辑及细节。

趟了几次坑之后，我发现直接跟着解决方案走，很可能会遇到如下两种情况：

（1）需求是合理的，但是提出者给的解决方案并不好，只是就问题解决问题

这种情况下，提出者的需求是合理的，但由于提出者可能并不具备产品的专业技能，导致方案有缺陷，无法解决问题。

比如，产品的活跃度很低，不健康，于是负责的同事 A找过来：我们产品的活跃太低了，要提升，我们要多给用户增加推送，每天推送 10条，让用户想起我们，打开我们！

用户活跃度低需要提升，这个没问题，但是不分析原因，强行 push，打扰用户，可能初期有一点点效果，但长期下来，只会让产品的卸载率上升。

（2）需求是不合理的，是提出者想当然的结果

这种情况，提出者提出的需求是“错误”的，是自己想当然的，给出的解决方案必然也是错误的。

常见于不考虑产品的目标用户，以及用户的实际使用场景，只是单纯的就功能自嗨。

以上两种情况，无论是哪种，如果产品直接跟着解决方案走，最终的效果都不会很理想，甚至会导致项目反复，临时变更，越做越复杂的情况。

对于这种“你就这么做”的需求如何接

首先我们要知道，解决方案并不等于需求！对于这种情况，我们要回到需求本身，从需求入手。

很重要的一点是：讨论问题，以问题代替方案来和提出者讨论。

可以分为以下几个步骤：

1. 拒绝传递需求，尽可能找到“需求当事人”

在工作中，可能有很多时候，需求是由老大或者业务部门的老大直接提给产品经理的，也就是需求经过了其他人的传递，这种情况下，信息内容可能会失真，和开始的需求不一致，甚至可能“面目全非”。

我们在接收信息的时候会经过两步：理解与加工；理解中可能会出现偏差，在不自主的加工后信息的失真会更严重。

在传递中，他人对信息的理解与加工，可能会影响我们的判断，如果直接按照传递者的说法做，很有可能方向是错的。

因此，在实际工作中，还是建议允许的情况下，尽可能的和“需求当事人”直接接触，了解一线需求。

比如，笔者曾经负责的一个小程序，中间有一个步骤需要用户授权昵称以及手机号，但在开发的时候发现已经不允许同时获取昵称和手机号了，本来打算调整方案，分开获取。结果一个同事说正好他需要找一下业务，可以帮忙沟通一下，给我返回的结果是他们不要昵称了，但给到业务测试的时候，发现人家原本的意思是：可以在这一步不要昵称授权，而不是可以完全不要昵称。

2. 明确是业务需求还是用户需求

对于提过来的需求，我们先大致分为两个类型：业务需求和从用户角度提出的需求。

之所以要先区分，是因为，这两种需求的出发点是不一样的。

对于 C端产品，业务需求通常来自于运营和市场同学，出发的角度是如何更好的运营用户，是从“KPI”角度出发的；而从用户视角出发的需求，则是认为用户是有这个需求的，这么做是更好的帮助用户。

因此，我们对接这两种需求的方法也会有所不同。

（1）业务需求

这类需求是业务部门内部的，比如业务部门需要做个活动，或者要提升某个指标，需要产品端配合。

文章开头的例子中，运营人员提的直播中答题的功能，就属于这种。

配合业务方，更好的进行产品的推广、运营，是十分重要的，但我们不能完全“听从”于业务方，否则业务方不断的来找配合各种活动，整个项目组的人员都会疲于应付。

对于这种需求，我们要明确两个事情：

1）业务方的目的

对于业务方的需求，我们首先要和他们明确：这么做的目的是什么？

提出业务需求很合理，但在做之前，需要先沟通清楚业务方的目的，明确目的可以让我们了解更多的信息，从产品的角度给出思考与建议，更好的配合业务方，也让我们自己处于主动而非被动的位置。

2）要达到什么样的目标？如何衡量？

对于需求，必然要有能够衡量的标准。如果没有衡量标准，各个业务团队不断的做活动、提需求，会让产品和开发疲于应付运营需求，影响产品的正常进度。

因此，在沟通中，我们需要和业务方明确目标以及如何衡量，要能够有明确的数据指标来衡量。

明确这两点：

• 一方面可以让我们了解更多信息，并从产品的角度进行思考与建议，掌握一部分的主动权；
• 一方面，长此以往，也会让业务方在每次提出解决方案前，先明确好目的以及衡量标准，这样可以提前在他们内部就筛选掉不靠谱的需求。

注：目的和目标是两个不同的词。目的更抽象一些，是我们的期望或终极的宗旨，目标则更具体一些，是阶段性的追求。比如，运营同学提的红包活动，目的是想要引导新用户快速下单，具体的目标则是让新用户的下单率提升 10%。

（2）从用户角度提出的需求

这种类型的需求，提出者通常是因为觉得用户是需要的，能更好的满足用户需求，通常也会带着“合理”的理由，但我们还是要谨慎。

对于这种需求，我们要明确：

1）需求是为了哪些用户？

随着产品不断的发展，用户不断的增加，需求会越来越多，越来越多样化，产品中不同的用户，对功能的使用和需要程度都会存在不同，因此，我们需要明确：这个需求，是为了满足哪一部分用户？

2）这部分用户在什么场景下因为什么而会用到它？

需求依附于某一个场景，以及这个场景下遇到的问题。

在明确了为了哪些用户而做之后，我们还需要明确：这些用户在什么情况下，会因为什么而需要它。

比如：人人都是产品经理上传文章的时候，有一个功能：通过链接导入其他平台的文章。这个功能就能够减轻作者人群，在上传文章时排版的工作量。3）目标用户真的“需要解决”这个问题吗？

有时候，确实有需求，但用户真的“需要解决”吗？是否已经有其他的解决方案且广为人知？

比如笔者的一个朋友，曾经想要做一个大学校园的二手交易平台。大学生二手交易这个需求和场景都是存在的，但目标用户真的会有很强的意愿用一个新的方式来解决吗？即使没有这个平台，大学的贴吧、BBS、朋友圈都是他们可以用来出售二手物品的地方。

3. 判断需求的价值

明确需求后，我们要判断需求的价值。

对于业务类的需求，可以通过面向的用户、是否合理、预期投入产出比、是否会造成用户的反感四个方面来考虑。

用户角度的需求则可以从以下几个方面来判断：

（1）需求的覆盖度

这个需求所能覆盖到的用户是多是少？能够覆盖的用户是产品的核心用户还是普通用户？

（2）需求的类型

对于目标用户来说，这个需求是基本型、期待型还是兴奋型？

（3）需求与产品的规划是否一致

需求对产品本身来讲，是否与产品规划一致，是否能够帮助产品更好的服务目标用户？

判断不同需求的价值，主要是为了明确：

1. 是否要做？
2. 优先级如何？

资源总是有限的，我们无法满足所有用户的所有需求，因此，我们需要通过对需求价值的判断，决定哪些需求是需要做的，哪些需求是我们放弃的，以及做的需求中，应该优先做哪些？

注：这里的放弃指的是当前阶段，而不是完全舍弃，随着产品和业务的不断发展，有一些某个阶段不做的需求，可能会在下一阶段就值得去做了。

总结

对于带解决方案的“需求”，核心的一点是：不要跟着解决方案走，解决方案不等于需求！我们要通过对需求类型的区分，用不同的方法来明确真正的需求，并通过对需求价值的判断，明确是否要做。

作者：海先生，公众号：慢言录

本文由 @海先生 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议