带解决方案的需求如何接？只需这3步

很多次，我们将满足“您执行此操作”的需求。 如果处理不当，我们很可能会为自己挖一个大坑。 作者总结了三个步骤，希望对您有所帮助。

很多时候我们会满足“您做得到”的需求，如果处理不当，很可能会给我们自己挖一个大坑。 作者总结了三个步骤，希望对您有所帮助。

最近的工作中总是有

的需求：我想要XX功能，那就去做吧！

是需求提议者直接带来解决方案。 这种要求在产品工作中很常见。 如果处理不当，很可能会给自己挖一个大坑。 本文将讨论如何满足这种要求。 本文的描述基于我自己的C终端经验。

从业务部门的需求开始。 当他在家中工作时，

突然收到业务部门负责人的声音。 他直接对我说：对于我们现在正在进行的直播，如果要在直播过程中增加与用户的互动，我们需要在直播中增加回答问题的功能。

特定方案：一次最多由主机发起5个问题（此处省略500个单词），甚至与后台合作，然后问我：什么时候可以完成在线？

是直接解决方案的需求，在产品的工作中经常遇到，特别是在业务领先且业务实力雄厚的公司中。 如果我们直接执行该怎么办？ 对于此类需求，

产品经理将直接从解决方案

中遇到问题，有时他们可能会习惯性地遵循提议者的解决方案，直接讨论解决方案的逻辑和细节。 在经过几次针对

的维修站之后，我发现如果直接遵循解决方案，我可能会遇到以下两种情况：

（1）需求是合理的，但是提议者给出的解决方案并不好，只是 为了在这种情况下解决问题

，提议者的要求是合理的，但是由于提议者可能没有产品的专业技能，因此解决方案存在缺陷，无法解决问题。 以

展开全文

为例，产品活动非常低，不健康，因此负责的同事A会发现：我们的产品活动过低。 为了改进，我们需要向用户添加更多推送，每天10次推送，提醒我们的用户，打开我们！

用户活动较少，需要改进。 没问题，但是如果不分析原因并强行推动打扰用户，一开始可能效果不大，但从长远来看，只会增加产品的卸载速度。

（2）需求不合理，这是提议者的假设

的结果。 提议者的要求是“错误”，这是他自己的假设，给出的解决方案也是错误的。

通常在用户的实际使用场景中使用，而没有考虑产品的目标用户。 这只是一个简单的功能。

和

。 无论哪种情况，如果产品直接遵循解决方案，最终效果都不会很好，甚至导致项目的重复和临时更改，情况会更加复杂。 为此，您首先需要如何连接

，我们需要知道解决方案不等于需求！ 在这种情况下，我们应该回到需求本身，并从需求开始。

非常重要：讨论问题并用问题代替方案与提议者讨论。

可以分为以下步骤：

1。 拒绝交付需求，并尝试在工作中找到“需求方”

，可能有很多次需求是由老板或业务部门的老板直接提交给产品经理的，即 例如，需求是由其他人传递的。 在这种情况下，信息内容可能会失真，与初始需求不一致，甚至“完全不同”。 当我们收到信息时，我们将经历两个步骤：理解和处理； 处理后可能会产生理解上的偏差，信息失真也会更加严重。 在传递

时，其他人对信息的理解和处理可能会影响我们的判断力。 如果我们直接根据发件人的声明进行操作，则可能是方向错误。 因此，在实际工作中，建议尽可能与“需求方”直接联系，以了解一线需求。 以

为例，作者曾经负责一个小程序。 该过程中有一个步骤要求用户授权昵称和手机号码。 但是，在开发过程中，发现不允许同时获取昵称和手机号码。 旨在调整方案并单独获得它们。 结果，一位同事说他需要找到一家公司来帮助沟通。 返回给我的结果是，他们不需要昵称。 但是当他进行业务测试时，他发现其他人的本意是他们不能在此步骤中授权昵称，而不是根本不需要昵称。

2。 为了明确是业务需求还是用户需求，

可以大致分为两种：业务需求和用户需求。 首先要区分

的原因是这两个要求的起点不同。 C端产品的

，业务需求通常来自运营和市场营销专业的学生。 出发点是如何从“ KPI”的角度更好地操作用户。 从用户的角度来看，需求就是用户有这种需求，因此更好地为用户提供帮助。 因此，我们对这两个要求的处理方法将有所不同。

