b端産品經理如何定義産品的mvp?編輯導語：或許你會遇到學完MVP之後但是在實際運用中卻無從下手的情況，遇到這樣的情況應該如何解決呢？作者總結了其在B端産品MVP實踐中的5點感悟，與你分享，今天小編就來說說關于b端産品經理如何定義産品的mvp?下面更多詳細答案一起來看看吧!

b端産品經理如何定義産品的mvp

編輯導語：或許你會遇到學完MVP之後但是在實際運用中卻無從下手的情況，遇到這樣的情況應該如何解決呢？作者總結了其在B端産品MVP實踐中的5點感悟，與你分享。

關鍵詞：MVP

你有沒有在學過MVP思想後，依然不知道在實際産品中如何去落地？

對于哪些功能可以歸屬在MVP中，哪些不應該歸屬在MVP中，不知如何下手？

剛開始，我以為我學完MVP理論就已經懂了MVP，而實際上并不是如此。

一方面，在實際工作中，總想一次性做個完美的産品出來，給客戶“哇”的感受。

另一方面，研發時間緊張，根本沒時間思考MVP的事兒，隻想快速梳理出一堆功能，試圖趕緊開發完。

直到我在自己負責構建一款0-1的産品時，我發現我不懂MVP，我無法靈活地應用它，以緻于沒辦法在關鍵時刻給出合理的結論。我深刻地感知到“紙上得來終覺淺，絕知此事要躬行”。

今天，我想和你分享下我對MVP的一些感悟。因為在MVP模式的指導下，我們的産品在半年後不僅有了種子客戶，驗證了産品的可行性；還獲得了公司内部比賽的優勝獎，這是大家對我們産品的認可和鼓勵。

這也讓我在實踐MVP的過程中，對什麼才是可行的MVP産生了新的思考。

首先，我們先來看看理論中的MVP到底是什麼？

MVP全稱是Minimum Viable Product，也就是最小可行性産品，這是埃裡克·萊斯在《精益創業》這本書中提出的理論。

在MVP産品設計理論指導下研發出來的産品具有功能極簡、可被使用、開發成本低、适合快速叠代等特點。

産品以低成本快速實現核心功能後，順勢推向市場，交給用戶去驗證産品的可行性，通過用戶訪談等方法獲取用戶使用的體驗反饋，基于此快速叠代産品。

在我的書籍《B端思維-産品經理的自我修煉》中，我也提到過，如何在确定最小可行性範圍？我們可以遵循以下原則：“少了某些功能，産品就無法正常使用，這些功能要做。多了某些功能，産品沒有使用起來更好，且又增加開發成本，這些功能不做。要做滿足用戶剛剛好需求的核心功能點。”

MVP相比原始的瀑布式研發流程來說，可以規避團隊辛辛苦苦研發完一款産品後，推向市場，市場不接受的情況。這會嚴重浪費資源、時間與金錢。

那麼如何構建一款MVP産品呢？大約5步驟：

第一步：明确産品目标。明确做什麼産品？産品解決客戶哪些痛點？能給客戶帶去什麼價值？在此之前客戶是如何解決該痛點的？

第二步：梳理用戶流程。圍繞要解決的用戶痛點，定義用戶操作流程，引導用戶達成目标。（這裡不要忘了去和客戶溝通，了解客戶對你想法的大緻思考）

第三步：定義産品功能。依據流程，梳理出實現用戶目标需要涉及到的功能點。

第四步：功能優先級排序。根據研發資源、交付周期等情況，對功能進行排序與删減。

第五步：繪制原型圖。完成碎片化功能到一個可滿足客戶痛點、剛需的原型圖。

基本上到此，我想你對MVP有了概貌性的了解。

對于MVP，總結起來一句話，即是：“做最小單位的市場剛需産品，驗證通過，則持續投入；驗證不通過，則迅速調整方向。”

接下來，我将和你分享下，我在實際做産品中，對MVP的一些感悟吧。

1. MVP一定要研發出來嗎？一個高保真原型算不算？

這個問題我在帶團隊研發産品中思考了不下數次，即，高保真原型算不算一個MVP？我也問了一些小夥伴，基本沒有明确的答案。

為什麼我會思考這個問題呢？

因為我在帶團隊研發一款産品的時候，研發資源不夠，這就不得不促使我去思考一個問題：如何才能在開發中胸有成竹，每開發一個功能不是懷疑，而是盡可能自信。

因為資源甚少，我不希望把資源浪費在任何一個地方，一定要打到實處。

每一步都要走穩，才可以用時間換取最大成功的可能性。

後來，我看到Zappos的MVP做法後，我的思路被打開了。

Zappos是一家賣鞋子的網站。起初，創始人有個想法，想從事鞋類零售。但是假如他先拿貨，再去賣，就會出現庫存的情況。于是他放了鞋子的照片在網站上（實際上他沒有鞋），如果顧客拍下了鞋子并付款了，他就會去購買鞋子，從而出售。

我想，或許MVP不應該是理論上的，而是基于你實際情況的。

後來，我覺得可以試試通過用原型的方式去展開我們産品的MVP。

我在啟動與客戶交流之前，完成了“業務流程圖”、“用戶行為路徑”、“界面流程圖”的梳理，然後約上客戶，進行一對一溝通。

他們在面對以上可視化内容後，對我們團隊将要做的産品就基本很清晰了，因此毫無保留地給出了他們的期望、需求、思考、想法，我也逐一進行了記錄（真的是寶貴的資産）。

雖然是原型化的MVP，但說真的，已經可以測出客戶的痛點、需求、偏好。

