編輯導(dǎo)語：產(chǎn)品經(jīng)理每天要接觸到大大小小不同的需求，需求在產(chǎn)品經(jīng)理的日常工作中占了很大的比重。面對這些需求，只有選取恰當(dāng)?shù)姆绞竭M(jìn)行分析處理，才能更好地幫助開發(fā)了解問題，從而制定相應(yīng)的解決方案。那么，該如何驗證我們的需求假設(shè)呢？本文作者基于自身經(jīng)驗，對此展開了分析總結(jié)，希望對你有幫助。

需求是產(chǎn)品經(jīng)理在日常工作中每天都在打交道的，我們每天總是在想用戶可能需要這個，用戶可能需要那個。

然而我們想的并不一定就是用戶真正需要的，這就需要對我們提出的假設(shè)進(jìn)行驗證。

用戶有各種各樣的需求，有的需求是大眾需求，例如：網(wǎng)上購物需求、線上打車需求。

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

還有一部分就是偽需求了，大到一個產(chǎn)品方向、小到一個產(chǎn)品功能，你覺得用戶需要這個，但真正做出來之后卻發(fā)現(xiàn)用戶根本不買賬，比如共享經(jīng)濟(jì)比較火的時候出現(xiàn)的共享雨傘、共享籃球等等。

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

首先我們必須承認(rèn)一個事實，每個人的成長經(jīng)歷、眼界認(rèn)知、行業(yè)經(jīng)驗等等都不同，而這些就導(dǎo)致了我們對需求的理解不同。

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

我們經(jīng)常容易犯的一個錯誤就是站在自己角度看問題，記得當(dāng)年快手這個產(chǎn)品剛誕生不久，自己也下載過，打開里邊的內(nèi)容覺得這個整個產(chǎn)品看起來比較“l(fā)ow”，“有人玩才怪”，而如今快手的市值已經(jīng)突破了1萬億港元。

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

我們常說說產(chǎn)品經(jīng)理要站在用戶角度思考問題，這句話沒毛病，但說實話要做到這一點確實不容易。

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

因此還有一個做產(chǎn)品方法理念，就是多跟用戶交流，不管是訪談聊天，還是看用戶反饋等，據(jù)此了解用戶真實的想法，加深我們對需求理解。

不論是換位思考、還是多接觸用戶、了解用戶真實想法，我們總是會受限于個人對需求理解程度、樣本數(shù)量的大小等因素，所以我們最終發(fā)掘的用戶需求可能還會是我們的一廂情愿。

特別是現(xiàn)如今大部分需求都已經(jīng)被滿足的情況下，需求的真?zhèn)卧絹碓诫y判斷，要求我們對需求、對用戶理解的更深刻，同時還要去驗證是否和我們當(dāng)初設(shè)想的一樣。

這還不像互聯(lián)網(wǎng)快速發(fā)展的時候，很多需求需求都是顯而易見的，盡管快速迭代獲取用戶就是了，根本無需在驗證需求上花費太多時間。

那么如何驗證我們的需求是否跟我們的設(shè)想一致呢？

這里邊還得分為兩種情況：一是比較大的產(chǎn)品模式的驗證，比如你有一個想法，想創(chuàng)業(yè)做一個產(chǎn)品，這種情況更多是驗證你的想法；另外一種是產(chǎn)品版本迭代的驗證，驗證的更多的是產(chǎn)品里的功能模塊。

01 產(chǎn)品模式驗證

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

我們先拿一個日常生活中事情舉個例子，買房是我們?nèi)松械囊患笫?，畢竟房子是高?biāo)的物，有時候還得掏空好幾個錢包，看了好多個，最終決定在哪買的時候還是謹(jǐn)慎再謹(jǐn)慎，因為一旦買錯了，造成的損失影響實在太大。

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

可能你看房的時候是晚上，路上車比較少，所以房子內(nèi)還算比較安靜，可當(dāng)你住進(jìn)了才發(fā)現(xiàn)白天的噪音確實很大；可能中介跟你說周圍有個大超市，可當(dāng)你住進(jìn)來時候卻發(fā)現(xiàn)離你四五公里；更夸張的，之前在新聞上看到的用戶買完房之后發(fā)現(xiàn)屋后就是墓地。

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

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

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

當(dāng)你覺得這個房子的位置、學(xué)區(qū)、生活便利性等都很不錯時，并不是直接簽合同交錢，而是先通過租房形式驗證你的假設(shè)是否正確，只有真正驗證過后再做決定，驗證這個的成本可能最多一兩千塊錢，可是她卻能幫你減少了很多風(fēng)險。

回到互聯(lián)網(wǎng)領(lǐng)域，有一個產(chǎn)品理論叫MVP（最小可行性產(chǎn)品），看概念好像比較難懂，其實它的本質(zhì)同我們舉的買房的例子是一樣的，并不是一上來就開始上手做這件事，而是先通過低成本的手段快速驗證我們的假設(shè)。

我們經(jīng)?？吹接行﹦?chuàng)業(yè)公司，老板有一個“石破天驚”的想法，成功的“忽悠”了一幫投資人拿了幾百萬投資。

項目啟動后，老板特別注重用戶體驗、特別追求完美，不等產(chǎn)品打磨好決不能推向市場。

當(dāng)整個團(tuán)隊加班加點做了一年，老板覺得產(chǎn)品打磨的差不多，該放大招了，終于等到自己上場了，于將產(chǎn)品開放給用戶，結(jié)果卻發(fā)現(xiàn)使用者寥寥無幾，滿心歡喜變成淚眼汪汪，整個團(tuán)隊一整年的成果瞬間化為烏有。

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

