編輯導語：產品經理每天要接觸到大大小小不同的需求，需求在產品經理的日常工作中佔了很大的比重。面對這些需求，只有選取恰當的方式進行分析處理，才能更好地幫助開發瞭解問題，從而制定相應的解決方案。那麼，該如何驗證我們的需求假設呢？本文作者基於自身經驗，對此展開了分析總結，希望對你有幫助。

需求是產品經理在日常工作中每天都在打交道的，我們每天總是在想使用者可能需要這個，使用者可能需要那個。

然而我們想的並不一定就是使用者真正需要的，這就需要對我們提出的假設進行驗證。

使用者有各種各樣的需求，有的需求是大眾需求，例如：網上購物需求、線上打車需求。

有的需求是小眾需求，例如：高達愛好者交流需求、老年人跳廣場舞需求，雖然面向的人群有限，但使用者的需求也足夠強烈。

還有一部分就是偽需求了，大到一個產品方向、小到一個產品功能，你覺得使用者需要這個，但真正做出來之後卻發現使用者根本不買賬，比如共享經濟比較火的時候出現的共享雨傘、共享籃球等等。

我們也許會問，既然是偽需求，那麼為什麼還有那麼多的人要做這件事，特別像一些創業公司，花費了百萬千萬的投資，到頭來卻是竹籃打水一場空，最後不得不關門大吉。

首先我們必須承認一個事實，每個人的成長經歷、眼界認知、行業經驗等等都不同，而這些就導致了我們對需求的理解不同。

同樣一個需求，可能是一個偽需求，但也有人覺得是使用者的剛需。

我們經常容易犯的一個錯誤就是站在自己角度看問題，記得當年快手這個產品剛誕生不久，自己也下載過，開啟裡邊的內容覺得這個整個產品看起來比較“low”，“有人玩才怪”，而如今快手的市值已經突破了1萬億港元。

周鴻禕也曾分享過一個他自己的案例，在滴滴很早期的時候，360是有機會投資滴滴的，但老周自己有司機接送，已經很多年沒打過車了，便覺得現在打車的人應該沒多少，市場不會太大，後來就沒投，錯過了入股滴滴的機會，又是一個幾十甚至上百億美金的教訓。

我們常說說產品經理要站在使用者角度思考問題，這句話沒毛病，但說實話要做到這一點確實不容易。

就像讓你去做一個廣場舞產品，我們需要站在老年人角度去思考這個產品，二三十歲的我們從來沒有跳過這個，對老年人的需求也不瞭解，就是想破腦袋也想不出來該怎麼做。

因此還有一個做產品方法理念，就是多跟使用者交流，不管是訪談聊天，還是看使用者反饋等，據此瞭解使用者真實的想法，加深我們對需求理解。

不論是換位思考、還是多接觸使用者、瞭解使用者真實想法，我們總是會受限於個人對需求理解程度、樣本數量的大小等因素，所以我們最終發掘的使用者需求可能還會是我們的一廂情願。

特別是現如今大部分需求都已經被滿足的情況下，需求的真偽越來越難判斷，要求我們對需求、對使用者理解的更深刻，同時還要去驗證是否和我們當初設想的一樣。

這還不像網際網路快速發展的時候，很多需求需求都是顯而易見的，儘管快速迭代獲取使用者就是了，根本無需在驗證需求上花費太多時間。

那麼如何驗證我們的需求是否跟我們的設想一致呢？

這裡邊還得分為兩種情況：一是比較大的產品模式的驗證，比如你有一個想法，想創業做一個產品，這種情況更多是驗證你的想法；另外一種是產品版本迭代的驗證，驗證的更多的是產品裡的功能模組。

01 產品模式驗證

首先說產品模式的驗證，我們常說大道至簡，許多知識理論的本質都是一樣的，只不過同一套知識理論應用在不同的場景而已。

我們先拿一個日常生活中事情舉個例子，買房是我們人生中的一件大事，畢竟房子是高標的物，有時候還得掏空好幾個錢包，看了好多個，最終決定在哪買的時候還是謹慎再謹慎，因為一旦買錯了，造成的損失影響實在太大。

買房時要考慮位置、交通、學校、生活便利性等各方面因素，因為可能我們對這片區域不熟悉，所以這些因素可能只是瞭解一個表面。

可能你看房的時候是晚上，路上車比較少，所以房子內還算比較安靜，可當你住進了才發現白天的噪音確實很大；可能中介跟你說周圍有個大超市，可當你住進來時候卻發現離你四五公里；更誇張的，之前在新聞上看到的使用者買完房之後發現屋後就是墓地。

所以這裡邊會有很多潛藏的問題，一旦買錯了，產生的成本還是比較高的。

但有的人會這樣做，當決定要買這片房子時，會先在這個小區或者附近租個房子，住個七天半個月的，基本上對所有的情況都能有一個比較深入的瞭解，這個時候再決定買不買，潛藏的風險就小了很多。

這就是一個典型的驗證我們假設的過程。

當你覺得這個房子的位置、學區、生活便利性等都很不錯時，並不是直接籤合同交錢，而是先透過租房形式驗證你的假設是否正確，只有真正驗證過後再做決定，驗證這個的成本可能最多一兩千塊錢，可是她卻能幫你減少了很多風險。

回到網際網路領域，有一個產品理論叫MVP（最小可行性產品），看概念好像比較難懂，其實它的本質同我們舉的買房的例子是一樣的，並不是一上來就開始上手做這件事，而是先透過低成本的手段快速驗證我們的假設。

我們經常看到有些創業公司，老闆有一個“石破天驚”的想法，成功的“忽悠”了一幫投資人拿了幾百萬投資。

