如何定義B端產品的MVP

2020-12-12 酷扯兒

本文轉載自【微信公眾號:ToB行業頭條,ID:shkxquan】經微信公眾號授權轉載,如需轉載與原文作者聯繫

TO B的產品和TO C的場景有很大的不同,TO B的業務要複雜很多,對比To C需求也要確定很多,除了少數完全創新性的To B產品以外,大多數TO B產品的MVP不是為了驗證需求是否存在,而是讓產品用最小的代價最短的時間面市,從而可以讓產品的研發可以讓用戶需求來進行驅動,避免閉門造車的尷尬以及產品出來之後和客戶期望南轅北轍的風險。

來源/ SaaS產品說 李東林

編輯/ jenny

MVP是Minimum Viable Product的縮寫,意思是最小可行產品,最近幾年在移動網際網路時代,在TO C產品研發以及推向市場的時候,這個概念很是盛行。說說比較有名的二個例子:

一個例子是Zappos,創始人Nick為了證實人們有網上購買鞋子需求的想法,在一開始先到當地的專櫃去拍鞋子的照片放到網上,如果有人下了單,他就跑去店裡購買。這樣,他一開始並沒有倉儲的壓力,也不需要投入成本去搭建一個真正的電商平臺。2009年Zappos被Amazon以12億美元的價格收購。

還有一個例子就是Dropbox, 剛開始創始人也不知道Dropbox是不是被大家所需要,所以先拍了一個視頻,視頻主要是演示Dropbox所能解決的痛點以及使用場景,之後把視頻放到Youtube上面,很多網友通過視頻來到Dropbox網站留言表示了強烈的使用意願,也正是這2分多鐘的視頻為Dropbox帶來了上千萬的用戶。

大家看了這二個例子,是否發現了一個問題,C端產品,特別是一些創新的商業模式因為有很大的未知數,所以前期MVP最重要的目的是驗證需求是否存在,商業模式是否成立?基於這個驗證的需求來實現最簡的MVP,然後慢慢迭代開發演變。

但是TO B的產品和TO C的場景有很大的不同,TO B的業務要複雜很多,對比To C需求也要確定很多,除了少數完全創新性的To B產品以外,大多數TO B產品的MVP不是為了驗證需求是否存在,而是讓產品用最小的代價最短的時間面市,從而可以讓產品的研發可以讓用戶需求來進行驅動,避免閉門造車的尷尬以及產品出來之後和客戶期望南轅北轍的風險。

那麼TO B的產品應該怎樣來定義MVP呢?筆者建議遵循下面的步驟來定義B端產品的MVP。

1、確定產品定位

定位主要要確定三個問題,客戶是誰,用戶是誰,要解決什麼問題。

客戶是誰?

一般來說,有二個維度需要考慮,一個是行業的維度,一個是規模的維度。

行業的維度:如果是支持通用行業,或者只是某個特定行業,所需要的產品功能以及產品採用的設計是非常不同的,如果是通用行業,產品的可配置性要遠遠大於只是針對特定行業,但是針對特定行業的產品可以基於行業特點,設計很多貼身的功能。規模維度:比如說跨國公司,本土大公司,中型公司,小型公司,不同規模,地域的公司所需要的產品功能會有很大的差別。一般來說,大公司的業務複雜度很高,如果將大公司的產品給小公司來用,產品易用性很差,培訓實施周期太長,這些都是中小企業很難接受的。

所以筆者的一個原則,同一個業務,針對不同規模的公司的解決方案,長期來說是要分產品線的,如果不分產品線,是很難競爭過有針對性的競爭對手的。什麼客戶都支持,實際上就是沒有想清楚目標客戶定位。

用戶是誰?

在確定了客戶是誰之後,我們要進一步了解用戶是誰。

比如說人事系統的用戶是HR,CRM的用戶主要是市場和銷售人員,ERP主要是採購人員,銷售人員,庫管人員,如果我們能夠抽象出目標用戶的用戶肖像,包括主要性別,教育水平,喜好,使用系統的場景等,對產品功能定義以及設計會非常有幫助。

