我對B端產品MVP的5點感悟(實戰版)

8 評論 9433 瀏覽 58 收藏 15 分鐘

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

關鍵詞:MVP

你有沒有在學過MVP思想后,依然不知道在實際產品中如何去落地?

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

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

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

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

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

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

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

首先,我們先來看看理論中的MVP到底是什么?

一、MVP的概念定義

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

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

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

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

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

二、如何構建MVP產品

那么如何構建一款MVP產品呢?大約5步驟:

第一步:明確產品目標。明確做什么產品?產品解決客戶哪些痛點?能給客戶帶去什么價值?在此之前客戶是如何解決該痛點的?

第二步:梳理用戶流程。圍繞要解決的用戶痛點,定義用戶操作流程,引導用戶達成目標。(這里不要忘了去和客戶溝通,了解客戶對你想法的大致思考)

第三步:定義產品功能。依據流程,梳理出實現用戶目標需要涉及到的功能點。

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

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

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

對于MVP,總結起來一句話,即是:“做最小單位的市場剛需產品,驗證通過,則持續投入;驗證不通過,則迅速調整方向?!?/p>

接下來,我將和你分享下,我在實際做產品中,對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可以是一個當前不存在的產品,只要你能向用戶表達清楚就可以。

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

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

3. MVP中到底哪些功能要保留?哪些砍掉?

關于功能保留與刪減的問題,也是我在做產品中慢慢想明白的。

這里我舉產品中數據對象“復制”的功能。

當時的情況是這樣子的:

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

我們在這塊上投入了很多思考:包括數據對象復制那一刻是復制最新版本還是復制全部狀態(對象有版本概念);若數據對象復制到當前分類內,是否允許復制;數據對象是否可跨產品復制?等等,關于復制的一系列問題困擾著我們。

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

第一:復制功能不是核心功能,以后加也可以?,F在沒有,產品核心流程依然可以跑通;

第二:復制功能要基于用戶場景去設計邏輯,其不是簡單的一個操作功能;

第三:即便復制功能研發出來,也未必是用戶想要的復制形式。

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

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

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

4. 技術無法實現MVP中的功能怎么辦?

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

此時,在MVP中又出現了一個問題,核心功能無法實現怎么破?

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

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

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

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

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

第一:功能是否真的真的真的必須實現,即是不是沒了這個功能產品無法運轉了(評審過后的MVP功能也未必是仔細斟酌的功能,后期看情況是可以調整的);

第二:若功能必須實現,那么考慮是否暫時用替代方案。

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

5. 你的MVP只有你自己知道,多問自己為什么要做它?

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

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

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

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

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

三、最后的話

有句話說:“不要自我設限?!?/p>

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

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

最后,再對MVP做個總結吧。

第一:用MVP不是目的。目的是在最少的時間里驗證你的假設,接著有規劃的去做。

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

第三:MVP需要體現產品的獨特價值主張。不因為現在是MVP而隨意搞(就如不因為他是個兒童,而不關注其長期成長的價值)。它是誰?它要解決什么痛點?它的未來朝向哪里?都是需要去關注的。

#專欄作家#

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

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

題圖來自Unsplash,基于CC0協議

專欄作家

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

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

題圖來自Unsplash,基于CC0協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 看了你的文章我好像又什么都懂了,但工作中總是去接領導不經調研、脫口而出的需求,回到現實我似乎又變得很蠢

    來自北京 回復
  2. 我也是一看mvp的概念覺得很簡單學會了,但是實踐起來確實難以抉擇哪些功能要放哪些不要放到mvp版本中

    來自廣東 回復
  3. 一直認為MVP就是在資源匱乏階段做減法,看完覺得需要改改了。

    來自陜西 回復
  4. 說實話我以為作者要講他在實戰中的mvp使用,結果是通過一些事情后對mvp的感悟

    回復
    1. 那我下次整理一篇MVP的實戰,讓我縷縷,哈哈

      來自浙江 回復
    2. 確實

      來自廣西 回復
  5. 看完突然對mvp有了更深的理解,謝謝分享

    回復
    1. 不客氣呀,很開心對你有啟發

      來自浙江 回復