本文探討了在構(gòu)建最小化可行產(chǎn)品時，應(yīng)該如何思考產(chǎn)品的范圍，進(jìn)一步有效控制產(chǎn)品開發(fā)成本和時間。

任何在過去五年中從事軟件開發(fā)工作的人，都可能聽說過MVP（Minimum Viable Product，最小化可行產(chǎn)品）一詞。

如果您是負(fù)責(zé)用戶體驗的，那么您經(jīng)常會對這三個字母感到沮喪?？赡苁且驗槟ǔＴ陧椖拷Y(jié)束時遇到它們，比如有人會這樣說：“這是個好主意，但我們現(xiàn)在沒法做。先發(fā)布一個MVP，以后再添加它?！边@成為一些人的說辭，即使并沒有未來迭代的計劃。

這個本來可以幫助我們快速打造客戶喜愛的產(chǎn)品的概念，反而成為了發(fā)布并不優(yōu)秀產(chǎn)品的借口，這不是很諷刺嗎？

最小可行產(chǎn)品的最常見定義是，產(chǎn)品具有足夠的功能足以滿足早期客戶的需求，并為未來的開發(fā)提供反饋。

不幸的是，有時這種說法會被誤解，團隊認(rèn)為構(gòu)建“剛剛好”的產(chǎn)品意味著純粹專注于功能。然而，產(chǎn)品不僅僅等于是功能的堆砌，不能只是發(fā)布有一些功能的產(chǎn)品，然后等待下一次迭代再使其可用。用戶的信任是非常脆弱的，一旦被打破，就很難重建。

下面的模型最初由Jussi Pasanen提出（后來成為關(guān)于該主題的任何博客文章的產(chǎn)物），該模型解釋了如何在盡快使用戶獲得產(chǎn)品的同時不讓用戶失望。它建議您應(yīng)該在每一層上創(chuàng)建最小的塊，而不是逐層構(gòu)建。

任何MVP都必須具有一系列為用戶提供的價值特征：足夠的價值，贏得用戶信任的可靠性層，以及用戶不必過多地理解產(chǎn)品設(shè)計的可用性層，和可以獲取到一些歡樂的頂層部分。

構(gòu)建最低可行產(chǎn)品的方法：建立一個切片，而不是一次構(gòu)建一個層（來自Jussi Pasanen的圖表）。

缺了點什么？

這張圖還很好地表達(dá)了另一個觀點：產(chǎn)品層是堆疊在底層的，如果您擴展了一層的范圍，則需要增加它上面所有層的范圍。

例如，添加的新功能越多，就需要更多的工作來保持產(chǎn)品的可靠性和易用性。如果想要縮小范圍，最合理的起點是這個金字塔的基礎(chǔ)——功能。

那么應(yīng)該要包含哪些功能？如何進(jìn)行決定？我知道您的“UX觸覺”（譯者注：原文為‘蜘蛛俠的觸感’）現(xiàn)在開始感覺到了什么。

我的也一樣，直到我意識到“功能層”并非這座金字塔的真實底層。上圖僅涵蓋了產(chǎn)品本身的特征，但產(chǎn)品并非存在于真空中。我們構(gòu)建它們是為了幫助希望對我們所提供的價值給予回報的人們，產(chǎn)品的真正基礎(chǔ)層應(yīng)該是受眾及其需求。

縮小受眾范圍

假設(shè)我們需要一種能夠為用戶解決問題X的產(chǎn)品，我們應(yīng)該為哪部分用戶構(gòu)建MVP的來驗證我們的方法？

有關(guān)項目范圍的討論應(yīng)該由此驅(qū)動：

選擇“產(chǎn)品的受眾”（誰將在最初階段從產(chǎn)品中獲得最大的價值），并向其他所有人說“不”（或“現(xiàn)在暫時不”），最能顯著縮短開發(fā)時間。產(chǎn)品的受眾范圍越廣，其需求和問題就越多，必須構(gòu)建的功能就越多，產(chǎn)品將變得越復(fù)雜和難于使用。

沒有什么比劃定“受眾”范圍，更能顯著地減少開發(fā)時間了。也有人這樣說，您的MVP不一定要像最終產(chǎn)品那樣酷，但是使用它的體驗仍然應(yīng)該令人愉快：“汽車的MVP是三輪車，而不是四個車輪?！?/p>

受眾范圍越廣，需求和問題就越多，產(chǎn)品將越復(fù)雜。