專案啟動後，老闆特別注重使用者體驗、特別追求完美，不等產品打磨好決不能推向市場。

當整個團隊加班加點做了一年，老闆覺得產品打磨的差不多，該放大招了，終於等到自己上場了，於將產品開放給使用者，結果卻發現使用者寥寥無幾，滿心歡喜變成淚眼汪汪，整個團隊一整年的成果瞬間化為烏有。

MVP的理論核心其實就是低成本的快速試錯。

02 低成本的快速試錯

當你有了一個想法時，首先透過一個低成本的手段去驗證你的想法。

假設你覺得男士化妝品很有前景，想做一個專賣男士化妝品的產品，並不是一上來就建網站、做App，可以先透過你的朋友圈（前提是好友裡有你的目標群體）賣一段時間試試，看看大家的反響如何。

如果無人問津，那麼可能目前市場還不成熟，大家對這個的需求不大；如果有許多人感興趣，那麼你可以在朋友圈跑通流程之後，逐漸增加公眾號、小程式等新渠道。

其次就是要快，對於我們來說，時間是最大的隱形成本，時間就是金錢，時間就是機會，所以要快速的驗證你的想法是否正確，如果驗證正確，那麼需要快速迭代佔據市場。

如果錯誤，那麼要及時止損，不花費過多時間，尋找其他的方向再次嘗試。

以上跟大家分享了透過MVP形式驗證我們的想法，接下來再跟大家聊聊如何驗證我們產品功能模組。

03 產品迭代驗證

作為產品經理，我們日常工作中最重要的一部分工作就是產品的迭代了，每一次迭代的功能模組如何設計、迭代後的效果如何，都需要我們進行驗證，通常對於一個功能模組，有以下幾種驗證手段：

1. 改版資料

資料是最具有說服力的形式，當然前提是資料的埋點得正確、資料分析時對比的維度也要一致。

比如說這個版本做這個功能預期是提升產品的人均時長，那麼我們可以在版本上線後檢視新版本的人均時長資料，比較老版本提升了多少，如果沒有提升，那麼我們就要去想是哪個環節出了問題、還是當初太理想化了

2. 使用者反饋

使用者反饋是產品經理瞭解使用者的常用手段之一，雖然說使用者反饋也是驗證功能迭代的一個手段，這個這個手段其實比較主觀，並沒有太大的說服意義。

像我們去年對產品做了一次升級，產品的頁面變化較大，結果一批老使用者就來吐槽，因為他們習慣了原有的產品樣式，但對於我們來說，產品不可能一直停留在幾年前的風格樣式。

而且很多覺得改版好的使用者他們也大機率不會發表意見，屬於沉默使用者，所以給人整體感覺上好像大家都在吐槽，但其實仔細一看，吐槽的只是佔據所有使用者中很小的一部分。

3. AB測試

有時候在設計產品的時候，可能有多個產品方案，每個人都說不準哪個方案更好，那麼這個時候就可以使用AB測試這種形式。

AB測試是將我們的假設製作兩個（A/B）或多個（A/B/n）版本，除了我們想要驗證的假設之外，其他所有的條件都不變，在同一時間維度內目標人群隨機訪問這些版本，然後我們看每個版本的資料情況。

例如幾年前做直播產品時，關於直播feed流是用單列大圖、還是雙列小圖，大家都各執已見。

後來我們就把feed流內容樣式分為AB兩個版本，A版本使用者使用的是單列大圖、B版本使用者使用的是雙列小圖，其他部分不變，AB版本隨機分配50%的使用者，最後看AB版本的資料效果。

當然如果公司沒有現成的AB測試平臺，得先需要搭建AB測試的環境，還有一定的開發量，另外在做AB測試時有些事項也需要注意：

首先是AB組一定要隨機分配，絕對的隨機幾乎不太可能，只能儘可能的接近真隨機；

其次在測試這塊時間內，使用者的行為是不變的，而且測試時間要長，因為有些新功能可能需要給老使用者一定時間去適應。

另外AB測試畢竟還有一定的成本，並不是所有的改動都需要用AB測試，否則就是小題大作了。

4. 灰度測試

微信每次釋出比較大的版本，我們會發現有些人已經用上了新版本，而自己去檢查更新卻提示已經是最新版了，這其實就是微信更新的灰度策略。

因為微信使用者體量實在是太大，每天有10。9億使用者開啟微信，3。3億使用者進行了影片通話，有7。8億使用者進入朋友圈，1。2億使用者發表朋友圈，如果功能更新一下全部推給所有使用者，即使騰訊的測試再嚴格，也怕萬一出點bug什麼的，那影響的使用者可太大了。

所以透過灰度測試的形式，先把新版本推給一部分使用者，比如10%的使用者，這些使用者使用過程中沒有什麼問題之後，在逐漸擴大使用者的比例，直到推給所有使用者。

除了擔心有潛在問題之外，透過灰度測試也可以看到使用者對這個版本的反饋，比如使用者如果對其中的一個功能比較反感，那麼也可以及時調整策略。

灰度測試一般適用於體量較大的產品的迭代更新，特別是產品要推出全新的功能或者大的版本改動，那麼驗證我們的此次迭代，灰度測試是一個比較安全保險手段。

以上就是跟大家分享的驗證產品需求的一些方法，這些其中的思維模式也並僅僅不侷限於我們做網際網路產品，在日常生活中我們也能找到很多相似的地方，希望能對大家有幫助。

#專欄作家#

HQ，公眾號：產品那些年，人人都是產品經理專欄作家。社交路上不斷前行的創業產品汪。關注社交社群，打過工創過業，擅長產品規劃與設計，純乾貨，不摻假。

本文原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash， 基於CC0協議