產品經理如何提升需求分析的能力？

01-02

需求是一個系統工程，涉及到需求收集，需求分析，需求開發多個方面的內容。很多時候互聯網行業把需求工程簡化了，那就談談互聯網產品下得需求分析能力提升涉及到的點。

1.你做的產品涉及不涉及到業務領域或業務流程，如果涉及到那麼先熟悉業務流程，基礎支撐是基本的流程分析和建模能力。至少能夠把業務流程所涉及的場景，崗位，角色，活動，輸入輸出描述清楚。

2.用戶行為分析，交互設計：基礎理論的書可以看幾本，更多的是多看別人的產品和網站，交互設計不僅僅是用戶體驗或易用性設計。更多涉及到基於場景或角色驅動的流程設計。

3.需求工程：不管是傳統軟體工程的需求規格，用例建模。還是敏捷下得User Story Card，都存在收集需求，整理需求，結構化和條目化需求，場景和流程描述，業務規則描述等基本內容。建議至少看一本需求工程方面的基本理論書籍。需求分析能力提升了，附帶的就是結構化思考和寫作能力提升，需要把需求能夠表達和描述的清楚。

理論流程

好幾個朋友讓我分享一下產品需求分析，我想了好久也沒發現有什麼可說的。這主要是我在工作中很少把需求分析當成規範性的操作流程，通常我都是在腦海里直接判斷需求，而且在絕大多數的公司里，也沒有規範的需求分析標準，常常都是由諸多因素直接影響並決定了需求。出現這樣的情況，也是職業屬性決定的，因為產品類的工作帶有很多主觀性因素。

既然要講產品需求分析，那麼就先要知道這在產品實現過程中處於哪個環節。無論是新產品還是迭代產品，首先由想法產生需求，然後需求彙集並分析，放棄掉不需要的，暫緩不緊急的，然後整理出需要下一步執行的，最終形成產品需求文檔並實施。

在彙集分析之前，需求的產生來自各個方面，由不同的人產生想法並表述反饋給產品經理，因此產生需求，主要來自公司內部(老闆、其他部門或同事)、產品經理自己(策劃、挖掘)、外部(用戶、客戶、夥伴)。

通過上面的梳理，我們就清晰的認識到，產品需求分析實際上就是需求決策。無論是自己的創新想法，還是市場調研，或者說來自其他方面的需求，最終彙集到產品經理手裡的需求分析，就是決策哪些要做、為什麼要做、怎麼做，同時也要給出哪些不能做、哪些暫緩做、為什麼不能或暫緩。

需求分析之前我們先要對需求進行分類，每個公司或產品都有不一樣的分類喜好，通常有功能類、數據類、運營類、體驗類、設計類等等，分完類之後再對需求進行權重考慮並決策。

需求決策有三個基本考慮因素，分別是戰略定位、產品定位、用戶需求。這是一個層級的關係，戰略定位決定了產品的位置，有些公司的產品在戰略上只是需要有這樣一個產品，也僅僅是需要有，有不代表非要做好，既然不要做好，也就不會有大的資源投入，更談不上需求的迭代，所以戰略定位是首要的需求決策因素。其次是產品定位，產品定位決定了哪些需求是必要的，哪些需求是多餘的，同時也影響著用戶需求的取捨。

基於三大考慮因素，我們對需求進行了篩選，之後還需要進行分位，即使用「四象限定位法」進行需求分位，將需求劃分成「重要又急需、重要但不急需、不重要但急需、不重要也不急需」。分好位之後，我們再對需求進行分級，也就是優先順序，標註需求的優先等級，規劃並決定需求的執行計劃。

通過上面的理論流程，我們可以大致的對產品需求分析有一個全貌的理解。簡單直接的介紹就是說產品需求分析是一個產品決策過程，通過對需求的分類、篩選、分位、分級的四步流程之後，決定需要執行的需求，將其規划到執行計劃中。

需求分析和判斷

大致的介紹了產品需求分析在產品實現過程中的位置和分析的方法。但是在很多公司，需求分析並決策是一個很快速的流程，特別是瀑布開發模式的公司，不會將太多精力放在需求分析上，而是在產品策劃的過程中就直接對需求進行了分析並決策，這樣可以大大減少其他工作人員的閑置。在大公司或者產品擁有眾多決策對象的時候才會細化並單獨進行需求分析，其餘往往都是產品經理直接決策。

產品需求分析是在需求產生之後、產品實施之前的一個中間環節，他有很多工作是和產品策劃重疊的，因為絕大多數的情況下，需求分析和決策在策劃的過程中就直接完成了，所以需求分析的工作往往出現在產品迭代過程中。新產品進入迭代周期之後，會收到各個方面的需求反饋，這個時間就會出現很多需求，因此就需要對需求進行分析和判斷，決定需要實施的需求。

通過上一篇介紹的理論流程，我們清晰了需求分析的流程方法，第一步我們先要對需求進行分類，通過分類我們可以清晰的認識到需求的重要程度。對需求分類也是考驗我們產品運營知識的一個機會，例如微信公眾平台的服務號從原來的每月1條群發信息調整到每月4條，這個實際上屬於運營類需求，再例如微信公眾平台服務號支持微信支付，這個策略看著像運營類需求，但實際上應該屬於功能類需求。

對需求分類之後，我們就要對需求進行分析和判斷，主要考慮因素有三個，分別是戰略方向、產品定位、用戶需求。

戰略方向是一個很宏觀的方向，這個方向沒有明確的界線標準，但是可以給我們一個參考範圍和目標，在實施的過程中又細化成各個階段，在每個階段里需要實現的目標又是不一樣的，因而需求分析和判斷的時候，就要取捨決策。常見的戰略階段分別為起步階段、發展階段、迭代階段。在起步階段的時候，注重核心功能的實現，快速推出市場驗證產品的可行性；到了發展階段就會進行功能擴展和完善，在這個階段也會小範圍的進行試錯實驗；到了迭代階段的時候，產品基本已經成熟穩定，需求就會更加註重用戶體驗方面。

在各個不同的戰略階段，需求決策的標準是不一樣的，起步階段可能為了快速實現產品，所以在核心功能之外的需求會被放棄或暫緩。例如微信要構建閉環的商業生態圈，但這個工程不是一步能完成的，所以分階段進行，每個階段的重心就會不一樣。第一階段需要先完成場景布局，所以推出朋友圈、公眾平台，先將點對點的微信改造成有維度的社交圈；第二階段開放定製介面、內推微信支付，構建商業藍圖吸引更多參與者；第三階段升級服務策略、開放微信支付，放開許可權提升各類常見模式的實現方法，完成閉環的可能性。

戰略分階段，階段分版本，通過這樣細化需求標準，決策每個版本需要實現的核心是什麼，其中需要考慮產品定位、用戶需求和當前的環境，從而決定需求分析和判斷的標準。這些說的可能有些虛，沒有實在的案例支撐，所以聽著也暈，並且很多公司里，產品經理很多時候是沒有最終決策權的，這也是一個尷尬的職業處境。但是我們需要明白，再偉大的產品，都不是一口吃成胖子的，都是有階段性的發展和提升，我們需要找准每個階段的需求重心。

通過戰略因素，我們認識了需求決策要參考階段規劃，並不是所有「有用的需求」都要一次實現，這一點需要我們擁有項目管理的一些常識，更多的需要經驗積累。

產品定位和戰略方向是有一些重疊因素的，但是戰略方向更偏向於市場，而產品定位更注重功能定義，所以產品定位的考慮因素是判斷功能需求是否符合產品定位的標準。例如地圖APP是一個LBS模式的POI導航服務的應用程序，如果有一個顯示路況信息的需求，那麼這是符合定位內的需求，可納入規劃中按計劃實現，但是如果需求是希望實現Web版離線地圖下載，那麼這個需求和產品定位以及運營策略是不符的，就沒有必要納入規劃。

戰略方向和產品定位都是策略型因素，考慮的思路也是主觀性的，但是用戶需求這個因素就是實實在在的訴求點，但是用戶的需求也不全部合理，也要考慮公司的戰略和產品的定位，正如上一段提到的Web版離線地圖下載，就不符合公司策略。既然用戶需求是實實在在的訴求點，也就有了更加可挖掘的方法。

