產品經理如何基於需求迭代產品（上篇）：需求調研的四個步驟

產品經理要爲產品負責，而且以產品爲手段，推進業務發展。

以產品爲手段，就是把產品當作產品經理本身的延伸，用產品經理的思惟和方法去解決問題推進業務發展，而產品就是思惟、方法和解決方案的載體。

產品經理要經過產品表達想法，就像做家經過書表達想法，建築師經過建築表達想法。與書、建築相比，互聯網產品擁有敏捷迭代這一大優點，書和建築沒辦法兩週更新一次，可是互聯網產品能夠。總覽產品的整個生命週期，其最小粒度就是版本，產品的版本迭代，就是推進業務的方法之一。

產品迭代，就是要基於需求進行產品設計以解決問題，通常包含需求調研和產品設計兩塊內容。（PS：需求挖掘和產品設計只是產品經理的工做內容之一，其餘還包括項目管理、溝通交流、競品分析、進度排期、產品培訓等，實質上都是爲產品迭代服務的，而產品迭代是爲業務服務的。）

需求調研是爲了明確版本迭代的內容，產品設計是基於需求出詳細解決方案，需求調研和產品設計階段都要靈活，某個已經肯定下來的需求由於產品設計方案實現不了也只能被砍掉。

什麼是需求調研和產品設計？

舉個例子：有一天，產品經理在論壇上溜達，發現有個用戶說他想吃鴨子。產品經理去溝通後發現，其實他是餓了，本身又喜歡吃鴨子。要不要解決這個需求呢？假設要，產品經理怎麼解決呢？沒條件就給個包子，有條件的給個祕製烤鴨，一碟小菜和一碗飯。

祕製烤鴨（來自百度圖片）

需求調研階段：

「發現有個用戶說他想吃鴨子」→需求收集

「產品經理去溝通後發現，其實他是餓了，本身又喜歡吃鴨子」→需求挖掘

「要不要解決這個問題」→需求評估

產品設計階段：

「沒條件就給個包子，有條件的給個祕製烤鴨，一碟小菜和一碗飯。」→產品設計

下面將從需求調研和產品設計兩個篇章分析。

需求調研的四個步驟

需求調研既然是爲了明確版本迭代的內容，就要通過需求收集、需求挖掘、需求評估和需求評估的四個步驟。

需求收集，創建需求反饋通道和需求池，隨時收集需求。

需求挖掘，洞察本質需求和場景，理解需求方。

需求評估，緊急度和重要性，儘可能作即重要又緊急的。

需求分析，需求分解和邊界肯定，作到什麼程度。

需求調研

需求收集：需求反饋通道和需求池

需求的來源包括公司、產品經理本身、運營、市場、用戶等等。日常要注意建設良好的需求反饋通道，需求反饋通道能夠分公司內部和公司外部。

公司內部是指內部的運營、市場、財務等部門提交的需求，隨着業務發展公司每一個部門都會提出各類各樣的需求以便於數據增加、提高效率、減小成本、風控等。若是每一個部門都每一個人都想產品經理提需求，這就會出現A說要作B說不要作的信息誤差問題。因此要有一套需求提交規範，每一個部門能夠有個需求收集員，需求收集員向內對接部門成員統一部門想法，向外對接產品經理溝通業務需求。若是遇到部門間衝突/合做的需求，還要拉來各部門的相關人員進行討論肯定。

公司外部是指來源於用戶、競對、行業專家等人的需求。能夠經過用戶羣、用戶反饋、回訪調研、微博吐槽等了解用戶的需求和關注點，尋找用戶的痛點，能從用戶中脫引而出。能夠經過使用競對產品，查看競對更新/幫助文檔等了解競對的發展狀況和產品策略，尋找本身的差別化。能夠經過行業會議、文章、當面交流等了解行業的趨勢和行業未解決的痛點，創造企業從行業中突圍的機會。

需求反饋通道建設起來之後，就要建設本身的需求池，把每一個需求分門別類放好。關於需求池的文章有不少，我在就再也不贅述了，注意記錄兩點：要解決什麼問題和建議的解決方案。

需求挖掘：歸因和同理心

每一個人提的需求都是基於他本身的理解，而他本身的理解一般都是片面的，由於不瞭解具體狀況或者只瞭解他那一端的產品。一個系統，暴露在人們眼前的永遠只是冰山一角，沒有海面下部分的承載，也不會有海面上的炫目冰山。

普通用戶所提出的解決方案和需求都是有侷限的，其價值不在於直接使用，而在於產品經理基於它去挖掘更深層次的需求。若是用戶讓你給他鴨子，你就給他一隻鴨子，這就是產品經理的失職。

產品經理須要用本身的同理心，化身爲用戶，在他的場景下面思考需求。我通常用如下兩種方法。

1.問題歸因，需求的本質是什麼？

當一個系統比較複雜的時候，絕大部分問題已經沒法一眼看穿了，須要產品經理本身去挖掘。就像一個嬰兒哇哇大哭，餵了奶不喝，摸摸額頭不燙，抱起來一看原來是尿牀了。這就是歸因。

怎麼進行問題歸因？

首先，要了解問題的表現，嬰兒的哇哇大哭就是不舒服表現出來的樣子。

