編輯導讀：在工作中很多產品經理都會遇到這種情況：千辛萬苦做好的功能上線後，前來驗收的運營卻説這個功能不是我想要的。明明這是按照運營的需求來做的，為什麼會這樣呢？本文作者針對這個問題展開自己的思考，希望對你有幫助。
相信不少產品經理都遇到過這樣的問題，在做原型設計的時候感覺功能已經很完善了，但等上線後，運營驗收的時候卻説這個功能不是我想要的，然後又提出一堆待優化點和新需求。你可能會疑問，當時是按照運營所提的需求來做的呀，但最後運營為什麼會變卦呢？
出現這樣的問題，主要原因是因為需求分析不準確，導致產品設計的方向跑偏了，所以最後做出來的功能自然不能滿足用户需求了。
筆者在入行前也曾多次遇到這樣的問題，當時只覺得運營的需求太善變了。時隔多年，自己也積累了不少項目經驗，今天就結合自己的經驗做下覆盤，分享一下個人感受（運營人員也是我們的用户，所以，以下文章均稱為用户）。
《代碼大全》的作者Steve McConnell報告説，產品60%的錯誤存在於設計中，而設計的錯誤60%的源於需求和分析活動。所以，能準確的挖掘到用户需求，對於產品經理來説是多麼重要的事情。
01 用户所説的未必是真的有一個説法叫“冰山理論”，它指的是一個人的“自我認知”就像一座冰山一樣，我們能看到的只是表面很少的一部分，而更大一部分的卻隱藏在更深底層，不為人所見，就像漂浮在海面上的冰山一樣。
用户的需求也像一座冰山，有很大一部分隱藏在海平面以下，只有很少一部分需求暴露在海平面以上。
有時候我們收到用户需求後，也按他們的要求做了，但上線之後發現所做的東西並不是他們想要的，或者説是不完善的。
這時候如果你如果質問他們“當時怎麼不説清楚呢？”，那他們就會反問你“你是產品經理，這些都是你該考慮的，我只負責提需求”。
這時候你應該責怪誰呢，是怪自己還是怪用户。事實上他們所提的需求只是他們已經意識到的，更深層次的需求隱藏在冰面下那些沒有意識到的需求，當然沒法告訴你了。
這就給我們的需求調研工作帶來了很大的困擾，這時候產品經理就應該從自己專業的角度上觸發，幫他們找到那些隱藏在冰面下的需求。我們經常所説的需求挖掘，主要就是找到隱藏在冰面下的需求。
所以，用户的需求分成意識到的需求、無意識的需求、進一步的需求三種。
- 意識到的需求：在海平面以上的需求，通常是一些困擾用户的問題，或者是用户自己能想到的功能。大部分產品經理在調研的過程中獲取到的都是這一類的需求；
- 無意識的需求：它是用户在實際工作場景中“沒有意識到的問題”，這種問題需要產品經理對業務有一定的理解才能發現。只有對這類場景能做到“感同身受”的話，產品經理設計的過程中才能夠設計出更合理、更高效的方案；
- 進一步的需求：對於用户遇到的問題，他們畢竟只是普通的工作人員，並不是技術專家。因此對於他們自己遇到的問題也沒有辦法提出關鍵的解決方案。因此需要產品經理對問題充分理解的前提下，選擇合適的實現方式以創造用户未想到的功能；
舉個例子，夏天的時候男生們都喜歡到操場上打籃球，打到中途口渴的時候一般都會到自動售賣機上買飲料。請問，對於打籃球的男生來説他們的意識到的需求是什麼？對，他們的需求是想喝水解渴。
那沒有意識到的需求是什麼？他們想喝水的目的，首先是因為運動激烈，水份消耗過快，所以想要喝水口渴。另外激烈的運動會讓身體產生大量的熱烈，他們想給身體降温。
那進一步的需求又是什麼呢？男生們出去打籃球往往是穿上籃球服，隨身帶着手機就出門了，但是打籃球總會弄着雙手，如果用手機支付的話就會弄髒手機，這時候如果這個售貨機能提供刷臉支付的功能，對於男生來説就是解決了他進一步的需求了。因為在刷臉支付技術沒有出現以前，他們是不知道不用手機也可以實現支付的。
所以通過這樣的場景設想，我們就可以整理出男生打球的過程中意識到的需求是喝水接口，無意識的需求是想要喝冰水，進一步的需求是刷臉支付。
02 如何抽絲剝繭，抓住真正的需求首先，我們應該把用户需求做個分類，只有將需求做好分類，我們做需求挖掘時才能有的放矢。
我們可以將用户的需求可以分成基本需求、期望需求、興奮型需求。
- 基本需求就是一個產品必備的需求，這類需求是即使用户不説，在做產品設計時也應該考慮的。
- 期望型需求就是用户期望做到的，一般是用户能比較清晰的知道的，一般是用户提出來的。
- 興奮型需求就是超預期的需求，一般是用户沒有意識到的，也就是隱藏在冰山下面的需求。
一個產品一般會經過導入期、成長期、成熟期和衰退期四個階段。
在產品的導入期應該着重滿足用户的基本需求。在產品的成長期應該選擇性地去滿足用户的期望型需求，並且完善原有的需求。在產品的成熟期關注更加細節方面的需求、體驗性的需求，以及挖掘其他隱性需求，也就是超預期的需求。產品的衰退期，這時候產品經理需要考慮怎樣去挖掘更多新的需求去滿足用户，甚至開拓新的產品項目。
那麼，我們應該怎麼去挖掘用户的需求呢？我們怎麼判斷他們所提的需求就是他們想要的呢？
首先讓我們先來看個例子，媽媽帶小明一起出門逛街，小明突然説“媽媽，我我渴了，想喝水”，這裏的想喝水是小明的基本需求。因為小明説的“口渴”是現狀，而水能解渴，應該順便給他買瓶礦泉水。
所以我們通過上面簡單的案例可以看出，需求分析的第一步就是邏輯推理。通過用户所提的需求進一步進行邏輯推理。小明“口渴了”案例邏輯推理就是：口渴—水能解渴—買礦泉水。
但是，如果媽媽給小明買瓶礦泉水真的能滿足他的需求嗎？不一定，那如果他剛出門才喝過水，剛一出門路過奶茶店就説自己渴了，那可能是他想喝奶茶了。如果給他買瓶礦泉水就不能滿足他的需求了。
所以，完全通過邏輯推理並不能他需求挖掘完整，也許還會出現錯誤的需求，我們還要加入情景分析才能挖掘出正確的需求。
綜上所述，我們可以將需求挖掘整理以上公式：
【什麼人】（角色）
【什麼業務場景】-【遇到什麼樣的問題】-【客户有什麼需求】
【現在是什麼樣的】-【期望的步驟】-【可選的解決方案】-【最終方案】
基於這個公式，我們在挖掘需求的時候，可以先在合理的範圍內，設定不同的用户和不同的場景，然後將不同的用户匹配到不同的場景，就像排列組合一樣，分析他們的目的。
03 聽取用户意見，但別照着做在通過各方收集到相應的需求之後，產品經理還需要懂得如何對需求進行管理。收集到需求的時候，注意建立需求池對需求進行記錄和整理。
我們在做產品設計時還有一個很大的誤區，就是全盤聽取用户意見，用户提什麼需求我們就做什麼需求。
產品的需求可以説是無上限的，大量的堆積需求，會使得產品非常臃腫，而且毫無特色，而需求的過多，還會導致工期過長，拖慢了產品推出市場的進度，對產品百害而無一利。
因此，產品經理需要了解產品的加減法。需求如何處理？在什麼時候需要加？什麼時候減？在需求收集階段，我們一直在做需求的加法，不斷地增加需求的量，增加所有能夠得到的需求。在進行需求分析、需求評審的時候，我們則需要不斷地對需求做減法，確認了需求之後，需要對需求進行優先級排序。減掉的需求並不代表這以後都不會使用，所以記得先保留着不刪。
我們應該聽取用户意見，但不要照着做。正確的做法是聽取各方意見，準確分析他們的需求和期望，結合各方意見最終做出最產品價值最合理的決策，這才是產品經理的職責所在。
我們應該緊盯我們的產品目標，對於產品目標有利的需求和建議就採納，對於產品目標不利的需求和建議就捨棄。
並且結合產品所處的階段對需求緊急程度進行排序，按時間週期實現分部實現產品目標，從而實現產品的價值最大化。避免出現在導入期緊盯用户期望型需求，成長期期緊盯用户興奮型需求的情況。
上面花了大量篇幅來講如何避免需求不準確導致需求設計失誤的問題，為什麼要花大量篇幅講呢？因為在前期控制失誤的成本和效率都要比事後控制容易的多。
回到標題，如果功能已經上線了，並且用户説功能並不是自己想要的怎麼辦？
需要分類討論，如果功能完全不滿足需求，並且與所提需求完全背離，這屬於產品經理的重大失誤，只能緊急停用，一切推到重來。
如果能部分滿足需求，可以申請延期發佈，等進一步改進後驗證通過再發布正式環境。
如果只是體驗不好，能基本滿足用户需求，可以上線後等待下一個版本去做迭代優化。
作者：青鋒，公眾號：PM知庫
本文由 @青 鋒 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。