編輯導語：產品經理每天要接觸到大大小小不同的需求，需求在產品經理的日常工作中佔了很大的比重。面對這些需求，只有選取恰當的方式進行分析處理，才能更好地幫助開發瞭解問題，從而制定相應的解決方案。那麼，該如何驗證我們的需求假設呢？本文作者基於自身經驗，對此展開了分析總結，希望對你有幫助。
需求是產品經理在日常工作中每天都在打交道的，我們每天總是在想用户可能需要這個，用户可能需要那個。
然而我們想的並不一定就是用户真正需要的，這就需要對我們提出的假設進行驗證。
用户有各種各樣的需求，有的需求是大眾需求，例如：網上購物需求、線上打車需求。
有的需求是小眾需求，例如：高達愛好者交流需求、老年人跳廣場舞需求，雖然面向的人羣有限，但用户的需求也足夠強烈。
還有一部分就是偽需求了，大到一個產品方向、小到一個產品功能，你覺得用户需要這個，但真正做出來之後卻發現用户根本不買賬，比如共享經濟比較火的時候出現的共享雨傘、共享籃球等等。
我們也許會問，既然是偽需求，那麼為什麼還有那麼多的人要做這件事，特別像一些創業公司，花費了百萬千萬的投資，到頭來卻是竹籃打水一場空，最後不得不關門大吉。
首先我們必須承認一個事實，每個人的成長經歷、眼界認知、行業經驗等等都不同，而這些就導致了我們對需求的理解不同。
同樣一個需求，可能是一個偽需求，但也有人覺得是用户的剛需。
我們經常容易犯的一個錯誤就是站在自己角度看問題，記得當年快手這個產品剛誕生不久，自己也下載過，打開裏邊的內容覺得這個整個產品看起來比較“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協議