當(dāng)拿到一個(gè)需求時(shí)，分析他的核心假設(shè)是可以確定的，還是需要線上用戶驗(yàn)證的。如果是可以確定的，其實(shí)就不需要采用 MVP；如果是需要線上用戶驗(yàn)證的，才適合用 MVP 的方式。

Eric Ries 在《精益創(chuàng)業(yè)》中提到?MVP（minimum viable product）概念，意即”最小化的可行性產(chǎn)品” – 花最少的力氣、最短的開發(fā)時(shí)間建立一個(gè)產(chǎn)品原型，這個(gè)產(chǎn)品原型需要經(jīng)歷一次完整的?BML（開發(fā) – 測量 – 認(rèn)知）?循環(huán)，以此幫助認(rèn)清對(duì)用戶需求的理解是不是正確，快速試錯(cuò)。

關(guān)于 MVP 有很多成功的案例：美國鞋類第一大電商zappos最開始建網(wǎng)站后沒有馬上進(jìn)貨，為了驗(yàn)證是否有網(wǎng)上買鞋的需求，他們等有人下單后直接去實(shí)體店里買來后再郵寄給客戶；

airbnb最開始是兩個(gè)創(chuàng)始人在自己房間里擺了三個(gè)床墊就把網(wǎng)站掛出去了，然后融到了600萬美金；

最著名的是40億美金估值的dropbox，只做了一個(gè)視頻說描述了一下要做的服務(wù)，什么都沒有做的情況下，根據(jù)視頻點(diǎn)擊量驗(yàn)證這個(gè)產(chǎn)品會(huì)很有用戶需求，于是開始融資開發(fā)。

相信很多產(chǎn)品經(jīng)理都看過《精益創(chuàng)業(yè)》，也都贊同 MVP 理論，但實(shí)際上 MVP 做起來比看上去要困難的多，在工作中經(jīng)常還會(huì)覺得 MVP 和用戶體驗(yàn)的沖突的。

因?yàn)樵谄綍r(shí)產(chǎn)品設(shè)計(jì)過程中，很多產(chǎn)品經(jīng)理都通過把自己想象成用戶，來設(shè)計(jì)要達(dá)到某個(gè)目標(biāo)需要怎樣的功能流程，并在此基礎(chǔ)上補(bǔ)充上異常流程和分支流程的處理邏輯。當(dāng)需要在所有這些功能中排定優(yōu)先級(jí)，決定哪些功能應(yīng)該出現(xiàn)在 MVP 版本里面的時(shí)候，就很為難，覺得無論刪哪一個(gè)都會(huì)破壞產(chǎn)品的的完整性。

01 根據(jù)需求判斷

我們大都是到了設(shè)計(jì)完功能的時(shí)候才去想怎么 MVP ，而真正確定是不是應(yīng)該 MVP 應(yīng)該是在我們需要驗(yàn)證什么問題的時(shí)候就開始了。

我們拿到一個(gè)需求，分析他的核心假設(shè)是可以確定的，還是需要線上用戶驗(yàn)證的。如果是可以確定的，其實(shí)就不需要采用 MVP；如果是需要線上用戶驗(yàn)證的，才適合用 MVP 的方式。

之前做二手車交易的時(shí)候做過兩個(gè)項(xiàng)目，一個(gè)適合，一個(gè)不適合：

寄售車源

我們是希望通過寄售的模式為第一次未成交的車源找到感興趣的車商，并通過現(xiàn)場議價(jià)的方式促成合作，這里面包含了幾個(gè)核心假設(shè)：

1. 車商是否愿意花時(shí)間在這些車源上？
2. 車主在沒有價(jià)格保證的情況下是否愿意到店？
3. 車商是否有意愿一臺(tái)一臺(tái)的議價(jià)？

