在日常工作中，產(chǎn)品經(jīng)理常常會遇到一些煩心事，被業(yè)務(wù)方牽著鼻子走，每天都在處理一些小改動(dòng)，沒有發(fā)揮自身的價(jià)值。本文就來簡單聊聊，如何應(yīng)對業(yè)務(wù)方提出的爛需求，希望對你有所啟發(fā)。

產(chǎn)品經(jīng)理在日常工作中，總會遇到一些糟心事。

A 產(chǎn)品已經(jīng)入行 1 年了，工作職責(zé)就是處理上級分配的小功能需求，認(rèn)為功能來來去去就那些，畫原型已經(jīng)膩了，完全沒有成長空間和業(yè)務(wù)價(jià)值。

而 B 是公司的產(chǎn)品老司機(jī)了，一呆就是 3 年，后來還成為了某條產(chǎn)品線負(fù)責(zé)人。問題是，所屬的產(chǎn)品部門在公司話語權(quán)很低，業(yè)務(wù)方說要做什么就做什么。

并且產(chǎn)品迭代節(jié)奏，完全被業(yè)務(wù)方牽著走，每天就處理他們提出的各種繁瑣問題，沒有任何個(gè)人的發(fā)揮空間。

你是否也遇到了類似“每天做些業(yè)務(wù)小改動(dòng)，感覺工作沒啥價(jià)值”等問題呢？

今天我們就來簡單聊聊，如何應(yīng)對業(yè)務(wù)方提出的爛需求。

一、如何識別低價(jià)值需求？

上述所說的爛需求，叫“低價(jià)值需求”可能更合適。

什么是低價(jià)值需求？即投入產(chǎn)出比低的需求。

那如何才能識別它們呢？

可以從“戰(zhàn)略契合、市場潛力、商業(yè)價(jià)值、符合目標(biāo)、覆蓋人群、使用頻率、研發(fā)成本”這幾個(gè)維度，判斷一個(gè)需求的價(jià)值高低。

戰(zhàn)略契合：并不是什么需求都必須要做，如果需求與用戶畫像沖突、年度戰(zhàn)略規(guī)劃不符，即使需求價(jià)值再高也不做；

• 市場潛力：相關(guān)需求的未來市場有多大？例如 iPhone 面世后，原先全球的手機(jī)用戶，未來將面臨更新?lián)Q代的需求；
• 商業(yè)價(jià)值：通過落地需求方案，能直接、間接為公司帶來多少增量收入；
• 符合目標(biāo)：通過產(chǎn)品專業(yè)的需求挖掘，確保業(yè)務(wù)方提出的需求，符合其業(yè)務(wù)目標(biāo)的占比有多大；
• 覆蓋人群：需要考慮有同樣需求的用戶，到底是什么量級；
• 使用頻率：推測出每個(gè)用戶在一年中，遇到該需求的頻率；
• 學(xué)習(xí)成本：提供的方案，對用戶來說，是否能快速學(xué)會和易于上手；
• 研發(fā)成本：一個(gè)需求開發(fā)落地，所需要的工作日時(shí)間。

在日常工作中，接到新需求不一定都要考慮這么多因素，你可根據(jù)實(shí)際情況，進(jìn)行刪減部分。

一些小功能需求，稍微考慮“覆蓋人群、使用頻率、研發(fā)成本”也夠了。

二、應(yīng)對低價(jià)值需求的 3 個(gè)方法

有些時(shí)候，即使是你認(rèn)為沒有價(jià)值的需求，也有可能因?yàn)榉N種原因，成為了版本計(jì)劃中的高優(yōu)先級需求。

那么遇到這種情況，要如何處理？

一般來說，有以下三種方法處理：需求記錄、版本排期、需求泛化。

1. 需求記錄

面對業(yè)務(wù)的一句話需求，最好的應(yīng)對方式是，及時(shí)記錄到產(chǎn)品需求池中，該調(diào)研該溝通的工作流程和友好態(tài)度，還是要有的。

但假設(shè)一頓操作后，發(fā)現(xiàn)這個(gè)需求價(jià)值太低、可有可無，或者業(yè)務(wù)方連最基礎(chǔ)的使用場景，都沒想清楚的話，那么還是先在需求池待會吧~

等什么時(shí)候業(yè)務(wù)理清需求的“必要信息、使用場景”了，再處理也不遲。

2. 版本排期

產(chǎn)品團(tuán)隊(duì)的迭代節(jié)奏，完全被業(yè)務(wù)方牽著走，更多原因在于產(chǎn)品本身。