用戶需求的思考我們需要注重兩個方面，分別是「不把需要當成需求、不把產品形態當成本質」，我分別也有兩個案例供大家參考。

不把需要當成需求：好幾個朋友讓我分享一下產品需求分析，這實際上是他們需要的，但不是他們真正的需求。用戶往往在表述需求的時候，因為各種原因或因素，沒辦法認識到真實的需求，也就會把需要當成需求表述出來，但實際上他們的需求是希望我能分享一下「產品需求」產生之前如何挖掘和策划出需求，而不是產生之後的分析決策。

不把產品形態當成本質：正如我前一篇章的《萬能的產品策劃公式》中介紹到的行李箱策劃流程，行李箱是產品形態，但不是產品本質，產品的本質是大眾人群在出行中攜帶的一個物體，根據本質我們需要改良用戶攜帶物體所遇到的麻煩。

通過需求分類後，我們再結合「戰略方向、產品定位、用戶需求」這三個因素，對需求進行篩選，最終再根據工作計劃對需求進行分位和分級，制定各個階段和版本的需求文檔。

需求分析和判斷是一個關聯性的思考過程，篩選、分位、分級都需要結合三大因素以及其他因素一同參考並判斷，這需要我們擁有宏觀的思維能力，並且也要有足夠的定力，避免發散性思維產生的誘惑讓我們偏離最初的戰略方向和產品定位。

分析文檔/報告

在文章之前先分享一個思維導圖，由草榴網產品經理「小福子」針對前兩篇文章整理的一個思維導圖，結構化的羅列了我的文章內容，如下圖所示：

需求分析和判斷之後，我們需要寫一份報告文檔，將需求的處理結果呈現給領導或其他同事，這和我們策劃產品後要寫一份策劃方案是一樣的，通常這樣的文檔都是PPT形式，以大綱加上演說的方式表述方案。

PPT文檔的大綱應當包括以下幾點內容：

1、需求分類：將需求以需要的類型分門別類的羅列好，並介紹清楚需求本意。

2、需求分析和判斷：在這個部分介紹各個需求決策結果，將可行性需求留下，不可行需求放棄；通常這個部分只介紹放棄的需求和放棄的理由。

3、需求分位：將可行性需求進行分位表述，表明需求的輕重緩急，這個分位的決定因素有很多，需要參考三大因素進行評估；四象限定位法在普遍的公司里也會這樣稱呼，重要(緊急)、重要(不緊急)、不重要(緊急)、不重要(不緊急)。

4、需求分級：根據分位再分優化等級，將需求劃分計劃，根據不同規劃階段分多個版本實現；如果需求很少，那麼就一次性迭代實現了。

通過PPT的展示和演說，就能詳細的報告了產品需求分析的結果。

因為我都是在產品策划過程中就完成了需求分析和決策，所以沒有單獨的產品需求分析報告，也就沒有案例下載了，以後如果有了我再在博客中分享給大家。

本文框架如下:

從一則小故事談需求從前有一個國王，國王有個極其嬌慣、任性的公主，這個國王又無比寵愛這個公主，不管這個公主有什麼願望，國王一定滿足。終於有一天，公主說：「父王，我要月亮!」，於是國王叫來一個臣僕，說把月亮給我女兒給摘來，不然我就殺了你，臣僕欲哭無淚，最終被國王殺害，接著叫來另一個臣僕，也無奈之憤憤而終。在公主的哭鬧下，臣僕一個個死去，終於輪到了一個聰明的，他接到任務後，來到公主前謙卑的問：「親愛的公主啊，請告訴愚昧的臣僕，月亮是什麼啊?」公主不耐煩的說：「月亮是什麼你都不知道!月亮就是用金子做的，如手指蓋般大小，彎彎的，晚上就會掛在我窗前的樹枝上啊，白天不知道被誰偷走了。」此臣僕暗喜，照此炮製，逃過一劫。

對於產品經理而言，從這則小故事我們可以反思：我們真的了解用戶需求嗎?還是有時候會陷入主觀臆斷的泥淖—「我覺得產品的這個功能很實用，直擊用戶痛點」，往往我覺得並不等於用戶也覺得，產品經理可以有自己的主張，可以非常堅持，但是不可以只活在自己的世界不在乎用戶的聲音和身邊的建議。產品是以實現用戶價值為核心概念的，產品經理自然要傾聽用戶的聲音，確認是否實現了用戶價值。對於身邊的建議,也要注意學習和吸收，不要切斷產品和自己的上升階梯。

何謂需求？

最基本的需求，即「食色性也」，「食」是為了生存，保證個體延續，「色」是為了繁衍，保證種族延續，這是生物（包括人）的本性。1943年，由美國著名猶太裔「人本主義」心理學家亞伯拉罕?馬斯洛提出了需求層次理論，由此將人的需求分為五個層次，由低到高分別是：生理需求、安全需求、社交需求、尊重需求、自我實現需求。

人類生活在地球上，為什麼會有各種各樣的需求？那是因為生活中存在太多的問題，從而產生了不滿意，而問題就是「理想與現實的差距」，那麼人類會很自然地產生「減小甚至消除這個差距」的願望，這就產生了需求。我們之所以做一個產品，肯定是為了解決某些問題，滿足某些需求，而這些需求深挖到底，多問幾個為什麼，總可以歸結到馬斯洛說的那幾個層次里。

需求採集的方法

1.用戶訪談

用戶訪談通常採用訪談者與被採訪者一對一聊天的形式，一批用戶訪談的樣本比較少，一般是幾個到幾十個，但在每個用戶身上花的時間比較多，通常為幾十分鐘到幾個小時，圍繞幾個特定的話題，我們問，用戶答，用戶說，我們聽，這是一種典型的定性研究。用戶訪談可以了解用戶怎麼說，即他們的目標和觀點。

2.調查問卷

調查問卷和用戶訪談的提綱是有區別的：用戶訪談的提綱通常是開方式的問題，適用於我們心裡比較疑惑的時候去尋找產品的方向，適合與較少的訪談對象進行深入的交流；而調查問卷通常是封閉式的問題，適合大用戶量的信息收集，但不夠深入，一般只能獲得某些明確問題的答案。無論是網上的還是線下的問卷，作答時間最好不要超過5分鐘，否則很多人看一眼就嚇跑了。

3.可用性測試

可用性測試是指通過讓實際用戶使用產品或原型的方法來發現界面設計中的可用性問題，通常只能做少數幾個用戶的測試，看他們怎麼做，屬於典型的定性研究。

4.數據分析

數據分析時，根據目的的不同，數據來源多種多樣，常見的有用戶使用產品的日誌、客戶管理系統里的信息、網頁訪問情況的統計信息等。數據分析的方法，最簡單的可以用Excel，複雜一點的可以用一些統計軟體、資料庫軟體。最關鍵的就是對結果的解讀，通常數據分析只能發現一些現象和問題，並不能了解原因，所以分析完成後通常會伴隨著一些用戶訪談，聽聽用戶怎麼解釋。

需求分析的方法

1.要會做減法

初始的需求調查和需求收集雖然是有目的性，有針對性地去收集，也會反饋回來大量的需求數據，更別說無目的性的收集需求了。不過有數據總比沒有數據強，需求分析要做的就是從這些林林總總的需求當中找出可實現的，有價值的需求，排除那些無意義，不可實現的需求，或者是當前暫時先不實現，或者是這個產品不實現但可以利用在別的產品身上的，反正與當前產品無關的需求，都需要排除掉，這個過程就是在做減法。需求分析要根據產品的願景，設計理念等去捕捉到有價值的需求，這個篩選的過程是圍繞著最終實現的功能去的，並不是胡亂篩選。比如說，我們收集到10個功能需求，覺得其中有兩個是沒必要做的，或者是可以以後再做的，就把這2個需求功能先排除掉，先做剩下的8個功能需求。

2.要會做加法

當收集到的需求數據無法滿足現有產品的設計時，一種方式是重新做一輪需求調查，一種方式是靠產品經理的能力去找出新的需求來完善產品的設計，後一種方式就是做加法的過程。產品經理依靠自身的工作經驗，和對產品設計理念的理解，可以提出新的需求，這些新的需求不一定就是最終的需求，但產品經理要有能力去總結髮現。因為往往人們在考慮問題的時候都是不全面的，所以才古語有云，三個臭皮匠頂個諸葛亮，把所有的意見綜合在一起，很有可能就是個非常棒的點。