比如說人事系統的主要使用用戶是女性,為什麼現在沒有一款人力資源管理系統的頁面風格是偏女性喜歡風格的呢?如果有,一定讓人眼前一亮。

CRM的銷售人員辦公一般處於移動場景中,那麼相關功能在移動端的友好度,就很重要的。如果用戶一直坐在PC面前,移動端就不是那麼重要的。

解決什麼問題?

對於定位的要解決的問題,一定要簡單直接,我們看一些定位相對比較好的例子:

機場掃地機器人

中型企業的招聘管理

中大企業招聘官網搭建工具

零售行業的顧客管理系統

一個原則就是說明文案都是大家都能理解的名詞,不能有需要解釋的名詞,比如說你現在說我要做一個滴滴打人的產品,大家現在能理解,但是如果在滴滴打車出現之前,你說滴滴打人是你的定位,就沒有人能夠聽懂.

現在很多公司在說明自己定位的時候,很喜歡加上新零售,人工智慧,生態,入口這樣的字樣,很多時候讓人越聽越糊塗,這些本身意義很含糊寬廣的字樣會讓其定位更加模糊。

整體來說公司定位需要極其簡潔,不能長篇大論,最好15個字以內,如果太長,請簡化之。

2、確定種子客戶。

在產品正式開發之前,最好可以基於團隊的資源以及產品定位的說明,儘早找到一些符合自己定位的種子用戶(有時候在後期等產品原型設計完成後,再來說服種子用戶)。如果種子用戶很難找到,或者很難被說服的時候,很多時候要反思產品定位以及通過更多的用戶調研,從而找到更精確的公司客群以及產品定位。

最近看到一個可行的獲得種子用戶的方式是幫助其做代運營,筆者看到不少面向餐飲,培訓,房產中介創業做賦能業務的創業公司,前期都是通過線上代運營的方式來開始的。創業公司通過線上代運營快速產生現金流,活下去,同時找到客戶真正的痛點以及操作方式,後面可以再用產品解決方案來將其自動化,這樣的路徑很符合精益創業的理論。

3、確定產品路線

確定種子用戶以後,就可以跟客戶溝通來確定產品的路線,比如說公司的目標定位是對標Workday,或者Salesforce,那麼一口氣開發出Workday或者Salesforce的大部分功能然後上線無疑是很愚蠢的行為,這個時候就要將目標進行拆解,確定產品的演變路徑。

關於MVP的演進路徑,原來網上有一張很著名的圖,如下:

意思說就是如果要造一輛車,MVP的演進路徑應該先造一輛滑板車,然後是自行車,摩託車,然後是汽車之類的。筆者覺得這個在TO C產品是可以這樣設計產品路徑的。如果在TO B產品裡面這樣設計產品路徑,筆者覺得就是滑天下之大稽了。為什麼呢?因為B端產品業務以及邏輯極其複雜,最重要是架構的搭建,如果按照這樣的演變路徑,每一輪產品基本上都是上都要推翻上一輪的產品以及設計,這在B端的產品裡面是不可接受的,從客戶體驗的角度也是不可接受的。

如果還是拿汽車來舉例子,正確的方式可能還是先要有一個可以能動的汽車的框架出來出來,但是很多功能可以缺失,後來再慢慢增加比如說雨刷,多個座椅,轉向燈,後備箱,導航等功能,但是需要保證增加後續功能的時候不能推翻原來的設計。

對於特別複雜,開發周期長的產品,通過巧妙的設計產品路徑,分批上線,從而可以避免閉門造車的尷尬局面以及風險,快速上線產品也能夠給予客戶信心。而這些,對於創業公司都是關係生死的問題。