由于產(chǎn)品負(fù)責(zé)人只會疲于應(yīng)付業(yè)務(wù)需求，完全沒有自己的產(chǎn)品規(guī)劃。導(dǎo)致近期的版本內(nèi)容，都是圍繞業(yè)務(wù)進(jìn)行開發(fā)的。

如何才能解決類似問題？核心在于，產(chǎn)品負(fù)責(zé)人需要主動(dòng)規(guī)劃產(chǎn)品路線圖。

理想的情況是，版本規(guī)劃中的業(yè)務(wù)、產(chǎn)品需求 73 開，留 30% 時(shí)間用于產(chǎn)品創(chuàng)新。

最次的情況，即使只有 5% 為產(chǎn)品規(guī)劃，也不至于那么被動(dòng)。

遇到一些新的業(yè)務(wù)低價(jià)值需求，也能把當(dāng)前規(guī)劃完整列出，迫使業(yè)務(wù)方重新考慮需求合理性和優(yōu)先級。

3. 需求泛化

如果一個(gè)低價(jià)值需求，已經(jīng)進(jìn)入了版本排期，此時(shí)的產(chǎn)品是不是就躺平了呢？

面對這種尷尬的情況，一種做法是將需求泛化為系統(tǒng)能力，進(jìn)而滿足未來更多的需求組合。

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

什么是泛化？

即由個(gè)別的、具體的現(xiàn)象，提煉為普遍的、一般的。這種抽象的思維過程，叫做泛化。

那么需求泛化，指的是將適用范圍較窄的需求，擴(kuò)大為普遍、常見的需求。

例如小明喜歡吃香蕉、蘋果，那么原先一家只賣香蕉、蘋果和其他零食的小賣部，經(jīng)過一番裝修后，改為什么都賣的水果店。

產(chǎn)品案例：動(dòng)態(tài)收藏功能

舉個(gè)實(shí)際的產(chǎn)品案例。

某電商 APP 的產(chǎn)品，收到了運(yùn)營的“收藏動(dòng)態(tài)”功能需求。

假設(shè)動(dòng)態(tài)模塊僅占 APP 流量 3%，而該產(chǎn)品手上又有其他重要需求待做，這時(shí)該咋辦？

我們先從“覆蓋人群、使用頻率、研發(fā)成本”等維度，簡單分析下該需求的實(shí)際價(jià)值。

• 覆蓋人群：這個(gè)動(dòng)態(tài)模塊才占 APP 總流量 3%，而動(dòng)態(tài)收藏作為動(dòng)態(tài)的子功能，覆蓋人群更是低的可憐；
• 使用頻率：從動(dòng)態(tài)流量占比這個(gè)信息，可以推導(dǎo)出該模塊是電商 APP 的低頻功能，有條件的話寫個(gè)日志 SQL，就能算出使用頻率了；
• 研發(fā)成本：一個(gè)動(dòng)態(tài)收藏功能，正常的開發(fā)周期大致是 1~2 工作日。

經(jīng)過一番頭腦風(fēng)暴后，基本判定這個(gè)功能，雖然上線較快，但功能價(jià)值極低。

有這時(shí)間，還不如打幾盤王者呢~

開玩笑的哈，作為一個(gè)經(jīng)過專業(yè)訓(xùn)練的產(chǎn)品經(jīng)理，遇到類似需求，除了“需求記錄、版本排期”等方法外，還可以進(jìn)行“需求泛化”。

按正常思路來做，我們會根據(jù)運(yùn)營要求，直接設(shè)計(jì)、上線“動(dòng)態(tài)收藏”功能。

那如果進(jìn)行“需求泛化”，該怎么做呢？

抽象來看，該功能核心的能力是“收藏+對象”，按這種方案來做的話，當(dāng)用戶需要收藏更多內(nèi)容類型時(shí)，系統(tǒng)隨時(shí)支持相關(guān)能力復(fù)用。

那么，從更長的時(shí)間周期來看，原先的爛需求，搖身一變，就成了高價(jià)值需求的前奏。

上述方案的具體落地細(xì)節(jié)，需要掌握數(shù)據(jù)建模能力，知道一個(gè)功能依賴什么數(shù)據(jù)表，然后對它進(jìn)行魔改。

我們通過這個(gè)案例，簡單講了下需求泛化的大概思路，產(chǎn)品經(jīng)理要學(xué)會舉一反三。

那么你學(xué)會了嗎？