3.Digg挖掘

當我們面對一件全新的產品設計任務時，沒有任何現成的數據去提供給我們做分析，或者說數據很少，這個時候產品經理要去挖掘需求，也可以說是發現新需求，這個新需求是全新的，沒有任何經驗可借鑒的。比如說輕博客需求，在此之前沒有一種產品形式可以以微博的形式分享音頻，視頻等富媒體。這個挖掘的能力需要鍛煉才行，經常關注一些事物的本質，經常問為什麼，經常去分解現有產品所提供的服務。

滿足需求的方式

我們通過產品需求來滿足用戶，順著這個思路，就是要做一些用戶真正需要的功能或服務，雖然這是最常用的辦法，但也是最「勞民傷財」的。在甩開膀子幹活前，我們有必要擴展一下思路，從問題的本質出發，尋找新路。

需求來源於理想與現實的差距，那麼減小這個差距就有三種方式：

提高現實┃降低理想┃轉移需求

舉個簡單的例子：

某寫字樓可能因為建造比較早，考慮不周，電梯數量明顯不夠，每天中午吃飯的時候總是很擠，最上面幾層的小白領們平均要等20分鐘才能下到3樓得餐廳吃飯，於是抱怨很多。其實我們可以按照以上三種方式分析一下。

提高現實┃ 對現有產品做一些改進，在這個案例中就是增加電梯數量，或者加快電梯的運行速度，但成本太高，直接被否定。

降低理想┃ 告訴樓里的小白領們，隔壁那個寫字樓中午要等40分鐘呢。俗話說「不患寡而患不均」，人們更在意的是相對的而不是絕對的，這樣確實可以減少抱怨，但是是一種低水平的滿足要求，對產品美譽度沒有幫助，要慎用。

轉移需求┃ 電梯門上貼一些健身鍛煉的廣告，當然內容是說爬樓梯有益身體健康。有效，部分用戶走樓梯去餐廳了，但是剛吃過飯怎麼辦？爬十幾層樓梯要得闌尾炎的。最後，採用一個看起來很傻的方案，在電梯門旁邊安裝一面鏡子，讓等待的人們可以整理一下儀錶，或者搔首弄姿一番，不至於那麼無聊。

所有這些，都是想告訴大家，滿足用戶需求，不一定要做新產品或者新功能，而是更應該想想是否有「四兩撥千斤」的妙招。

關於需求分析，我新寫了篇文章，主要關注點在於商業分析之後的功能分析，貼一下，供參考：

撇開項目範圍和功能商業價值（也就是說該單項功能已由多種渠道證明，如果做得好會有很多用戶使用），我來整理下我是如何從產品設計的角度，衡量一個功能是否做和如何做的（排名有先後）：

一、是否符合網站整體定位

網站整體是針對高端用戶的，還是針對屌絲用戶的？是針對一線城市的，還是主打二三線城市的？是主要編輯采編內容的，還是主要依靠UGC的？是主要做B2C的，還是主打SNS的？等等等等。。

二、對參與用戶的鼓勵性：

簡單來說，就是

1、反饋的有效性。使用了這個功能的用戶，他會得到什麼。是具體的實物（包括積分）獎勵，還是虛擬的炫耀性展示獎勵？這樣的獎勵，是否足夠大到讓他覺得付出都是有價值的？或者說，是否超出了他的預期？是不是下次還會樂滋滋的去使用這個功能？

如果沒有得到獎勵，能不能得知為什麼不能得到獎勵？這個理由是否足夠令人信服？能不能提供頁面供他修改或更新，重新申請獎勵？

2、反饋的時效性。他在使用了這個功能時候，多久可以獎勵？

或者，沒有得到獎勵，他會多久得知沒有得到獎勵？

這裡插個題外話，最近很火的Instagram，大家在討論該應用交互很快，有什麼奧秘么？其實，秘密有兩個：

a，頁面交互和數據傳輸的分開。比如，你贊了某張圖片，馬上就會在你的手機上顯示出來，但是這個點擊操作的數據傳輸仍然在後台運行。

b，數據的提前載入。比如，新用戶尚在在註冊流程時，Instagram已經在載入註冊完成後首頁的圖片了。。

其實第一種做法不新鮮，幾年前王堅的糗事百科就用了這樣的機制。第二種沒聽說過以前有用過，這對於數據挖掘很考驗功力。

3、展示的廣泛性。某用戶使用了該功能，包括通過該功能獲得的獎勵，會在多大的範圍上被其他用戶知曉？如果是炫耀性的功能，會不會被更多的用戶看到？是會被進入首頁的用戶看到，還是只有在該頁面的用戶才會看到？如果是私密性的功能，能不能做到只有用戶自己才能看到？

三、對非參與用戶的吸引性：

其實和第二點相輔相成。

四、交互的簡潔性：

1、和現有功能是否有衝突或重複？對於信息或功能的整理，有四種方法：合併，刪除，組織和隱藏。對於討論一個新功能，要明晰是否和現有功能在邏輯上有衝突，比如發表一篇文章在原頁面是送100積分，在現有新頁面就是200積分。如果沒有衝突，繼續考慮是否有重複。是否可以合併到現有的某個功能中？或者在現有功能的某個交互步驟才顯示？

2、用戶操作的簡潔性。讓用戶點擊一次滑鼠的操作比點擊兩次的功能有價值。如果做一個讓用戶投票「最想看某個產品的評測」的功能，在第一布讓用戶只要點擊下某個產品下的「選擇」就行了。判斷登錄和留下郵箱發送評測的步驟，可以放在點擊之後再然給用戶選擇輸入。

五、運營的後續性

1、新作了某個功能，是否會極大的加大現有同事的工作量？這種加大工作量是否是短期的，只是由於新功能不熟悉和用戶好奇心導致的？如果是長期的，是否有足夠的人手可以補充？

2、新作了某個功能，是通過用戶輸入口提交信息，還是下拉框讓用戶選擇提交？前者自主性更大，適合無需對輸入的內容做後續運營的，但是數據整理上會加大工作量。後者適合收集資料做數據分析和判斷，但是對於選項的MECE原則要求高。各有優劣。

六、投入產出比

這個很好理解，投入的產品設計前端開發資源，和最終效果的收益估量。其實如果把上面五點都討論清楚，這一點的答案會顯而易見的。

。

所以，別再說產品端做事慢，因為我們想的多。

寧願把時間花在需求討論的扯皮上，也不要把精力花在功能效果不好的互相埋怨上。

原文鏈接：http://raywang1124.diandian.com/post/%E8%A1%A1%E9%87%8F%E5%8A%9F%E8%83%BD%E4%BB%B7%E5%80%BC

自己是產品的用戶

當客服

謝邀

先上觀點：需求的本質是利益訴求，做產品的本質是利益的再分配。

需求一般是有三層的表達

1. 用戶期望

這是用戶最直觀表達的內容，包括對現象的吐槽，或者說我要XX功能等等。

2. 用戶需求

產品經理會根據用戶的需求，挖掘需求場景，提煉出需求和場景類似於「XXX在XX情況下產生了XX需求，需要XX來滿足」等等。

3. 利益訴求

這個是最最核心的關鍵點，通過場景化的語言描述需求，仍然停留在表面，更重要的是挖掘其中的利益訴求點，並通過產品來這一形式來進行利益的再分配，通過互相滿足多方利益訴求，來形成產品核心競爭力，這在產品統籌規劃階段是最為重要的。

然後舉個需求分析的小栗子

小A是業務方同學

小P是一個產品經理

// 在一個風和日麗的下午，小A和小P開始了一段愉快地扯淡。

小A：P啊，最近我想搞個東西，我想在監控頁面上加一個流量看板，能每天看進來訪問用戶的狀況的那種。

小P：這事兒簡單，我找研發對接一下，你把要看的數據給我就成啦，保證3天整完。

這個就是基礎的用戶期望直接對接成需求，一般在新晉產品經理對接需求時發生。

// 過了兩天小P想了一想，又來找小A

小P：A啊，上次那個需求我回去和研發哥哥聊了之後，有些點還想問問你，這個需求是怎麼來的？是什麼場景下要用到這個需求啊？