相關焦點

  • 如何定義B端產品的MVP(下)
    本文轉載自【微信公眾號:ToB行業頭條,ID:shkxquan】經微信公眾號授權轉載,如需轉載與原文作者聯繫「在上一篇文章《如何定義B端產品MVP(上)》點擊文章標題即可閱讀 裡面,我們談到了定義MVP產品的前面三個步驟,確定產品定位,找到種子用戶,確定產品路線
  • 重新定義B端產品
    導語:B端產品到底是什麼?是我做B端以來一直思考的問題;對於這個問題的答案,眾說紛紜,也難斷對錯;今天藉由此文,想把自己階段性的思考結論與各位讀者分享一下,希望通過這個定義,能對B端產品最本質的特點有個精煉的概括。
  • B端產品運營的工作核心是什麼?
    運營究竟走的是產品通道,還是市場通道?從C端運營轉到B端運營,究竟哪裡不一樣了?運營本質上是為了達成什麼目的?那我也嘗試著把運營目標定義如下:運營就是找到需求並通過交換價值提供供給,再逐步擴大規模、站穩腳跟,輔助產品在商業競爭中獲勝。
  • B端產品中,Web端表單如何設計
    編輯導語:B端產品往往由於業務體量龐大,導致信息複雜,同時對業務的精確性的要求很高;服務於B端的業務,不能夠出信息錯誤,填錯一個信息,就會引發巨大的問題。本文結合筆者自己的工作經驗,總結了大型B端業務中表單的設計方法,供小夥伴參考。
  • 如何理解B端業務:定義與特點
    編輯導讀:如何理解B端業務呢?不同人有不同的看法,作者認為B端業務即向組織銷售商品來盈利的事務。看似業務種類眾多,但只要透過現象看本質,往往能很快抓住工作重點。本文作者對此進行了三個維度的分析,希望對你有幫助。我們從事的業務領域是什麼?這是參加工作、創業的首要問題。
  • 如何合理的設計B端產品經理的考核目標?
    如何給B端產品經理設置合理的考核目標,從而激發大家的工作鬥志,為企業或團隊創造價值和收益,並可以科學評估大家的工作產出? 估計這個問題,對很多B端產品管理人員來講,都是一件比較頭疼的事情。
  • 如何準確定義B端需求?先找到關鍵點
    需求定義不準確,程序猿淚崩!(B端)描述產品的某個需求看似是一件很簡單的事情,感覺只要指出具體的事項和產品需要提供什麼就可以了。實則不然,在日常溝通中,我們仍是對很多問題存在爭論。這時候,就要求我們必須轉唄定義產品需求,對問題達成共識。具體如何做?文章對此展開了梳理分析,與大家分享。
  • B端產品,如何幫助企業降本增效?
    各位同學大家好,本次為大家分享的內容主題叫《B端產品如何幫助企業降本增效》,其實這是一個比較大的話題,在這麼短的的時間講透有一定難度的,希望能夠讓大家有所收穫、有所幫助、更能有所思考。首先講一下我們今天分享的幾個板塊:板塊一:明確界定一下B端產品的概念。
  • B 端設計 | 如何掌握 B 端配色技巧?
    https://www.materialpalette.com/colors當然,設計 B 端界面並不是只能使用安全配色,這只是一種建議,可以儘量確保主色,尤其是輔助色使用安全色,而中性色可以自由定義(下面會提
  • B端產品,如何通過活動獲客?
    編輯導讀:對於B端產品來說,通過舉辦活動進行獲客是一個很好的方式,它能夠有效觸達潛在用戶,並達到不錯的觸達率。那麼具體怎麼做呢?如何通過營銷活動快速提升整體獲客效果?本文作者結合案例,對這個問題進行了解答,供大家一同參考和學習。
  • 深入B端SaaS產品設計核心理念
    本文討論「為什麼採用SaaS模式」、「SaaS產品有哪些」以及「如何做好SaaS產品設計」三個話題,核心是產品設計,主要從需求定義、方案設計和開發交付3方面,共計討論10個問題點。一、Why為什麼要用SaaS模式,這個話題我們從面向B端的傳統軟體廠商的痛點來聊。
  • 以C端產品思維和方法做B端產品?
    編輯導讀:近些年,B端產品成為行業的「香饃饃」,市場潛力巨大。很多B端產品經理都在討論,如何在B端產品的建設中,融入C端產品設計的思維和方法。本文作者對此發表了自己的看法,希望對你有幫助。
  • B端設計指南04——彈窗 究竟應該如何設計
    用戶經過十多年的網際網路產品的「培養」,使廣告彈窗變得五花八門,人們應對彈窗,也有了自己的一套方法,相信每一個人都有被彈窗噁心的時候。而彈窗作為人人唾棄的設計形式,卻在B端產品中擁有獨特的一面,看完文章希望你能理解B端產品的彈窗。
  • 全面深度解析B端產品 | 教你如何從0到1設計B端產品的通用方法(上篇)
    (數據來源:Google和百度)從兩大搜尋引擎的檢索結果中,提煉出核心關鍵詞,發現B端產品的設計師關注的高頻問題主要集中在:B端與C端差異、B端產品如何調研、B端產品設計思維、方法、什麼是B端、業務流程、業務。由此可見,對於B端產品的設計師而言,核心訴求主要是關於B端產品what和how的問題,即希望對B端和C端產品有一個更加清晰的認知與理解,以及如何設計B端新產品。
  • 聊聊C端轉型B端產品那些事
    ,有著複雜的權限和邏輯,我們一定要清楚的知道不同角色的客戶對應需要哪些內容,第四深度體驗客戶業務,尤其是線下的業務一定需要我們深入一線,比方說我負責的智能貨櫃業務,需要深入的體驗倉庫是如何入庫採購,補貨員是如何進行補貨的,物流是怎麼流轉的,比方說美業行業,教育行業、超市、餐飲等行業,都需要我們深入體驗客戶的業務,最後就是梳理客戶的業務,通過以上流程,最終需要我們抽象客戶的業務流程,進而形成最終的方案
  • 以B端為綱 產業網際網路的再定義
    原標題:以B端為綱,產業網際網路的再定義   當我們開始遠離消費網際網路的「勢力範圍」,原本的狂熱開始變得理性。
  • B端產品如何做好業務流程梳理?
    對於B端產品經理來說,梳理好業務流程的重要性不言而喻,那麼具體怎麼做呢?筆者將為我們帶來答案。業務流程梳理是B端產品經理常常要面對的工作,雖然可能有的公司前面有流程部,但是事實證明,流程部往往是梳理不出完整而準確的流程的,這事就不可避免地落在產品經理頭上,流程梳理不清楚,邏輯往往混亂,場景往往遺漏。你不把流程畫好,開發測試人員也很難全面的理解你的設計方案。
  • 套路分享:B端產品經理如何試用競品?
    與C端產品不同,B端產品的試用門檻很高,導致產品經理在了解、體驗競品上有不小的障礙。而筆者就結合實踐經驗,和大家分享如何確定競品、如何套路試用競品。競品分析是產品經理的必備技能,做好競品分析對市場定位、產品規劃、產品設計都大有好處。競品分析的方法論已經有很多文章介紹,也有很多成熟的方法論,比如用戶體驗五要素、商業畫布、波特五力模型、PEST分析等等,這裡不再展開。對於B端產品經理來說,方法論不是問題,最大的問題很多時候在於我們很難去真正了解和體驗競品。
  • B端產品經理必知的底層實踐認知有哪些?
    前段時間撰寫了《B端產品經理必知的底層概念有哪些?》,從用戶、用戶價值、產品定義、交易成本,分析了B端產品經理需要建立概念層的認知。眾所周知,知行合一併不容易,將概念理解到落地仍有很長的路要走,本篇主要從B端產品經理落地實踐角度,所需要具備的認知,從而更好實現從概念到價值的落地。
  • B端產品與C端產品建設流程的區別
    來源/ goYangKun 楊堃編輯/ jennyB端產品和C端產品建設流程對比從圖中可以看出,B端和C端產品的建設流程很大不同,具體體現在如下方面。但是在選取最小功能集合(或最小可行產品)時,B端和C端產品的區別很大:B端產品要支持業務整體運作,所以在選取最小功能集合時,即便再簡化,也要保證一個核心業務流程的運轉,因此B端MVP往往是一個具備一定複雜度的系統,不可能是一個或幾個功能點。