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

產品經理要為產品負責，並且以產品為手段，推動業務發展。

以產品為手段，就是把產品當做產品經理自己的延伸，用產品經理的思維和方法去解決問題推動業務發展，而產品就是思維、方法和解決方案的載體。

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

產品迭代，就是要基於需求進行產品設計以解決問題，一般包含需求調研和產品設計兩塊內容。（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，追求用戶、技術、商業、社會價值的統一

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

推薦閱讀：