在日常工作中，産品經理常常會遇到一些煩心事，被業務方牽着鼻子走，每天都在處理一些小改動，沒有發揮自身的價值。本文就來簡單聊聊，如何應對業務方提出的爛需求，希望對你有所啟發。
産品經理在日常工作中，總會遇到一些糟心事。
A 産品已經入行 1 年了，工作職責就是處理上級配置設定的小功能需求，認為功能來來去去就那些，畫原型已經膩了，完全沒有成長空間和業務價值。
而 B 是公司的産品老司機了，一呆就是 3 年，後來還成為了某條産品線負責人。問題是，所屬的産品部門在公司話語權很低，業務方說要做什麼就做什麼。
并且産品疊代節奏，完全被業務方牽着走，每天就處理他們提出的各種繁瑣問題，沒有任何個人的發揮空間。
你是否也遇到了類似“每天做些業務小改動，感覺工作沒啥價值”等問題呢？
今天我們就來簡單聊聊，如何應對業務方提出的爛需求。
一、如何識别低價值需求？
上述所說的爛需求，叫“低價值需求”可能更合适。
什麼是低價值需求？即投入産出比低的需求。
那如何才能識别它們呢？
可以從“戰略契合、市場潛力、商業價值、符合目标、覆寫人群、使用頻率、研發成本”這幾個次元，判斷一個需求的價值高低。
戰略契合：并不是什麼需求都必須要做，如果需求與使用者畫像沖突、年度戰略規劃不符，即使需求價值再高也不做；
- 市場潛力：相關需求的未來市場有多大？例如 iPhone 面世後，原先全球的手機使用者，未來将面臨更新換代的需求；
- 商業價值：通過落地需求方案，能直接、間接為公司帶來多少增量收入；
- 符合目标：通過産品專業的需求挖掘，確定業務方提出的需求，符合其業務目标的占比有多大；
- 覆寫人群：需要考慮有同樣需求的使用者，到底是什麼量級；
- 使用頻率：推測出每個使用者在一年中，遇到該需求的頻率；
- 學習成本：提供的方案，對使用者來說，是否能快速學會和易于上手；
- 研發成本：一個需求開發落地，所需要的工作日時間。
在日常工作中，接到新需求不一定都要考慮這麼多因素，你可根據實際情況，進行删減部分。
一些小功能需求，稍微考慮“覆寫人群、使用頻率、研發成本”也夠了。
二、應對低價值需求的 3 個方法
有些時候，即使是你認為沒有價值的需求，也有可能因為種種原因，成為了版本計劃中的高優先級需求。
那麼遇到這種情況，要如何處理？
一般來說，有以下三種方法處理：需求記錄、版本排期、需求泛化。
1. 需求記錄
面對業務的一句話需求，最好的應對方式是，及時記錄到産品需求池中，該調研該溝通的工作流程和友好态度，還是要有的。
但假設一頓操作後，發現這個需求價值太低、可有可無，或者業務方連最基礎的使用場景，都沒想清楚的話，那麼還是先在需求池待會吧~
等什麼時候業務理清需求的“必要資訊、使用場景”了，再處理也不遲。
2. 版本排期
産品團隊的疊代節奏，完全被業務方牽着走，更多原因在于産品本身。
由于産品負責人隻會疲于應付業務需求，完全沒有自己的産品規劃。導緻近期的版本内容，都是圍繞業務進行開發的。
如何才能解決類似問題？核心在于，産品負責人需要主動規劃産品路線圖。
理想的情況是，版本規劃中的業務、産品需求 73 開，留 30% 時間用于産品創新。
最次的情況，即使隻有 5% 為産品規劃，也不至于那麼被動。
遇到一些新的業務低價值需求，也能把目前規劃完整列出，迫使業務方重新考慮需求合理性和優先級。
3. 需求泛化
如果一個低價值需求，已經進入了版本排期，此時的産品是不是就躺平了呢？
面對這種尴尬的情況，一種做法是将需求泛化為系統能力，進而滿足未來更多的需求組合。
要了解什麼是需求泛化，首先要清楚泛化的概念。
什麼是泛化？
即由個别的、具體的現象，提煉為普遍的、一般的。這種抽象的思維過程，叫做泛化。
那麼需求泛化，指的是将适用範圍較窄的需求，擴大為普遍、常見的需求。
例如小明喜歡吃香蕉、蘋果，那麼原先一家隻賣香蕉、蘋果和其他零食的小賣部，經過一番裝修後，改為什麼都賣的水果店。
産品案例：動态收藏功能
舉個實際的産品案例。
某電商 APP 的産品，收到了營運的“收藏動态”功能需求。
假設動态子產品僅占 APP 流量 3%，而該産品手上又有其他重要需求待做，這時該咋辦？
我們先從“覆寫人群、使用頻率、研發成本”等次元，簡單分析下該需求的實際價值。
- 覆寫人群：這個動态子產品才占 APP 總流量 3%，而動态收藏作為動态的子功能，覆寫人群更是低的可憐；
- 使用頻率：從動态流量占比這個資訊，可以推導出該子產品是電商 APP 的低頻功能，有條件的話寫個日志 SQL，就能算出使用頻率了；
- 研發成本：一個動态收藏功能，正常的開發周期大緻是 1~2 工作日。
經過一番頭腦風暴後，基本判定這個功能，雖然上線較快，但功能價值極低。
有這時間，還不如打幾盤王者呢~
開玩笑的哈，作為一個經過專業訓練的産品經理，遇到類似需求，除了“需求記錄、版本排期”等方法外，還可以進行“需求泛化”。
按正常思路來做，我們會根據營運要求，直接設計、上線“動态收藏”功能。
那如果進行“需求泛化”，該怎麼做呢？
抽象來看，該功能核心的能力是“收藏+對象”，按這種方案來做的話，當使用者需要收藏更多内容類型時，系統随時支援相關能力複用。
那麼，從更長的時間周期來看，原先的爛需求，搖身一變，就成了高價值需求的前奏。
上述方案的具體落地細節，需要掌握資料模組化能力，知道一個功能依賴什麼資料表，然後對它進行魔改。
我們通過這個案例，簡單講了下需求泛化的大概思路，産品經理要學會舉一反三。
那麼你學會了嗎？
本文由 @好夕雷 原創釋出于人人都是産品經理，未經許可，禁止轉載
題圖來自Unsplash，基于CC0協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。