产品经理在日常工作中，总会遇到一些糟心事。

A 产品已经入行 1 年了，工作职责就是处理上级分配的小功能需求，认为功能来来去去就那些，画原型已经腻了，完全没有成长空间和业务价值。

而 B 是公司的产品老司机了，一呆就是 3 年，后来还成为了某条产品线负责人。问题是，所属的产品部门在公司话语权很低，业务方说要做什么就做什么。

(相关资料图)

并且产品迭代节奏，完全被业务方牵着走，每天就处理他们提出的各种繁琐问题，没有任何个人的发挥空间。

你是否也遇到了类似“每天做些业务小改动，感觉工作没啥价值”等问题呢？

今天我们就来简单聊聊，如何应对业务方提出的烂需求。

如何识别低价值需求？

上述所说的烂需求，叫“低价值需求”可能更合适。

什么是低价值需求？即投入产出比低的需求。

那如何才能识别它们呢？

可以从“战略契合、市场潜力、商业价值、符合目标、覆盖人群、使用频率、研发成本”这几个维度，判断一个需求的价值高低。

战略契合：并不是什么需求都必须要做，如果需求与用户画像冲突、年度战略规划不符，即使需求价值再高也不做；

市场潜力：相关需求的未来市场有多大？例如 iPhone 面世后，原先全球的手机用户，未来将面临更新换代的需求；

商业价值：通过落地需求方案，能直接、间接为公司带来多少增量收入；

符合目标：通过产品专业的需求挖掘，确保业务方提出的需求，符合其业务目标的占比有多大；

覆盖人群：需要考虑有同样需求的用户，到底是什么量级；

使用频率：推测出每个用户在一年中，遇到该需求的频率；

学习成本：提供的方案，对用户来说，是否能快速学会和易于上手；

研发成本：一个需求开发落地，所需要的工作日时间。

在日常工作中，接到新需求不一定都要考虑这么多因素，你可根据实际情况，进行删减部分。

一些小功能需求，稍微考虑“覆盖人群、使用频率、研发成本”也够了。

应对低价值需求的 3 个方法

有些时候，即使是你认为没有价值的需求，也有可能因为种种原因，成为了版本计划中的高优先级需求。

那么遇到这种情况，要如何处理？

一般来说，有以下三种方法处理：需求记录、版本排期、需求泛化。

需求记录

面对业务的一句话需求，最好的应对方式是，及时记录到产品需求池中，该调研该沟通的工作流程和友好态度，还是要有的。

但假设一顿操作后，发现这个需求价值太低、可有可无，或者业务方连最基础的使用场景，都没想清楚的话，那么还是先在需求池待会吧~

等什么时候业务理清需求的“必要信息、使用场景”了，再处理也不迟。

版本排期

产品团队的迭代节奏，完全被业务方牵着走，更多原因在于产品本身。

由于产品负责人只会疲于应付业务需求，完全没有自己的产品规划。导致近期的版本内容，都是围绕业务进行开发的。

如何才能解决类似问题？核心在于，产品负责人需要主动规划产品路线图。

理想的情况是，版本规划中的业务、产品需求 73 开，留 30% 时间用于产品创新。

最次的情况，即使只有 5% 为产品规划，也不至于那么被动。

遇到一些新的业务低价值需求，也能把当前规划完整列出，迫使业务方重新考虑需求合理性和优先级。

需求泛化

如果一个低价值需求，已经进入了版本排期，此时的产品是不是就躺平了呢？

面对这种尴尬的情况，一种做法是将需求泛化为系统能力，进而满足未来更多的需求组合。

要理解什么是需求泛化，首先要清楚泛化的概念。

什么是泛化？

即由个别的、具体的现象，提炼为普遍的、一般的。这种抽象的思维过程，叫做泛化。

那么需求泛化，指的是将适用范围较窄的需求，扩大为普遍、常见的需求。

例如小明喜欢吃香蕉、苹果，那么原先一家只卖香蕉、苹果和其他零食的小卖部，经过一番装修后，改为什么都卖的水果店。

产品案例：动态收藏功能

举个实际的产品案例。

某电商 APP 的产品，收到了运营的“收藏动态”功能需求。

假设动态模块仅占 APP 流量 3%，而该产品手上又有其他重要需求待做，这时该咋办？

我们先从“覆盖人群、使用频率、研发成本”等维度，简单分析下该需求的实际价值。

覆盖人群：这个动态模块才占 APP 总流量 3%，而动态收藏作为动态的子功能，覆盖人群更是低的可怜；

使用频率：从动态流量占比这个信息，可以推导出该模块是电商 APP 的低频功能，有条件的话写个日志 SQL，就能算出使用频率了；

研发成本：一个动态收藏功能，正常的开发周期大致是 1~2 工作日。

经过一番头脑风暴后，基本判定这个功能，虽然上线较快，但功能价值极低。

有这时间，还不如打几盘王者呢~

开玩笑的哈，作为一个经过专业训练的产品经理，遇到类似需求，除了“需求记录、版本排期”等方法外，还可以进行“需求泛化”。

按正常思路来做，我们会根据运营要求，直接设计、上线“动态收藏”功能。

那如果进行“需求泛化”，该怎么做呢？

抽象来看，该功能核心的能力是“收藏+对象”，按这种方案来做的话，当用户需要收藏更多内容类型时，系统随时支持相关能力复用。

那么，从更长的时间周期来看，原先的烂需求，摇身一变，就成了高价值需求的前奏。

上述方案的具体落地细节，需要掌握数据建模能力，知道一个功能依赖什么数据表，然后对它进行魔改。

我们通过这个案例，简单讲了下需求泛化的大概思路，产品经理要学会举一反三。

那么你学会了吗？

总结

如何应对业务方提出的低价值需求？

可以根据“战略契合、市场潜力、商业价值、符合目标、覆盖人群、使用频率、研发成本”这几个维度，判断需求的价值高低。

然后再通过“需求记录、版本排期、需求泛化”等方法，进行合理应对。

关键词：