02 低成本的快速試錯

當(dāng)你有了一個想法時，首先通過一個低成本的手段去驗證你的想法。

假設(shè)你覺得男士化妝品很有前景，想做一個專賣男士化妝品的產(chǎn)品，并不是一上來就建網(wǎng)站、做App，可以先通過你的朋友圈（前提是好友里有你的目標(biāo)群體）賣一段時間試試，看看大家的反響如何。

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

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

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

以上跟大家分享了通過MVP形式驗證我們的想法，接下來再跟大家聊聊如何驗證我們產(chǎn)品功能模塊。

03 產(chǎn)品迭代驗證

作為產(chǎn)品經(jīng)理，我們?nèi)粘９ぷ髦凶钪匾囊徊糠止ぷ骶褪钱a(chǎn)品的迭代了，每一次迭代的功能模塊如何設(shè)計、迭代后的效果如何，都需要我們進(jìn)行驗證，通常對于一個功能模塊，有以下幾種驗證手段：

1. 改版數(shù)據(jù)

數(shù)據(jù)是最具有說服力的形式，當(dāng)然前提是數(shù)據(jù)的埋點得正確、數(shù)據(jù)分析時對比的維度也要一致。

比如說這個版本做這個功能預(yù)期是提升產(chǎn)品的人均時長，那么我們可以在版本上線后查看新版本的人均時長數(shù)據(jù)，比較老版本提升了多少，如果沒有提升，那么我們就要去想是哪個環(huán)節(jié)出了問題、還是當(dāng)初太理想化了

2. 用戶反饋

用戶反饋是產(chǎn)品經(jīng)理了解用戶的常用手段之一，雖然說用戶反饋也是驗證功能迭代的一個手段，這個這個手段其實比較主觀，并沒有太大的說服意義。

像我們?nèi)ツ陮Ξa(chǎn)品做了一次升級，產(chǎn)品的頁面變化較大，結(jié)果一批老用戶就來吐槽，因為他們習(xí)慣了原有的產(chǎn)品樣式，但對于我們來說，產(chǎn)品不可能一直停留在幾年前的風(fēng)格樣式。

而且很多覺得改版好的用戶他們也大概率不會發(fā)表意見，屬于沉默用戶，所以給人整體感覺上好像大家都在吐槽，但其實仔細(xì)一看，吐槽的只是占據(jù)所有用戶中很小的一部分。

3. AB測試

有時候在設(shè)計產(chǎn)品的時候，可能有多個產(chǎn)品方案，每個人都說不準(zhǔn)哪個方案更好，那么這個時候就可以使用AB測試這種形式。

AB測試是將我們的假設(shè)制作兩個（A/B）或多個（A/B/n）版本，除了我們想要驗證的假設(shè)之外，其他所有的條件都不變，在同一時間維度內(nèi)目標(biāo)人群隨機訪問這些版本，然后我們看每個版本的數(shù)據(jù)情況。

例如幾年前做直播產(chǎn)品時，關(guān)于直播feed流是用單列大圖、還是雙列小圖，大家都各執(zhí)已見。

后來我們就把feed流內(nèi)容樣式分為AB兩個版本，A版本用戶使用的是單列大圖、B版本用戶使用的是雙列小圖，其他部分不變，AB版本隨機分配50%的用戶，最后看AB版本的數(shù)據(jù)效果。

當(dāng)然如果公司沒有現(xiàn)成的AB測試平臺，得先需要搭建AB測試的環(huán)境，還有一定的開發(fā)量，另外在做AB測試時有些事項也需要注意：

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

其次在測試這塊時間內(nèi)，用戶的行為是不變的，而且測試時間要長，因為有些新功能可能需要給老用戶一定時間去適應(yīng)。

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

4. 灰度測試

微信每次發(fā)布比較大的版本，我們會發(fā)現(xiàn)有些人已經(jīng)用上了新版本，而自己去檢查更新卻提示已經(jīng)是最新版了，這其實就是微信更新的灰度策略。

因為微信用戶體量實在是太大，每天有10.9億用戶打開微信，3.3億用戶進(jìn)行了視頻通話，有7.8億用戶進(jìn)入朋友圈，1.2億用戶發(fā)表朋友圈，如果功能更新一下全部推給所有用戶，即使騰訊的測試再嚴(yán)格，也怕萬一出點bug什么的，那影響的用戶可太大了。

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

除了擔(dān)心有潛在問題之外，通過灰度測試也可以看到用戶對這個版本的反饋，比如用戶如果對其中的一個功能比較反感，那么也可以及時調(diào)整策略。

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

以上就是跟大家分享的驗證產(chǎn)品需求的一些方法，這些其中的思維模式也并僅僅不局限于我們做互聯(lián)網(wǎng)產(chǎn)品，在日常生活中我們也能找到很多相似的地方，希望能對大家有幫助。

#專欄作家#

HQ，公眾號：產(chǎn)品那些年，人人都是產(chǎn)品經(jīng)理專欄作家。社交路上不斷前行的創(chuàng)業(yè)產(chǎn)品汪。關(guān)注社交社區(qū)，打過工創(chuàng)過業(yè)，擅長產(chǎn)品規(guī)劃與設(shè)計，純干貨，不摻假。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash, 基于CC0協(xié)議