其次，瞭解致使問題出現的可能狀況，嬰兒不舒服的緣由有餓了、渴了、生病了、尿牀了、發現媽媽不在身邊等幾種。

最後，定位問題的本質所在，抱起來一看尿牀了。

嬰兒哭泣

2.用同理心，爲何提出這種解決方案？

若是需求方只提出了解決方案卻沒有提出問題，也能夠從解決方案中倒推問題本質，有條件的話仍是向需求方求證比較靠譜。

（1）解決方案是瞭解需求方的一種途徑，由於是創建於需求方自身對問題、產品和操做習慣等基礎之上的。經過解決方案倒推需求方對產品、問題的理解和操做習慣，可以讓咱們更好的揣摩和理解需求方所處的角色和產品在需求方心目中的畫像，以小見大，不管對後續需求評估和平常用戶理解都頗有幫助。

（2）解決方案也是個衡量標準。需求方提出的解決方案通常只有60分，只是能解決問題，處於需求金字塔的下方。產品經理以其爲衡量標準，去判斷本身的解決方案是解決了哪一個層次的需求。理想情況下天然是超出需求方指望，觸動需求方的G點。實際狀況並非誰的需求都要知足，所以要進行需求評估。

需求評估：重要性和緊急度

需求評估主要評估的是優先級，經常使用的方法有KANO模型、四象限模型、波士頓矩陣模型等。我比較經常使用的就是四象限模型，優先級：象限一 重要且緊急 ＞ 象限二 重要且非緊急 ＞ 象限三 非重要且緊急 ＞ 象限四 非重要且非緊急。

四象限模型

如何判斷需求的重要性和緊急度？

1.重要性的判斷標準，幾個比較重要的狀況

（1）公司戰略：產品經理是爲產品服務，產品是爲業務服務，業務爲公司服務，公司戰略落地的需求是從頂層下來，是須要優先考慮的。

（2）利潤相關：公司是要賺錢和生存的，一般客戶＞用戶，大客戶＞小客戶。

（3）基礎結構：產品是一座樓，基礎結構就是地基，稍蓋幾層沒有太大關係，若是地基沒搭好就會有坍塌的風險。包括角色、實體、主業務邏輯、系統架構、帳號體系等。

2.緊急性的判斷標準

（1）摸清實際狀況：業務方、用戶等一般會提出不少很是緊急的需求，產品經理不要被打蒙了，要先摸清實際狀況，影響了多少業務，影響了多少用戶，什麼緣由形成的等等。

（2）根據影響評估：摸清實際狀況後，根據需求的影響進行評估。核心業務高於邊緣業務，影響用戶多高於影響用戶少，形成損失高於未形成損失等等

3.四象限模型

（1）重要且緊急的比較少，若是多了就須要反思是評估問題仍是產品基礎沒打好；

（2）重要且不緊急的要多作，這些表明了產品的將來，並且要慎重，決策要慎重迭代也要慎重，要花時間去打磨他，不要急於求成，也不要一上一整個；

（3）不重要且緊急的要少作，作多了產品容易被牽着鼻子走，還會形成資源浪費，若是多了就須要反思是否是之前產品迭代沒作到位；

（4）不重要且不緊急的要不作。

需求分析：需求分解和邊界肯定

需求評估後，就要對第一第二第三象限的需求進行需求分析，需求分析的目的是得出要作到什麼程度，60分和90分效果和所需資源都不同。

我一般會在需求分析時，先進行需求分解，後進行邊界肯定。

1.需求分解

需求分解，指思惟發散，思考需求將來的發展，思考需求所觸及的功能模塊。

不管是業務、產品、功能或是需求，都有本身的生命週期，都是不斷髮展的。產品經理要基於如今判斷將來。

把需求比喻成木桶，作產品就是造木桶，木桶的木板就是產品模塊，木桶越大承載力越強成本也越高。需求分解的時候，產品經理要思考木桶之後要多大，木桶的木板要有幾根。

木桶（來自百度圖片）

2.邊界肯定

邊界肯定，指根據當前需求/業務狀態、需求方心理預期肯定需求的邊界。

俗話說，最合適的纔是最好的。若是你如今功能遠遠超出當前需求，可能到產品死了都還沒用上，這就是對資源的浪費。若是你如今功能還不能知足當前需求，這也是對資源的浪費，下次迭代前需求方還會來找你。理想狀況下，是超越當前需求一小段。具體這一段有多長，就須要根據需求重要性、業務發展狀況等進行合理評估了。

邊界肯定就是肯定木桶的高度，很高不合適很低也不合適，木桶的高度取決於要裝多少水。決定了木桶高度以後，就能夠去造木板了，造木板這就是產品設計的事了。

這些都是我本身的自我總結，也是我對世界的認知和總結，每一個人的認知或多或少有所不一樣，但願可以幫助你們更好地認識這個世界。

Vency，兩年經驗產品經理，歡迎交流微信號：vency277136551，追求用戶、技術、商業、社會價值的統一

搜索關注公衆號 Vency不二或者vencybu2，向你們分享我或系統或粗放的深度思考

下一篇：產品經理如何基於需求迭代產品（下篇1）：產品設計的高內聚低耦合