這三個(gè)假設(shè)都是很拿不準(zhǔn)，應(yīng)該堅(jiān)決的使用 MVP 的方式實(shí)驗(yàn)，客戶端增加這部分車源的展示，后臺(tái)可能就是一個(gè)記錄并能導(dǎo)出 Excel 的方式支持任務(wù)流轉(zhuǎn)。

車牌遮擋

我是希望通過圖像識(shí)別，對(duì)平臺(tái)上的車輛的車牌進(jìn)行自動(dòng)遮擋。對(duì)于這個(gè)需求我們希望是：通過系統(tǒng)實(shí)現(xiàn)車牌的自動(dòng)遮擋能夠提升效率。這個(gè)問題的答案其實(shí)是十分明確的，所以我們應(yīng)該直接交付一個(gè)完整的產(chǎn)品，包括自動(dòng)遮擋的流程，以及自動(dòng)遮擋出現(xiàn) badcase 之后的發(fā)現(xiàn)和修復(fù)流程。

02 決策者參與

MVP 其實(shí)是一種授權(quán)要求很高的方法，實(shí)施 MVP ，我們需要一個(gè)可以做決策的人，可以看到《精益創(chuàng)業(yè)》中那些成功的案例無一不是創(chuàng)始人直接參與的。因?yàn)閳F(tuán)隊(duì)中一定存在著信息不對(duì)稱，如果決策者沒有參與進(jìn)來，很可能會(huì)導(dǎo)致 MVP 在一開始就選錯(cuò)了要解決的問題。

因此作為產(chǎn)品經(jīng)理要做好向上溝通的工作，至少確保在四件事情上和決策者達(dá)成共識(shí)：

1. 對(duì)于要解決的問題達(dá)成共識(shí)；
2. 對(duì)于要采用的方案達(dá)成共識(shí)；
3. 對(duì)于 MVP 方案對(duì)品牌和用戶的影響達(dá)成共識(shí)；
4. 對(duì)于 MVP 方案對(duì)合作部門的影響達(dá)成共識(shí)；

03 測試環(huán)境支持

實(shí)施 MVP 最好能有灰度發(fā)布的能力支持，尤其是對(duì)于已經(jīng)有一定用戶量的產(chǎn)品。我們應(yīng)該追求在影響最少用戶的情況下完成需求假設(shè)的驗(yàn)證。

最好的 MVP 是能像 Dropbox 一樣，不用通過線上發(fā)布，只通過 Demo 就能收集到足夠決策的反饋信息。如果一定需要通過線上用戶來實(shí)現(xiàn)反饋收集，那就需要注意兩點(diǎn)：

1. 盡量通過灰度發(fā)布，意即選擇一小部分用戶發(fā)布新的功能，這樣可以在不影響大多數(shù)線上用戶的情況下，獲取線上用戶的反饋。
2. 充分設(shè)計(jì)和用戶接觸的界面和流程，簡化后端邏輯流程，就好我在上面提到的寄售車源的例子就屬于這個(gè)類型。這樣在能在盡量減少開發(fā)的情況下，保證用戶所見的完成度。

04 囈語

最后推薦一本書《設(shè)計(jì)沖刺：谷歌風(fēng)投如何5天完成產(chǎn)品迭代》，因?yàn)?Eric Ries 在《精益創(chuàng)業(yè)》中只是講了 MVP 的概念，并沒有展開講如果要設(shè)計(jì)一個(gè) MVP 的解決方案應(yīng)該如何操作。

我覺得 Jake Knapp 和 John Zeratsky 的《設(shè)計(jì)沖刺》正好是對(duì)這一部分的補(bǔ)充，雖然在這本書中，兩個(gè)作者采用的 設(shè)計(jì)沖刺 這個(gè)新的概念，但是其本質(zhì)也是一種通過最小成本設(shè)計(jì)一個(gè)產(chǎn)品原型，來驗(yàn)證核心假設(shè)的準(zhǔn)確性。

作者：shane；公號(hào)：勰門歪道（xmwd-666）

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