（1）业务需求2

这种需求是业务部门的内部需求。 例如，业务部门需要做一个活动，或者要改善某个指标，就需要产品端的配合。 在

文章开头的示例中，运营商提出的实时广播中回答问题的功能属于这种功能。 为了更好地推广和操作产品，与

进行业务合作非常重要，但是我们不能完全“听”业务端，否则业务端将不断寻找并配合各种活动，并且 整个项目团队的人员都会厌倦应对。 对于这种需求，我们需要澄清两件事：

1）业务目的为了满足业务需求，我们首先需要与他们澄清：这样做的目的是什么？

提出了非常合理的业务需求，但是在我们这样做之前，我们需要清楚地传达业务方面的目的，这可以让我们了解更多信息，从产品的角度提出想法和建议，更好地与业务合作 方面，也让我们处于主动而不是被动的位置。

2）要达到的目标是什么？ 如何测量？

对于需求，必须有可衡量的标准。 如果没有度量标准，则每个业务团队的持续活动和需求会使产品和开发人员无法满足操作要求，并影响产品的正常进度。 因此，在沟通中，我们需要弄清目标以及如何与业务方一起衡量它们，并有明确的数据指标来衡量它们。

阐明了这两点：一方面，

使我们能够学习更多信息，从产品的角度思考和提出建议，并掌握一部分的主动性； 另一方面，从长远来看，它还允许业务方在提出每种解决方案之前弄清目的和度量标准，以便他们可以提前筛选出不可靠的需求。

注意：目的和目标是两个不同的词。 目标更加抽象，这是我们的期望或最终目标，而目标更加具体，这是分阶段的追求。 例如，运行学生提议的红包活动的目的是引导新用户快速下订单，而具体目标是将新用户的订购率提高10％。 从用户的角度来看

（2），这种类型的需求

通常由提议者提出，因为他认为用户需要它并且可以更好地满足用户的需求，通常是出于“合理”的原因，但是我们 应该谨慎。 对于

的这种需求，我们需要明确：

1）需求是针对哪些用户的？ 随着产品的不断发展和用户数量的增加，需求将会越来越多样化。 产品中的不同用户将对功能有不同的用途和需求。 因此，我们需要明确：此需求可以满足哪一部分用户？

2）这些用户将在什么情况下使用它？

需要附加到某个方案，并且在此方案中遇到问题。

明确说明要针对哪些用户进行操作之后，我们还需要明确说明：在什么情况下，这些用户将针对什么进行操作。 例如

：当每个人都是产品经理都在上传文章时，就有一个功能：通过链接从其他平台导入文章。 此功能可以减少上传文章时作者组和排版的工作量。 3）目标用户是否真的“需要解决”这个问题？

有时有需求，但是用户真的“需要解决”吗？ 是否已经有其他解决方案并且众所周知？ 例如

，作者的一个朋友曾经想成为校园内的二手交易平台。 存在大学生的二手交易需求和情景，但是目标用户真的有强烈的意愿以新的方式解决它吗？ 即使没有此平台，大学邮局，BBS和朋友圈也都是可以出售二手商品的地方。

3。 判断需求值

我们需要在需求明确后判断需求值。 对

的商务舱需求可以从四个方面考虑：面对用户，是否合理，预期的投入产出比以及是否会引起用户的反感。 从

用户的角度，我们可以从以下几个方面进行判断：

（1）可以覆盖多少个用户？ 是可以覆盖产品的核心用户还是普通用户的用户？

（2）目标用户的需求

的类型，此需求是基本需求，预期需求还是兴奋的？

（3）需求是否与产品计划一致？

是与产品本身的产品计划一致的需求，并且可以帮助产品更好地为目标用户提供服务吗？

判断不同需求的价值，主要是要弄清楚：

资源总是有限的，我们不能满足所有用户的所有需求，因此我们需要判断需求的价值以确定需要满足哪些需求 完成，哪些我们需要放弃，哪些需要首先完成？

注意：此处的放弃是指当前阶段，而不是完全放弃。 随着产品和业务的不断发展，某些需求在某个阶段没有完成，而在下一阶段可能值得完成。

用解决方案总结了

的“要求”。 核心点是：不要遵循解决方案。 解决方案不等于要求！ 我们需要区分需求的类型，并使用不同的方法来澄清实际需求。