小A：哦，這呀。因為我們平時用監控的時候要看看流量的進展情況，如果發現問題我們可以及時修正下運營手段。

小P：哦了，場景收到，我回去再和技術說說，爭取這兩天搞完。

不僅僅是收到要求，更進一步挖掘了使用場景，了解了需求的來源，這是我們做進階在需求分析時常用的手法。

// 過了一天小P又哭喪著臉過來了

小P：A哥啊，真對不住。上次我回去和我老闆彙報了這事兒，老闆把我批了一頓。說這事兒對業務的價值都不明確，就這麼心急火燎的要上不合適，A哥一定得救救我。

小A：唉，這事兒是這樣主要現在我們在這個模塊取數不及時，不能很快發現問題，希望監控能提供實時數據，這樣我們只要有人看著，就能快速發現問題了。

小P：所以這件事兒的目標是希望能在運營過程中通過數據監控快速發現問題咯？

小A：是呀，這樣我們才能提升運營水平，還能提高一些問題響應效率呢。

小P：哦，那如果系統能直接發覺問題推送到業務那是不是效率能更高呢？

小A：那敢情好呀，能搞不？

小P：恩，這事兒對業務價值比較大，可以一步一步來，先把數據打通，然後通過模型判別來挖掘異常事件出來，通知到運營，這是一個產品亮點，可以給業務帶來很多價值吧。

小A：那必須的。

小P：那我回去好好整整，這事兒有點意思。

給用戶帶來的價值導向，而且這件事兒所能帶來的價值是多重的，不僅是業務更是新的業務管理嘗試，一個好的產品方案往往能帶來更大的效率提升和多方的價值體現，這是需求分析最重要把握的點。

需求分析需要精密的邏輯思維能力和全面的思維體系，這可以幫助產品同學快速挖掘多方價值，最終達成快速產品落地形成可用方案。

以上

產品經理的工作是圍繞著需求來進行的。產品經理日常的工作有：拍腦袋想需求，與用戶溝通了解痛點在哪裡，進行需求評審，寫需求文檔、畫原型圖等等工作。產品經理一直做著需求相關的工作，那麼應該如何正確地處理需求呢？在產品這條路上，經過多次的挖坑填坑，我認為應該這樣處理：

首先，先說明一個問題：一個產品，從前期的需求產生，到最後的產品成型，不管你前期的用戶需求把握得多準確，原型圖畫得多漂亮，最後開發人員開發不出來，那也是白搭。所以，有關需求評審等會議需要有項目經理的參與，項目經理進行技術評估，再確定需求，這樣才能保證需求提出後能夠很好地實現。

需求的來源：

老闆，老闆是負責戰略層的事務，在確定了產品的方向之後，他會對產品的樣子有個大致的想像，有些功能是必須要有的，這時候，他會和大家討論哪些需求建議加上去。
產品經理，在造就產品的過程中，老闆和核心層人員已經把戰略確定，接下來就是範圍層具體的需求確定。產品經理需要進行基本的競品分析對比、收集各方面的數據，然後分析得出需求有哪些。
產品運營，產品設計出來是給用戶用的，而最接近用戶的是產品運營人員。那麼，不管是一個產品最初的誕生以及迭代，產品運營人員都應該做用戶訪談，去獲取用戶的痛點，用戶用得不爽的地方有哪些，然後列一份需求清單給產品經理進行反饋。
UI、UE、以及開發人員，業內有句話叫做「自己做的產品自己都不想用，用戶會用么？」所以既然自身要設計以及開發，那麼你肯定希望你的工作是有價值的，希望能盡全力去做好這款產品，如果意見能被採取，那麼設計以及開發人員工作起來會積極很多，這樣能讓產品經理和他們更好地溝通起來，產品也會更完美。

需求的確定：

當老闆、用戶、產品經理、設計以及開發人員和你提需求的時候，記得給他們一份需求清單，讓他們將需求填寫上去，然後匯總到產品經理這裡，產品經理把以上的需求清單整理在一起列成表格，以便在會議上進行統一探討。會議千萬記得要求項目經理參加，向產品經理提供需求清單的人也盡量參加，以便更好地探討。會議上產品經理作為主持人，在介紹完產品背景以及產品戰略上的信息後，就正式進行需求的評審。評審之前，先在小黑板上畫出表格如圖

先列出需求，然後先讓提出此需求的人說下提出此需求的原因，然後進行投票，

認同：指的的關於產品需求，這個需求你也想到這個需求，和提出者想的一樣
贊同：之前你沒想到有這個需求，但是經過他人提出後，你很贊同，在使用這個產品你會需要這個功能。
不贊同：之前你沒想到這個需求，雖然經過他人提出，但是你不贊同，在使用這個產品你不需要這個功能。

在思考的過程中，強調給出意見之前，站在你是一個產品小白用戶的角度上，你會不會有使用這個功能的需求。 如何投票確定需求，打個比方：

會議共有9個人，有個需求進行投票表決，每個人只能投一票。
認同人數加上贊同人數加起來大於三分之二，那麼這個需求就確定必須加。
認同人數加上贊同人數加起來大一三分之一，那麼這個需求待確定，參會人員重新進行討論，站在小白的角度上說出各自的意見，重新進行投票，此刻投票只有贊同以及不贊同兩種，贊同人數超過三分之二，確定此需求，反之，則放棄。
認同人數加上贊同人數小於三分之一，那麼這個需求直接放棄，大家和需求提出者說下不贊同的看法以及意見。

需求的總結： 會議結束的過程中，需要專門有人在旁做會議記錄，把會議過程以及最後的決策記錄下來，會議後轉發給參會人員，很多時候，記憶總是不如文檔來得實在。匯總的需求在會議上就已經處理好，那麼對於老闆特意提出的需求，你需要給一些詳細的反饋了。如果老闆也一起參加會議，大家可以和老闆一起討論，很多時候老闆提的需求會得不到大家的認同，是因為你沒有老闆的大局觀，老闆提的需求大部分還是對的（前提是這是經驗豐富、靠譜的老闆，其他另說），他可以通過他的理解給大家解釋，也能說服大家，所以有關老闆需求，會議上就能有結論。如果老闆太忙沒有參加會議，老闆提的需求通過後，在最後的需求確定都會有一份需求總結，抄送給他就可以，如果老闆需求沒通過，那麼你需要在會議上把大家的意見和想法以及論據等等，都一一列舉出來，給老闆進行解釋，為什麼這個需求沒通過，以及大家的意見都是怎樣的。老闆認為這個需求很有必要加，但是大家通不過，那麼只能再開次會議，速度解決這個需求的決議。最後一點，就是項目經理在會議的過程中，他是有一票否決權的，在需求的產生後，就已經涉及到了後期的功能開發，如果太過天方夜譚無法實現的需求，項目經理以純技術的角度，當場就可以進行拒絕，老闆需求也可以拒絕，任何一個需求得不到實現，那麼這個需求是沒有意義的。

經常出現的問題：

1、有時候開發人員對有些需求表示不理解的時候，經常看到有產品經理和開發人員這樣解釋：這是老闆要求加的需求，沒辦法。這句話意思是什麼？

第一，我也認為這需求不靠譜
第二，他是老闆，他要加我也沒辦法。

這句話突出了一個產品經理的無能，試問一個老闆請你來做產品經理，你是專門用來做他的傳聲筒，還是用自身的經驗看法，來用心打磨優化一款產品。而且，開發人員也會認為你無能，在後期的溝通過程中，勢必會有更大的阻力。 2、有時候產品經理拍腦袋想出的需求，然後後果一般是這樣的：設計、開發人員在設計的過程中，設計師設計著頁面，一邊想著，這玩意，給我我也不用，開發人員擼著代碼想著，這傻逼功能，誰會用啊，浪費我這麼多時間做這種功能，這產品經理... 可想而知，產品經理和設計、開發人員在溝通上，會碰撞出什麼樣的火花。需求是產品經理繞不過去的坎，作為產品經理都應該儘力去把需求想好、處理好。

我所舉的也只是一個簡單的處理方法，有其他更好方法的可以和我交流探討。

1.變成問題青年--為什麼總掛在嘴邊，問別人，也問自己

