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