現在的產品還有MVP嗎？

產品經理在日常工作中可能時常要接觸MVP概念，因為在實際業務里，產品經理需要通過拆解MVP來驗證產品的可行性。那么，這類MVP思想或者敏捷迭代的思想，是否適用于大型B端項目或者傳統IT項目？小步快跑、快速迭代的概念在什么場景下還能適用呢？

01

最近在復盤梳理內部的一些產品發展歷程，發現有一段時間我們的產品迭代流程特別有意思。

(資料圖片)

我目前在一家以卷和快速迭代著稱的互聯網公司，做一款傳統行業中各類線上化工具都很成熟的一個行業新產品。當時有一家和我們深度合作的公司，歷史用的另外一家行業內知名度和成熟度很高的產品。出于戰略的一些訴求，我們不得不將僅研發了三個月的軟件給到這家公司使用，當時整體的產品完成度只有10%不到。

而我們要面對的用戶群體，是一群線下作業場景復雜，綜合素質比較一般的用戶群體。可想而知，硬著頭皮上的結果就是所有人都很累。

在做一個B端產品的時候，首先要考慮的是，如何將一個產品做的符合業務訴求，達到降本增效的目的。而當時的我們，不僅沒有達到這個目的，反而因為系統的不完善，額外給我們的用戶群體增加了許多麻煩。

比如，當時需要用戶在錄入某些信息的時候雙系統錄入，某些業務流程在兩個不同的系統之間切換。與此同時，我們也面對著大量的吐槽，諸如為什么系統不完善就讓使用，之前的系統那么好用為什么要切換。這個系統是多么多么的爛等等。

再后來，因為系統的不完善，我們把這個試用階段拖得很長。為了讓這家公司更早的用到我們自己的產品，我們除了在瘋狂的加班趕產品的同時，還需要改一些之前為了讓他們更好的試用做的一些臨時的邏輯或者功能。而這些功能，本來是不需要做的。

那最終的結果如何呢——這段長達半年的試用期，對我們產品的改進沒有任何的作用。

主要是幾個原因：

那這次試用有沒有收獲呢，肯定也是有的，讓我們知道了做這么一款復雜的產品，草率的試用，不僅影響客戶的體驗，也影響我們的工作狀態。

回過頭來再看這段經歷，會發現當我們以一個互聯網敏捷迭代的視角去看某個大型B端項目的從0到1 的建設，這種設想本身就有很大的問題。

一個傳統行業的復雜IT項目實施可能是需要經過數年的研發，以及詳細且周密的項目實施流程才能完整的交付。而所謂的敏捷迭代或者MVP的思想，完全不適用于這種場景。

02

一個產品經理的基本能力不就是如何拆解MVP，來驗證產品的可行性么。那為什么我會說現在的產品已經沒有MVP了。

其實還是現在的互聯網行業，垂直賽道的SaaS行業太卷了。目之所及，都是紅海。你所能想到的點子，基本上市面上都有著可以參照的競品。當你希望以最小可行性方案去驗證市場時，你會發現市場上充滿著比你功能完善，價格還優惠，實施流程還貼心的產品。你會發現你一個粗糙的產品根本沒有出路。

所以這個時候，所謂的差異化競爭，是在你必須具備基本的閉環邏輯下之外的競爭。半成品的產品，基本沒有出路。你說你某個功能做的特別好，體驗最佳，行業頂尖。但是這個產品該有的其他功能都很粗糙。那不好意思，基本上不會有人買單。

03

不僅是B端，在互聯網產品以及軟件行業高度發達的今天，任何產品都面臨著這樣的問題。

我比較喜歡研究一些筆記類的軟件。市面上的很多筆記軟件都使用過。我很多產品，很多功能都逐漸趨同。比如，當notion大火后，各大筆記軟件基本上都跟進了notion的一些產品思路。比如以塊的形式作為承載形式。“/”鍵可以新增內容等等。除了一些像素級一樣的軟件某lai，某us等，語雀和飛書這種本來體驗就不錯的協同文檔類的軟件也跟進了這種交互。

作為一個筆記類的軟件，難道不能能寫，能記錄就可以了嗎。這種能力，明顯不是一款筆記軟件的基本能力，不符合一款產品最小可行性方案的邏輯。但如果你沒有這些，你可能剛投入市場就失去了很多的競爭力。這也是為什么，最近幾年雖然各類筆記軟件層出窮，但恨不得一出來就給你一個王炸，各種知識網絡，多維表格等等功能一股腦的全部都整上的原因。

04

那什么場景下，這種小步快跑，快速迭代的思路還適用呢？

從單獨產品的視角來看，我覺得很難有出路了。需要以一個另外視角去看。你能給你的客戶帶來哪些新的價值。這些價值如何能轉化成產品的一些能力，以及你所能提供的服務是不是獨一無二的。

我曾經在一家外賣公司做過一段時間的企業服務。當時我們提供給客戶的第一版產品也很粗糙。基本上只可以點單，充值，對賬，開票等等這些都不滿足，只能線下操作。

但我們還是談了幾家客戶。因為在當時的那個階段，只有我們能給他們提供這種服務。不僅如此，在和他們簽約的時候，我們還沒有開始研發產品，一切從零開始。

回到第一個例子。為什么我們當時的產品那么爛，客戶還是在半成品的情況下試用我們的系統并且最后硬著頭皮切了呢。其實也是因為這次合作我們不僅僅賣的是軟件，還是一整套的服務體系，這個產品只是其中的一項。我們帶給他的收益，要遠高于切系統的成本。且需要和我們合作，就必須得切系統。

所以這個時候，MVP已經不是單獨站在產品的視角了，而是一整套服務體系。你能提供給客戶的服務是什么，這個服務下，有哪些環節的必須的，這些必須的環節里面，軟件服務是不是必不可少的一環，沒有軟件能不能走的下去。

這兩個例子下，點餐服務場景中，最小服務閉環是，我可以點餐。這個即是我服務體系的MVP，所以只要我提供了一個點餐系統，你這個服務系統就可以運行起來。

提供作業系統的這個場景下，最小的服務體系是我們所提供的一種交易模式，這種模式短期可以先通過臨時的方案跑著，而為了更精準和更及時的監測到我們的收傭，以及通過一些產品能力去賦能客戶，軟件是我們可以逐步迭代的一個能力。所以這個時候，產品將不再是這個服務體系內的MVP，而是到了某個階段必須要用到，不可或缺的工具。這個時候，我們根本不需要去驗證它的市場反饋程度。因為MVP已經走完了。

C端的邏輯也是一樣的，當一個抖音跑出來了，用戶需要的不是另外一個抖音，而是能給用戶提供不一樣服務的短視頻產品。騰訊連續上了十幾個類抖音的APP都沒有成功，反而最后的視頻號有了一些起色。那是因為在和微信以及公眾號的深度結合中，視頻號找到了自己差異化的定位。

如果以傳統的MVP思路，騰訊的十幾個短視頻APP都沒毛病，快速的投放一些產品驗證市場。但這樣，只能被市場淘汰了。

專欄作家

張哈哈，微信公眾號：張哈哈同學，人人都是產品經理專欄作家，B端產品經理，深入SaaS及企業服務領域多年，關注數碼和新能源。

題圖來自 Unsplash，基于 CC0 協議

責任編輯：Rex_21