2.開放的心態--得到的結論，看到的結論，不要當成真理，結論總會變的，而且很頻繁

3.同理心--真心的站在別人角度上想問題，練習從現象分析到本質，逐步就能從細分人群的共同本質推測出現象了。

比如，你能分析上海的農民工喜歡怎麼消磨晚10-12點的時間么？為什麼？

需求分析的過程

1. 工作流程

（1）用戶分析

通過用戶生活形態分群的方法，按照用戶的價值觀和生活形態特徵，對用戶進行分群，形成具有典型性的細分群組，並且總結提煉出該群組用戶的一般特徵，清晰定位目標市場與目標用戶群體，指導產品開發和創新。主要解決目標用戶是誰，市場預期容量有多大的問題。

（2）需求挖掘

根據上一階段選定的目標用戶群，進行抽樣研究，通過記錄某一特定類型用戶的生活場景或業務使用體驗（見圖3-3），洞察用戶的典型行為或生活習慣，了解他們在特定場景下的需求，結合企業自身的能力，拓展業務創新的空間。

圖3-3　用戶需求場景研究示意圖——「白領的一天」

（3）需求驗證

在定性挖掘用戶需求碎片的基礎上，要通過定量的調查從兩個方面對需求進行驗證：首先，要驗證需求的普遍性，目標用戶群中是否大部分用戶都有類似的需求；其次，要驗證需求的迫切性，目標用戶群中大部分用戶對需求的排列順序。經過驗證排序後的需求，就可以作為用戶需求的最後輸入。當然，要最終成為產品需求並且轉化成產品功能，還需要從其他幾個方面進行分析和篩選，在此就不詳細介紹

作為產品經理，最大的痛苦可能就是產品需求的管理，既要廣泛的聽取用戶和小夥伴們對產品的意見，又要不時地應付老闆突如其來的奇思妙想。而這些還只是需求的收集，還有需要評審的，評審中的，評審過了等待開發的，開發完成了的等到測試的等等。此外還有版本的管理，bug的管理等。如果沒有對需求進行很好的管理很有可能造成工作上的疏漏甚至是產品重大功能的缺失，所以對需求的有效管理勢在必行。

第一步，廣泛的收集需求

#截圖來自teamin示例，略有修改，下同

需求的收集不是越多越好，但是在不知道是不是必需的時候全部搜收集過來，從裡面找到符合產品定位和功能需求的也不失為一個方法。把收集到的需求用列表的方式列出來，列的時候可以採用標籤的方式標明需求的來源，方便後期的管理。

第二步，需求分解

在把所有的需求列出來後，需要對收集到的需求進一步進行分解細化，比如常見的註冊登錄功能，用戶可以使用那些工具進行註冊，註冊完成後後可否與第三方賬號綁定，登錄時可以用那些方式進行登錄等這些都是需要產品經理去考慮，而且需求的粒度劃分的越細，對於後期開發的實現難度就越低，換句話說產品更容易做成功。

第三步，需求計劃安排

對收集到的需求進行評審，是否採用，採用的需要在哪個版本里實現，並將評審通過的需求添加到相應的實現產品版本里，沒有通過的放在另一邊。通過評審的需求可以指定不同的執行者來負責這條需求的最終實現，也可以給需求制定截止時間並通過添加標籤的形式來標明需求的重要緊急程度，以示區別。

第四步，需求跟蹤

需求評審通過後，需要技術哥哥去開發實現了，需求的開發進展是怎麼樣的呢，這個可以通過看板的方式來實現。這個流程也是可以自定義的，添加你認為是必須的環節，比如測試驗收，產品驗收環節等。通過這個看板，需求甚至是整個產品的進展一目了然，再也不用為紛繁複雜需求感到頭疼了。

看到這裡是不是發現產品的需求管理其實也沒有那麼難？

今天開會才跟小夥伴們吹完。

很多答主是講的具體的技術，我來吹吹水，講個「道」方面的東西。

其實要做好一個產品，最核心的素質有這些。

1. 好奇心

好奇心，就是指人對身邊各種事物，各種東西的好奇。吃的飯，走的路，做過的車。用過的任何一個網站，軟體，手機應用，出門看到快遞員，飯店收銀員手裡持有的專門設備，新問題，展會上看到的新技術的新應用。這些東西，都嘗試去關注下，了解下，學習下，分析下。

人類其實是無法想像完全沒見過的東西的，大部分情況下都是根據曾經見過的東西拆分組合。那麼儘可能提高自己的知識庫，會讓自己的設計的時候有更多的靈感，有更大的素材庫，去設計出更加好用的東西。

2. 主動設計

當你碰到一個設計，或者去了解別人需求，分析別人需求的時候。先不要急著去問別人，去聽人講。這樣很難聽明白。因為任何一個職位，所做的事，都是要經過很多學習，大量的知識做儲備才能夠正常工作的。那麼作為一個外行，怎麼可能聽人說一下就搞清楚別人到底要什麼？

每一個產品，後面所對應的業務邏輯，都是一個由很多知識點構成的網。如果一次性的去接收別人的網的內容，那麼以正常人的大腦，根本不可能接收完整。所以應該遇到什麼產品，或者項目。就先換位思考下，如果我自己來做，我會怎麼做。有哪些節點？有哪些流程？會有哪些問題？怎麼解決？等真正去諮詢和了解業務需求的時候。自己心裡已經搭好了一個簡單的框架。這時候，需要去了解的就不是一個知識樹的全部內容了，而是去了解跟自己現有框架的不同點和自己沒想到的部分。

剛開始的時候，可能自己設計能力比較弱，只能設計出完整產品的十分之一。但是堅持下去，多練習，久而久之，可能去了解需求的時候，就只差幾個點了。這時候，對需求的了解，對產品的了解，對用戶真實意圖的挖掘，都會比直接去問要深的多。這樣也能大大的提高分析能力和設計能力，同時提高思維的條理性。

騰訊的很多產品都會在用戶反饋頁直接留下產品經理的名字和聯繫方式～你猜是為什麼？

帶著"沒有產品我怎麼解決問題"的想法，下到基層，衝到第一線，被客戶罵個幾輪，你的分析能力就上來了。

就說三點吧：

競爭對手研究透

行業前三研究透

用戶留言研究透

把自己研究透

最後一點最重要

多調查數據，多寫，多比較

樓上的是在回答編程還是產品的角色

新人能完成上述的，就不是新人了

先說個反面的現狀，你別不相信：在現實情況中，需求分析、挖掘如此重要的工作往往是這樣進行的：產品決策者們要麼舒舒服服地坐在辦公室里閉門造車、憑空捏造需求，或者團隊顯得非常有幹勁，一大群聰明人通宵達旦、絞盡腦汁地花幾天甚至幾個周的時間來頭腦風暴出用戶需求，或者乾脆由老闆一招定乾坤、拍腦袋定需求。無論如何，大家都不願意放下身段、用最簡單但最穩妥的手段——比如，找幾十上百個用戶聊聊。

就這樣，大家群策群力、加班加點，終於研製出了新一代飛船，公司上下一片歡騰。試飛那天，核心骨幹們衣著光鮮，齊呼口號，爭先登倉。只見飛船瞬間騰空，以第三宇宙速度疾馳而去，在天空中划出了一道美麗的弧線。透過飛船的舷窗，他們看到腳下的星球被遠遠地拋在了身後，而這個星球的名字叫做——用戶。

那麼，為了避免這樣的宇宙悲劇發生，究竟怎麼做才能挖掘到真實的用戶需求呢？這裡介紹「細心觀察、深入用戶、悟性推理」等三種方法。

1、細心觀察

只要善於觀察生活的細節，你會發現用戶需求和創新機會隨處都有。

排隊裡面有學問。雖然國人的綜合素質在不斷提升，但在很多場合，排隊這件小事依然做得不夠好。你應該經常可以看到在辦事窗口前，一大堆人並沒有井然有序地排隊，而是你爭我搶緊緊簇擁在一起。推推搡搡之下，非常容易引發口角甚至肢體衝突。

很顯然，在旁邊放置「請自覺排隊」之類的指示牌不會有什麼效果，安排專人管理排隊秩序的話效率又太低。你可能說那安裝僅能排一個縱隊的隔離護欄，將入口、出口分離開來。這樣確實會極大地改善狀況，但仍然會出現窗口擠上兩三個人，以及有人不排隊而直接跑到出口加塞的問題。那到底有沒有辦法徹底解決這些問題呢？