将原型作為MVP，是非常好的低成本驗證方式，屢試不爽。

2. MVP一定要研發出來嗎？一個說的清楚的idea算不算？

為什麼我忽然想到這個了呢？

因為在問題1中，我發現了MVP可以是一個原型後，我就在想，是不是其也可以是一個idea。

後來，我發現了Dropbox，我的疑問迎刃而解。

Dropbox的MVP産品是一個假裝準備好了産品的視頻（是不是有點出乎意料）。該視頻用來檢驗他們期望文件能在不同端上同步的想法，用戶是否也同樣喜歡。于是，創始人Arash Ferdowsi 和 Drew Houston設計了一段idea視頻，而該視頻在幾個小時候被瘋狂傳播，并且他們收集了很多用戶對此的想法與興趣。于是，Dropbox就被研發出來了。

可見，MVP可以是一個當前不存在的産品，隻要你能向用戶表達清楚就可以。

所以後來，我會帶着一些想得比較清楚的想法，直接去和客戶聊，看看他們是如何看待這個問題的。

雖然客戶不能給你答案，但是可以啟發你的思路。

關于功能保留與删減的問題，也是我在做産品中慢慢想明白的。

這裡我舉産品中數據對象“複制”的功能。

當時的情況是這樣子的：

我們産品中有一個頁面，是對某種類型的數據進行管理，但這些數據對象會有被複制使用的情況。（試想下，你隻想稍微修改下某篇文章的标題，發給另一個人，你會選擇複制編輯，還是重寫。我想大部分人都會采用複制去處理吧。）

我們在這塊上投入了很多思考：包括數據對象複制那一刻是複制最新版本還是複制全部狀态（對象有版本概念）；若數據對象複制到當前分類内，是否允許複制；數據對象是否可跨産品複制？等等，關于複制的一系列問題困擾着我們。

最終在MVP中，我砍掉了此功能，有以下三個原因：

第一：複制功能不是核心功能，以後加也可以。現在沒有，産品核心流程依然可以跑通；

第二：複制功能要基于用戶場景去設計邏輯，其不是簡單的一個操作功能；

第三：即便複制功能研發出來，也未必是用戶想要的複制形式。

以上，讓我決定聚焦核心功能，在MVP中把一切想不明白，又不确定用戶是否會真實需要的功能砍掉了。

我想，MVP中到底哪些功能要留下，哪些可以砍掉。一方面看核心流程是否因為此功能沒有依然可以跑通；另一方面要看是否為必備功能（參見KANO來篩選）。

2011年微信1.0版本發布，就是MVP的典型應用。那時候的微信隻有4個功能：設置頭像和微信名、發送信息、發送圖片、導入通訊錄。

由于我們的産品比較特殊，有些功能實現起來确實難，就會阻礙MVP的展開。

此時，在MVP中又出現了一個問題，核心功能無法實現怎麼破？

我舉個例子。在我們的産品中需要使用到AI功能，但目前我們沒有相關技能的人員，那功能如何實現呢？

于是我又想到了Zappos的MVP案例。我用其他技術方案替代了AI，先讓産品流程跑通。

因為關于你産品的某個功能是不是AI實現的，其實用戶壓根不關心。用戶的訴求就是能用、好用。

因此，我們産品的MVP中，關于AI的技術方案都用普通技術手段先去實現了。

其實，MVP中功能不能實現可以分兩方面考慮：

第一：功能是否真的真的真的必須實現，即是不是沒了這個功能産品無法運轉了（評審過後的MVP功能也未必是仔細斟酌的功能，後期看情況是可以調整的）；

第二：若功能必須實現，那麼考慮是否暫時用替代方案。

我始終相信，方法比問題多，沒有解決不了的問題，隻有你是否有想解決它們的堅定的心。

我在做産品中，試圖去問過其他人，某些該怎麼做，如何做更好。這個在MVP中要不要出現，那個在MVP中要怎麼設計。

但最終發現，其實還需要回過頭來多問問自己，隻有你自己才知道你的産品價值主張是什麼。未來要發展成什麼樣子。想去幫助客戶解決什麼痛點。為他們帶去哪些價值。

我記得做第一個産品的時候，就沒有考慮過MVP。小夥伴們也沒有意識，那時候資源多，也就做了。

做第二個産品的時候，因為資源真的極度匮乏，不僅人少，還要求快速出結果。

所以，我不得不去考慮MVP，并在實踐中調整。

有句話說：“不要自我設限。”

嗯，我覺得任何事情都一樣，不能設限。我們也不要給MVP設限。

時代在變化，MVP也在進化。

最後，再對MVP做個總結吧。

第一：用MVP不是目的。目的是在最少的時間裡驗證你的假設，接着有規劃的去做。

第二：MVP可以不是一個讓用戶去鼠标點點操作的産品，任何能說清楚産品價值的對象都可以成為MVP（要達到可驗證的目的）。比如投票調研、衆籌方式、看似真産品的假産品（如上“Zappos的MVP”案例）。

第三：MVP需要體現産品的獨特價值主張。不因為現在是MVP而随意搞（就如不因為他是個兒童，而不關注其長期成長的價值）。它是誰？它要解決什麼痛點？它的未來朝向哪裡？都是需要去關注的。

#專欄作家#

知果，公衆号：知果日記，人人都是産品經理專欄作家。浙江工商大學品牌設計專業碩士，《B端思維-産品經理的自我修煉》作者。在産品設計流程、産品設計原則、産品設計方法、産品設計規範方面均有豐富經驗

本文原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!