在日常工作中，产品经理常常会遇到一些烦心事，被业务方牵着鼻子走，每天都在处理一些小改动，没有发挥自身的价值。本文就来简单聊聊，如何应对业务方提出的烂需求，希望对你有所启发。
产品经理在日常工作中，总会遇到一些糟心事。
A 产品已经入行 1 年了，工作职责就是处理上级分配的小功能需求，认为功能来来去去就那些，画原型已经腻了，完全没有成长空间和业务价值。
而 B 是公司的产品老司机了，一呆就是 3 年，后来还成为了某条产品线负责人。问题是，所属的产品部门在公司话语权很低，业务方说要做什么就做什么。
并且产品迭代节奏，完全被业务方牵着走，每天就处理他们提出的各种繁琐问题，没有任何个人的发挥空间。
你是否也遇到了类似“每天做些业务小改动，感觉工作没啥价值”等问题呢？
今天我们就来简单聊聊，如何应对业务方提出的烂需求。
上述所说的烂需求，叫“低价值需求”可能更合适。
什么是低价值需求？即投入产出比低的需求。
那如何才能识别它们呢？
可以从“战略契合、市场潜力、商业价值、符合目标、覆盖人群、使用频率、研发成本”这几个维度，判断一个需求的价值高低。
战略契合：并不是什么需求都必须要做，如果需求与用户画像冲突、年度战略规划不符，即使需求价值再高也不做；
在日常工作中，接到新需求不一定都要考虑这么多因素，你可根据实际情况，进行删减部分。
一些小功能需求，稍微考虑“覆盖人群、使用频率、研发成本”也够了。
有些时候，即使是你认为没有价值的需求，也有可能因为种种原因，成为了版本计划中的高优先级需求。
那么遇到这种情况，要如何处理？
一般来说，有以下三种方法处理：需求记录、版本排期、需求泛化。
面对业务的一句话需求，最好的应对方式是，及时记录到产品需求池中，该调研该沟通的工作流程和友好态度，还是要有的。
但假设一顿操作后，发现这个需求价值太低、可有可无，或者业务方连最基础的使用场景，都没想清楚的话，那么还是先在需求池待会吧~
等什么时候业务理清需求的“必要信息、使用场景”了，再处理也不迟。
产品团队的迭代节奏，完全被业务方牵着走，更多原因在于产品本身。
由于产品负责人只会疲于应付业务需求，完全没有自己的产品规划。导致近期的版本内容，都是围绕业务进行开发的。
如何才能解决类似问题？核心在于，产品负责人需要主动规划产品路线图。
理想的情况是，版本规划中的业务、产品需求 73 开，留 30% 时间用于产品创新。
最次的情况，即使只有 5% 为产品规划，也不至于那么被动。
遇到一些新的业务低价值需求，也能把当前规划完整列出，迫使业务方重新考虑需求合理性和优先级。
如果一个低价值需求，已经进入了版本排期，此时的产品是不是就躺平了呢？
面对这种尴尬的情况，一种做法是将需求泛化为系统能力，进而满足未来更多的需求组合。
要理解什么是需求泛化，首先要清楚泛化的概念。
什么是泛化？
即由个别的、具体的现象，提炼为普遍的、一般的。这种抽象的思维过程，叫做泛化。
那么需求泛化，指的是将适用范围较窄的需求，扩大为普遍、常见的需求。
例如小明喜欢吃香蕉、苹果，那么原先一家只卖香蕉、苹果和其他零食的小卖部，经过一番装修后，改为什么都卖的水果店。
产品案例：动态收藏功能
举个实际的产品案例。
某电商 APP 的产品，收到了运营的“收藏动态”功能需求。
假设动态模块仅占 APP 流量 3%，而该产品手上又有其他重要需求待做，这时该咋办？
我们先从“覆盖人群、使用频率、研发成本”等维度，简单分析下该需求的实际价值。
经过一番头脑风暴后，基本判定这个功能，虽然上线较快，但功能价值极低。
有这时间，还不如打几盘王者呢~
开玩笑的哈，作为一个经过专业训练的产品经理，遇到类似需求，除了“需求记录、版本排期”等方法外，还可以进行“需求泛化”。
按正常思路来做，我们会根据运营要求，直接设计、上线“动态收藏”功能。
那如果进行“需求泛化”，该怎么做呢？
抽象来看，该功能核心的能力是“收藏+对象”，按这种方案来做的话，当用户需要收藏更多内容类型时，系统随时支持相关能力复用。
那么，从更长的时间周期来看，原先的烂需求，摇身一变，就成了高价值需求的前奏。
上述方案的具体落地细节，需要掌握数据建模能力，知道一个功能依赖什么数据表，然后对它进行魔改。
我们通过这个案例，简单讲了下需求泛化的大概思路，产品经理要学会举一反三。
那么你学会了吗？
本文由 @好夕雷 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。