有，那就是充滿民間智慧、具有中國特色的「防插隊機」。簡單有效，無懈可擊。

空調吹人的煩惱。炎熱的夏季，很多家庭都靠空調來解暑降溫。空調在帶來涼爽的同時，也帶來了一些麻煩。無論是你在客廳久坐看電視，或者在卧室睡覺，都可能經歷過空調冷風長時間直吹人體，而引發的不適甚至患上嚴重的疾病。雖然大部分空調都在出風口設置了導流葉片，並提供了調整風向以及自動「上下、左右」掃風的功能，但仍然沒有徹底解決問題。因為即使設定了固定的出風方向，仍然會有漏風的情況，或者設定了自動掃風，時間長了來回的冷風也會把你吹得不舒服。

於是，有人看到了這個需求，並設計出了各種各樣的「空調導風板」，月銷量可以達到成千上萬件。在此，也提請空調設計師們關注這個老生常談的問題，從源頭上將其解決。

快遞包裹的用戶需求。電子商務的繁榮帶來了快遞數量的飆升，據國家郵政總局統計，2015年全國快遞業務量達到206.7億件。然而，由於快遞包裝設計不夠人性化，給企業和用戶都帶來了麻煩。發貨人員需要用塑料膠帶將紙箱層層纏繞，工作效率很低；當用戶收到包裹後，要費九牛二虎之力才能層層剝開，有時候還會因為使用剪刀開包裹不慎傷及貨品或者雙手。此外，膠帶的大量使用也非常浪費、不夠環保。

有人注意到了這個需求，創立了一家叫做「一撕得」的公司，專門提供包裝解決方案。該公司的包裝箱不僅外觀上顯得很有品質，而且打包和開箱都變得非常便捷。

包裝人員封箱時，撕開鋸齒邊的雙面膠條即可牢固地粘上蓋子。用戶收到包裹後，就能像拉開衣服拉鏈一樣輕鬆打開紙箱。

這樣的創新設計及其帶來的優質體驗，很快贏得了包括三隻松鼠、唯品會、寺庫、阿芙精油等電商品牌的青睞。

2、深入用戶

深入到用戶當中去，你可能會有意想不到的收穫，挖掘到不可思議的需求。

1930年5月，毛澤東撰寫《反對本本主義》一文，用於警示當時紅軍中存在的教條主義思想。在文中，他提出「沒有調查，沒有發言權」的著名論斷。後來，毛澤東進一步指出：「一，不做調查沒有發言權。二，不做正確的調查同樣沒有發言權。」

幹革命需要深入群眾做調查，做產品更是如此。因為個體情況不同以及所處的生活環境千差萬別，那麼，除了自己在生活當中細心觀察，還需要主動走出去、去了解用戶的需求，尤其是接觸那些跟我們自己生活、工作環境差異比較大的用戶群體。在這個過程當中，你會獲得很多意想不到的用戶需求和產品使用場景，慢慢地會對用戶會有更深刻、更具象的理解。

貨車油耗管理的難題。翟學魂是一個創業老兵，在物流行業摸爬滾打了很多年。他發現，國內絕大部分貨車老闆和司機之間都存在矛盾，癥結就在「油」上面。由於貨車本身油耗大，每月行駛里程都在兩三萬公里以上，那麼，每百公里耗油量的小差異積累起來，都會使運輸成本增加很多。

然而，油耗管理卻是個難題：如果老闆管油，那麼幾乎所有的司機都會在利益的誘惑下千方百計地偷油，每個月輕鬆獲利數千元；如果讓司機負責油，那司機就會不顧行車安全想方設法地省油，比如會經常採取長時間空擋滑行的危險操作，還會出現車輛到達目的地燃油「剛好」耗盡，再也打不著火的尷尬局面。

於是翟學魂從解決這個痛點切入，創立了名叫「G7」的貨運車輛互聯網平台。通過給貨車上安裝可以聯網的硬體，實時捕捉包括油量、里程、速度、加速度、發動機轉速等車輛的多個數據上傳雲端。既從根本上解決了油耗管理的問題，還能了解司機的駕駛習慣，及時獲知車輛是否發生事故等狀況。這個功能受到了廣大貨車老闆以及相關物流和電商企業的歡迎，目前DHL、順豐、德邦、亞馬遜等企業都在使用G7管理自有或外協車隊，從而智能管理其運輸時效、成本及安全。

海爾洗衣機的另類用途。多年前，海爾公司收到來自四川農村用戶的投訴，說他們購買的海爾洗衣機質量不好，排水管很容易堵塞。公司的員工和高層都很吃驚，後來經過了解才知道，當地農民居然用洗衣機洗地瓜、土豆，結果大量的泥巴堵了排水管。於是，海爾公司決定改進產品，充分滿足這種特殊需求。他們開發出了排水管大、既可洗衣服又可洗地瓜、土豆的洗衣機，受到到農民的歡迎，並藉此迅速打開了農村市場。

如果不是數年深耕行業、與用戶在一起，是很難發掘到像網址導航、油耗管理以及能洗土豆的洗衣機這樣的用戶需求和商機的。

除了自己在平時細心觀察、長年累月深入行業，還可以使用調研的方法。通過大量、集中的面對面用戶調研，較快速地了解到用戶真實的想法和需求。

探究手機安全的第一需求。為了摸清楚用戶在手機安全軟體方面的需求，我曾經頂著可能被認為「不務正業」的壓力，帶團隊專門花了一個月的時間，奔赴多地進行用戶調研。通過一對一深訪、焦點小組等多種方式，前前後後親自接觸了超過兩百位以上的用戶。

功夫沒有白費，我們得到了很多重要的結論，其中就包括「用戶的手機安全第一需求並非支付安全，而是清理加速」這個看起來與常理相悖的結論。

隨著移動支付的逐漸普及，手機變成了隨身攜帶的、方便快捷的電子錢包。基於此現狀，根本不用做什麼用戶調研，就很容易歡快地得出這個結論：對於使用安全軟體的用戶來說，手機上的錢如果丟了那肯定是頭等大事，這比什麼「清理加速」之類的功能要重要無數倍。因此要把握好這個用戶需求和市場機會，投入人力物力來主打「保障支付安全」這個功能點。這個邏輯看起來顯而易見、無可辯駁，無論公司的產品研發、運營推廣的一線員工到中高層領導都會認可。

然而，當我們調研了從一線到三四線城市的、各行各業的用戶之後，卻得到了意想不到的結論——支付安全聽起來確實很重要，但用戶更需要清理加速功能，其原因總結起來有如下幾點：

手機丟錢這件事極少發生，而「速度慢、存儲空間不夠用」隨時在困擾著用戶。媒體上不時有「用戶因為詐騙電話簡訊、木馬病毒或者釣魚網站之類錢被轉走」的事件報道，但其發生的次數與數億手機用戶的巨大基數來比微乎其微，發生概率低到可以忽略，何況這裡面還有商家的恐嚇營銷。這個跟大家平時的感知也相一致——確實身邊沒有聽過誰有此遭遇。相反，安卓手機由於系統設計的原因以及國內手機軟體「偷偷啟動、靜默安裝」等亂象，導致手機速度慢、存儲空間被吃掉的現象大面積、高頻度地發生。加上安全軟體為了提高活躍度，紛紛將手機清理功能包裝成類似「發射火箭」等趣味操作的形式，使得該功能已經成為用戶的習慣，每天會啟動數十次。
用戶不覺得安全軟體能比支付工具本身更有保障能力。用戶普遍認為像支付寶這種專業的支付軟體自身會有足夠的安全保障能力，其他第三方的安全軟體並不一定比它專業。即使安全軟體跟支付軟體一樣，都聲稱「專門設置了數億元賠付保障金」，用戶也不為所動。大家認為即使我丟錢了，想要得到賠償恐怕比登天還難，用戶沒耐心去應對賠付所要滿足的苛刻條件以及需要經歷的冗長流程。
靠人不如靠己，用戶都有自己的防範妙招。我們發現有的人會給支付軟體綁定一個專門的銀行卡，這個卡里平時也就存個一兩千塊錢，即使被盜了損失也不大。有的用戶會使用兩部手機，一部iPhone專門用來支付、理財，不裝其他軟體不上不相關的網站，並且任何時刻都不連WIFI。另外一個安卓手機不涉及到錢財，則可以放心隨便玩。