但是，仔細(xì)看看這個MVP的本質(zhì)，就會發(fā)現(xiàn)它與最終產(chǎn)品的最大區(qū)別在于它所服務(wù)的用戶的廣度。

汽車適合所有人，老少皆宜，無論是獨自旅行或成群結(jié)隊旅行，還是上下班通勤或拼車前往下一個城鎮(zhèn)。但是，三輪車專門滿足幼兒的運輸需求。

對用戶進(jìn)行細(xì)分，并選擇要滿足的每個細(xì)分市場的需求，可以讓您的團隊事半功倍地為這些用戶創(chuàng)造出色的體驗，并且得到他們的喜愛。

當(dāng)您縮小金字塔的底層時，其他每一層也會縮小。

了解用戶的期望

讓我們回到金字塔，看一看橫切所有層次并將“最小值”與產(chǎn)品其余部劃分開的那條線。它很重要，因為它概述了您的工作范圍。

如何知道在哪里畫這條線？

我認(rèn)為這條線代表了用戶的期望，無論選擇哪種受眾群體，他們都會對產(chǎn)品是什么、應(yīng)該做什么有自己的看法，不應(yīng)該辜負(fù)他們的期望。

MVP的范圍基本上取決于產(chǎn)品受眾和他們的期望。

認(rèn)識到用戶想要什么與期望什么之間的差異至關(guān)重要。

“期望”是人們認(rèn)為某事應(yīng)該如何運作的方式，而“想要”是人們對當(dāng)前事物狀態(tài)進(jìn)行改進(jìn)的愿望。缺少想要的東西可能是不好的，但不能達(dá)到期望可能是一場災(zāi)難。

例如，如果通常的上班通勤時間是30分鐘，那么您會期望明天花的時間差不多。

人們會想要縮短旅行時間嗎？

當(dāng)然！但是大家都知道并不一定總能得到想要的東西。然而，如果您的電車明天晚15分鐘出現(xiàn)，而乘車時間變成45分鐘，您可能會暴跳如雷。

不僅是MVP版本，任何產(chǎn)品都不可能滿足所有用戶的愿望，什么產(chǎn)品都總是有改進(jìn)的空間。但是，當(dāng)您的產(chǎn)品達(dá)不到用戶期望時，這是一條快速的失敗之路。在嘗試確定用戶期望時，應(yīng)牢記一些注意事項。

用戶的期望來自于他們對類似產(chǎn)品的體驗

只要沒有開發(fā)出絕對新穎的產(chǎn)品（例如飛行汽車），就必須考慮競爭對手（甚至是間接競爭對手）提供的體驗。如果他們可以立即同步用戶數(shù)據(jù)，而您的應(yīng)用程序會延遲4小時就完全不及格了。它可能會迫使您在圖上向右移動劃線，擴大項目的范圍。

用戶的期望基于現(xiàn)代標(biāo)準(zhǔn)

十年前，您可以開發(fā)一款只能在臺式機上使用的產(chǎn)品，但如今，必須能在移動設(shè)備上對其進(jìn)行訪問。

如果產(chǎn)品無法在移動中為用戶提供支持，那么按照今天的標(biāo)準(zhǔn)，該產(chǎn)品可能就無法獲得“可靠性”標(biāo)簽。

用戶的期望基于他們今天使用的解決方案

我很喜歡Jared Spool在他的博客中關(guān)于用戶期望的示例。他的團隊在Google Spreadsheets上進(jìn)行了可用性研究，并觀察到當(dāng)簿記員找不到雙下劃線時，她就會感到非常沮喪。

她可以使用普通的單下劃線嗎？理論上當(dāng)然可以。但是，電腦和電子表格出現(xiàn)之前，人們就已經(jīng)在使用雙下劃線了，通過限制MVP的范圍并不是一個忽略它的充分理由。

總結(jié)

• 構(gòu)建MVP并不是單純削減功能，而是劃定最小的受眾群體，為他們構(gòu)建最低可用的產(chǎn)品范圍。
• 縮小用戶類型的范圍將會大有幫助，因為它將減少產(chǎn)品必須滿足的需求。
• 受眾對產(chǎn)品的期望將定義產(chǎn)品的范圍，理清這些用戶期望，幾乎就可以明白要做些什么了。

本文譯自Andrey Gargul 的The thing that’s missing from your MVP，作者是Shopify的用戶體驗設(shè)計經(jīng)理。

本文由 @海外設(shè)計參考 翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

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