獵豹清理大師就是只做清理加速功能而獲得了巨大成功，可以算是對這個結論的側面印證。可見，如果不是親自面對面調研，這些活生生的用戶故事以及重要的結論恐怕很難獲得。於是，全公司還會齊心協力、日復一日地浪費寶貴的人力物力，想當然地大推「支付安全」，那是多麼地可惜。

值得指出的是，用戶調研這件事親自參與非常重要。深入到用戶當中去做調查研究工作往往需要耗費很大的時間和精力，每次花費大半天才能與幾個到十來個用戶交流，可能還需要出差到不同發展程度的城市以及條件艱苦的縣城乃至鄉鎮去。因此，這件苦差事很少有人願意做，加之大部分公司重視程度不夠，於是，要麼乾脆不做用戶調研，要麼花數十萬將用戶調研工作直接交給調研公司代勞，自己人並不會親自上陣。

過上幾個周，調研公司的人會發來看似內容翔實、排版考究的上百頁調研報告。看完之後，經常是感覺「明明有很多重大發現，但事後印象模糊什麼都不記得」，這樣對產品的後續指導作用自然就微乎其微了。

究其原因，有這樣幾方面。第一，調研公司工作人員短時間內對於產品的理解有限，所以對用戶交流的方向和重點把握不夠準確；第二，現場聽到用戶講述自己使用習慣和故事，比看報告更鮮活更有觸動；第三，現場用戶很多細微但卻至關重要的措辭、表情等細節反饋，由於代勞的工作人員行業和產品敏感不足，而經常會被忽略或者因為層層轉述而大大衰減甚至扭曲了。

不見棺材不落淚，不撞南牆不回頭。負責決策的產品設計人員和營銷推廣人員如果不是親耳聽到用戶的抱怨、親眼看到用戶的痛苦，是很難「輕信」調研結論，下決心改進產品、改動營銷方案的。

可以看到，親自深入用戶交流、了解需求如此重要。

那麼，在設計產品之前，請問自己一個問題：你面對面聊過兩百個用戶嗎？

3、悟性判斷

有了足夠的積累和洞察能力，你就可以靠悟性、靠分析來對需求做出基本判斷。

「一步原則」，找到需求的簡單法則、創新想法的源泉。所謂「一步原則」，指的是如果用戶的某個常用操作需要多個步驟才能完成，那麼這就對應一個用戶需求，一個產品創新、改進的機會。

人們買東西都講究貨比三家，在電商網站上購物也是如此。比如你要買一部iPhone，為了找到最低價，可以分別在諸如京東、淘寶、天貓、國美等網站上搜索、比價。以後購買別的大件商品亦是如此，這顯然有點麻煩。同時，這也是一個產品創新的機會。於是，早在2010年，一個叫做「一淘網」的專門解決此問題的產品上線了。在該網站，輸入商品名稱，可以一步完成在各大電商的比價。而且，還可以給瀏覽器安裝插件，這樣當你在主流電商網站瀏覽商品時，頁面上就能同步顯示在其他地方的價格，非常方便。

幾年前，大家在瀏覽網頁時，如果看到網頁裡面個內容需要搜索下，一般需要先選中關鍵字，複製，然後粘貼到地址欄，敲回車搜索。這樣一個常用的操作不能便捷地一步完成，所以肯定可以改進。比如，現在大部分瀏覽器都支持「滑鼠拖放」功能，這樣，用滑鼠選中關鍵字後拖放一下就能打開搜索頁面。

在使用微信的過程當中，經常會碰到要連續點擊好幾次左上角的「返回」按鈕，才能回到首界面的情況，很費勁。比如，有一天你想查看某個公眾號的一篇歷史文章。你先在某個公眾號中點擊「查看歷史消息」，然後再點開某條圖文信息進行閱讀。讀完之後你想回到首界面，這時，你不得不連續點擊5次「返回」按鈕。

我相信很多用戶跟我一樣，長久以來被這個事情困擾。那按照「一步原則」，應該對這個問題進行改進。比如，小龍哥，能否改進為長按「返回」按鈕就一步回到主界面呢？

還有一個有關百度百科的案例。幾年前，我發現一個現象，用戶經常會碰到生詞，比如「耄耋」。怎麼樣，八成不認識吧？於是，你去百度搜索，通過百度百科可以了解到其含義是「指年紀很大的人」。但還是不知道讀音，又去百度搜索「耄耋怎麼讀」。

可見，這個體驗不滿足「一步原則」，應該考慮讓百科詞條直接展示拼音。我當時還注意到，所有百科類產品都沒有這個功能，最多就是詞條編輯人員隨意在正文裡面加上讀音。我就建議百度百科做一個體驗上的創新，在詞條名旁邊直接展示拼音。經過努力，這個功能上線了。

一步原則提到的問題，還可以通過分析產品的用戶行為日誌「無腦」地發現。如果從日誌裡面分析得出，很多用戶都存在一種相同的、連續的多步操作，比如「操作A、操作B、操作C」這三步操作連續、反覆、大量的出現。那麼，就應該考慮改進產品，把這三步變成一步。

這個「一步原則」，可以說是發明創造、產品創意的源泉。「懶人創造了世界」那句話就是這個意思，製造工具來代替人完成那些費時費力的重複性工作，將這個星球最智慧的生物解放出來干更有價值的事情。

把握用戶需要，還有個「真相原則」，就是要找到一個表象需求背後隱藏的真實需求。

先看一則有關真實需求的有趣漫畫。

老大爺由於沒有把握學生們開房的真實需求，導致賓館關門大吉。這則漫畫非常直觀和深刻地展現了了解真實需求的重要性。

環顧四周，我們發現生活中有很多類似的案例。現在思考一下，大家使用天氣預報軟體的真實需求是幹什麼？

應用市場中有很多各種各樣的天氣預報軟體，功能其實都大同小異。仔細想想，人們安裝天氣軟體只是表象的需求，其真實的需求是想了解未來天氣的變化和異常，這也是手段和目的的關係。

由此可見，第一層真實需求就是如果今天和昨天的天氣一樣，比如都是晴天，溫度差不了一兩度的話，那麼就不要來煩我。當氣溫將出現驟降驟升或者有雨雪風霧等天氣情況出現時，告訴我即可。我曾經用過一款挺熱門的天氣軟體，可能這個應用為了體現存在感，每天都給我推送一條天氣信息，很煩人。因為在大部分情況下，連續兩天的天氣和溫度都差不多，我就把它的通知功能給禁用了。

人們關注天氣的另外一層需求，就是選擇衣著。想必大家都有過在季節交替、氣溫變化較大的時候，穿錯衣服的尷尬經歷。比如，在北京那短暫的春天，這一幕就屢見不鮮。你像昨天一樣穿了那件輕薄羽絨服出門上班。結果發現驕陽似火，大部分人都只是穿了件薄外套，你卻裹得像個粽子，熱得受不了。這時，有個猛男居然只穿了件短袖迎面走來，你們對視了一秒鐘，心裡都默默地說了同一個不和諧的詞。

除了出門上班的穿著問題，那還有一類，就是去外地出差或者遊玩，也非常頭疼帶什麼衣服。大家不知道目的地那邊穿什麼衣服合適，即使看到當地的天氣預報也拿不準。

因此，天氣軟體可以提供針對不同天氣情況的穿著建議功能，用文字說明或者卡通圖形、真人照片都可以。有一天我欣喜地發現常用的墨跡天氣App提供了「時景」功能，就是每個地方的用戶隨手拍照上傳的照片。我想，這樣我就能知道那個地方的人大概穿什麼衣服了。但遺憾的是，大部分人拍攝的是天空、大樓或者花草之類，包含人像的並不多。我感覺把這個功能改成「穿什麼」，多拍一些當地人的穿著，應該更加實用。

再思考下大家購買保溫杯和電熱壺的真實需求。我想大部分人都能脫口而出，真實需求無非就是「喝水」了。的確是這樣，但很多保溫杯和電熱壺產品中設計時，並沒有把這個真實需求滿足好。有的保溫杯保溫效果很好、圖案精美、小巧便攜，但當你口渴時準備喝水時，發現水太燙沒法直接喝，還得另外找個杯子倒出來晾著。電熱水壺是常見的家用電器，接上電就能保溫，但喝水的時候也會遇到水太燙的情況。

對於這兩種情況，如果按照滿足喝水這個真實需求來考慮，可以這樣做產品設計：保溫杯的杯蓋可以兼做杯子使用，這樣用起來就方便了；電熱水壺可以增加「90度、60度」等保溫溫度選擇。泡茶就用90度，喜歡喝白開水就選60度，不涼不燙剛剛好。再想想，還有什麼用水場景對溫度有特定需求？有，那就是奶爸奶媽們給寶寶沖奶粉的場景。所以，可以增加40度這個檔位，避免溫度太高燙到寶寶或者破壞奶粉的營養。

=====

擴展閱讀：

產品定位：你是釘子，還是棒槌？
關於張小龍，你看到了「節制」，我看到了「抵禦」
以大部分產品體驗之差，根本輪不到去拼天賦！

P.S.：我的公眾號：自傳播實驗室，裡面有很多有關產品設計、品牌營銷方面的思考和案例，歡迎關注和交流。

個人的一些摸爬滾打的經驗，攢一篇八股供大伙兒吐嘈，僅適用於業務複雜的傳統行業2B產品。

每個需求都是一個哈姆雷特，一千個人有一千種分析方法。

【準備階段】

凡事都要打好基礎再行動，做需求分析至少熟悉以下三方面:

1、熟悉業務，能夠把業務流程所涉及的場景，角色，活動，上下游搞清楚。

2、熟悉產品，至少要掌握產品核心功能與系統邊界，了解需求在產品中的位置。

3、熟悉團隊，了解合作團隊的角色分工和人員能力情況，了解目前的資源狀態（忙還是閑，全職還是兼職）。這一點很重要但常被無視。

如果因種種原因剛好沒有相關積累，用到時最好請教了解的「行家」，萬萬不能略過直接上馬就做分析，會出大問題的。

好在做產品的一般都會對業務和所負責的產品比較熟悉。至少我們公司里，我認識的大部分產品經理都是其他崗位上「做而優」，然後轉產品的，筆者亦然。

當然這些儲備工作在於日常積累，從一個模塊到一個產品到再整個系統，從了解到熟悉再到精通是漫長的一個過程，我想這恐怕也是月薪5千到月薪5萬的過程吧。

判斷需求所處的是產品生命周期的哪個階段。不同階段有不同的分析策略。比較典型的MVP階段，要求功能極簡。這個階段需求是一道選擇題，需求要儘可能的體現產品核心價值才被執行，其他輔助性的增值的花瓶的統統砍砍砍。

在線運營階段，需求分析要多考慮對現在業務和用戶的影響，尤其是涉及核心業務或模塊大改的需求。這個時候需求是個變換題，要想辦法通過各種變通的方式實現或合理引導需求方從而減小影響。

產品轉型階段，這個時候需求是個判斷題，有些需求是給產品整容，但也有些是完全是毀容，我是見過太多被改的他馬麻都不認識的產品。

了解了產品當下的階段之後，就可以有針對性的開始需求分析了。大致為兩個階段，第一個階段主要回來要做什麼，為什麼要做？

【第一階段】

為了回答這兩個問題，一般可以如下四步走：

1、看需求來源，誰提的？客戶的需求、老闆的需求、產品的需求還是研發自優化需求，或者乾脆是個BUG（廣泛意義上也是需求）。所謂人人都是產品經理，人人都可以提需求，但不同來源的需求處理起來的節奏感是不一樣的。以下省略500字。

2、看需求是個體性的還是群體性的，是否有代表性。表面描述背後的本質需求是什麼，這點更重要。有個笑話說客戶提出A，產品經理理解成B，開發設計成C，最後交付了D。簡單的挖掘方法是多問幾次為什麼，為什麼提這個需求？這個需求要解決什麼問題？為什麼現在提？打算什麼條件下使用？提出者有解決方案嗎？轉著圈的多問幾次，不要怕麻煩，需求會越來越深入，越來越接近於本質。

3、看需求的類型，是單純的界面優化還是涉及流程調整？是完全獨立的新增功能還是涉及老模塊的改造？是單一模塊的內部需求還是跨模塊甚至跨產品的複合需求？從需求的性質判斷出需求的範圍、影響面、重要程度（研發視角）、實現難度等。

4、分析需求的緊要程度，可以參照時間管理的四象限方法，把需求劃分成緊急且重要，重要但不緊急，緊急但不重要，不緊急也不重要。以下省略一本書。於是這個需求要不要做，以及什麼時候做，優先順序就都有了。

上面四步走，全程都是結合著業務流程和產品來的，比如需求的緊重程度不是客戶或老闆說了算，而要依照當下市場分析並結合產品戰略做出理性分析的。

以上說的複雜，實際操作上有時可能分分鐘就搞定了，看經驗、能力和悟性了。

分析完之後要做什麼就基本清楚了。此時應該有產出了，流程圖或泳道圖之類的，有時候需要簡單的原型。同時要做一份需求確認文檔，去跟需求提出方交流。理解不同的要PK，範圍要PK，優先順序也要PK。如果說需求調研時傾聽最重要，這時就要體現引導客戶的能力了。2B的，尤其是2大B的。溝通之後是改改改，直到完成需求確認。這個過程有長有短，是體現產品經理能力的加分點。

確認之後，需求就最終定下來了，存檔入庫，不再接受變更。（PS：不再變更？99%是不可能的啦）

【第二階段】

二階段回答怎麼做？

在回答怎麼做之前先要問能不能做？即可行性。

評估可行性，往往需要多方面配合，比如產品、技術、研發、測試、項目經理、交付、運營、運維等。

可行性評估會影響之前的所有分析結果，甚至要時返回第一階段從新分析。再好的想法如果太超前技術上實現不了或實現成本太高那都是不靠譜。實際工作中我發現可行性評估這一步常常被忽略掉，結果給下游的同事挖各種坑。

如果需求可行，接下來就要定資源估工時了。估工時跟定研發計劃是不一樣的。關於估工時，又是一個大坑，裡面水好深。改天可以專門寫一篇。

【注意事項】

最後列幾個注意事項吧。

1.避免過渡分析，俗稱「想太多」。我們一款產品光MVP就有100多個菜單，你怕不怕？

2.做完一階段需求分析後，要跟客戶提出方做需求確認。還記得那個ABCD的笑話嗎？

3.需求的可行性評估還是不能省的。否則？霸王硬上弓，無顏見江東。

4.工時估計長一點，對自己好一點。最後給個私家公式，工時=研發計劃*3。

今年剛畢業、就接觸產品經理這塊的工作、現在是產品經理助理、產品經理帶了一段時間被派到另個項目。暫時沒人帶、自己提需求給自己，又根據運營提出的需求優化產品、在原有的產品規則上去優化產品、一下子想的太多、、、不知道怎麼辦，評審的過程往往是處於劣勢、有時候會打擊信心、但同時又是鞭策自己要更努力。其實做個產品、參透的規則很多、細了通了、最後還要對上大部分用戶的需求。做產品不是靠想、做產品也不會靠人家說、簡單去抓住一個需求點、細化、再全面化。

我是個營銷人員，感覺工作也是和需求分析相關啊

我覺得營銷和產品經理共同要具備的能力是在一大堆無序的邏輯，數據中找到有序，並能快速總結規律，運用於營銷及產品開發

最基本的用戶輸入需求分析，這個不應該只是營銷人員該做的如：

這是一個搜索引擎工程師開發的東西（看看如何站在搜索引擎角度考慮分析）

一串query藉助軟體可以告訴你很多信息

與節日相關的內容有哪些？這不是靠腦子想的，而是要通過數據分析，並以此形成自己的獨立體系！

不要告訴我你是喬布斯，整天想的是創造需求。那我也無話可說

附軟體下載地址：

http://d.shop123.io/tongyong/caijiqi.zip

我來分享下自己之前做的需求分析，歡迎大神們來打臉

--------------------圖片分割線-------------------------------------------