編輯導語：SaaS是一種基于互聯網提供軟件服務的應用模式，做行業SaaS或其他TOB產品時總會遇到更加復雜和多元的問題，這就是缺少閉環；本文作者根據自身的創業經驗，給我們分享了如何做SaaS產品的MVP，我們一起來看一下。

先跟大家問個好，好久不見，我真的太久沒更新了，主要原因是最近個人狀態有了一個比較大的變化，之前有說到過我從今年開始做自己的公司了；距離上一篇文章有小半年了，上次是第一筆融資到位之前，公司還沒正式成立，有時間寫寫；現在公司走上了正軌，團隊也較為穩定了同時第二筆資金到位，壓力稍微得到了緩解，所以在周末抽出時間來寫寫這幾個月經歷的一些事情。

這個號還是會以產品內容為主，輸出一些我深度的具有獨立思考的內容；不一定是對的，但我希望是能夠觸發讀者思考的，如果內容可以激發大家的討論或辯論就再好不過了。

說正事。

從今年開始TOB被推上風口浪尖，SaaS作為主要的產品形態終于熬到了出頭之日；我在16年就操盤做過SaaS產品，那個時候苦不堪言，商戶沒有付費習慣，資本市場還在TOC業務上砸錢，產品本身也沒有定式，大家都在探索。

我作為產品經理第一次面對SaaS產品也是一臉懵逼，在摸索的過程里我們產品團隊成功的浪費了公司的寶貴資金。

今年我創立自己的SaaS產品后，對資金的投入格外謹慎，在有限資金的壓力下做決策是一個非常鍛煉人的事情，也倒逼我們必須把事情一次做對；因為沒有第二次試錯的機會，一次搞不定可能公司沒了；于是我們不得不更去找到一個TOB的MVP方法，來提高每個產品功能/模塊與市場的匹配率。

一、MVP的核心是求證

沒錯，“求證”才是做MVP的最本質的價值。

我們并不是要為了做一個小產品而做MVP，也不是把一個產品做的很小就是MVP；真正的MVP甚至都不需要做什么產品，所以我們說只要能圍繞著“求證”這件事展開的一系列低成本的驗證方法，我們都可以認為是優秀的MVP。

舉個例子：

我有一個好朋友，她是一名室內設計師，有一天她找我說想做一款可以幫助室內設計師群體快速解決樣板間搭建的系統工具——可以通過組合產品中提供的優質軟裝產品快速搭建出一個設計方案，付一定的費用就可以拿到這個設計方案；并將相應的軟裝產品一并下單購買，做到高效產出設計、高效完成商品采買。

我們拋開這個案例在商業上的可行性，單純的以MVP的視角來分析；如果做這個項目，最應該“求證”的那個關鍵問題是什么？

我們乍一看這個項目需要的維度還挺多，又需要工具，又需要豐富的商品，又需要線上支付，其實這些都不重要。

最終分析下來要驗證的核心觀點非常簡單——就是看看能不能通過組合模板的方式來替代掉室內設計師原有的工作方式，仔細想想沒錯吧。

所以這個點來看驗證方法其實很簡單，可以借助第三方工具，通過表格把模板制作好；涉及到的軟裝商品直接從淘寶選購鏈接貼進來，然后以有贊商城為售賣節點來進行銷售，在設計師群里進行推送和描述；也可以寫一篇公眾號的文章來介紹這樣的工作方式，如果有設計師購買，我們就去淘寶下單；這樣就輕松快速的驗證了，設計師是否接受這樣的全新工作方式。

好了，快速結束這個案例，畢竟聊B端的MVP才是本文的重點，經過上面的案例大家已經對MVP的核心概念達成了共識；但其實這個案例還是比較輕的，往往在我們做行業SaaS或其他TOB產品的時候會遇到更加復雜和多元的問題，比如你會聽到商戶說：“你XX功能都沒有，這個功能我肯定也用不起來”，沒錯這就是B端場景下很典型的問題：“缺少閉環”。

二、B端MVP首要考慮最小業務閉環

什么是最小閉環呢？其實不難理解，一件事有清晰的落點能夠結束就可以簡單理解成閉環，那在TOB產品中，我們的閉環又該如何理解呢？

SaaS產品一定是服務于某些業務場景下的，SaaS產品的某個功能點能夠在特定場景下解決商家工作人員的完整支持操作過程，這就是閉環，但是我們可能面臨一個普遍現象，那就是“閉環過大”。

比如上面舉的案例，如果做這樣的一個軟裝設計師SaaS根本無法落地，這個閉環太大了；所以找到最小的”業務“閉環才是B端產品去MVP的方式。

那如何找到最小的業務閉環呢？

當我們在規劃一款SaaS產品的時候，最容易犯的錯誤就是把一個完整的大閉環誤以為是一個小業務閉環；所以業務閉環是以產品的使用人為單位的，而不是以一家企業為單位的。

我拿長租公寓來舉個例子，我們要看的是長租公寓業態中，運營管理人員的某個業務環節，比如客人的簽約入駐然后激活一系列硬件等等，而不是去看整個公司下的業務流。

聚焦在一個角色下的某一個行為的閉環，就是最小的業務閉環。

這樣我們就得出了一個結論，B端產品是不存在“小步快跑快速迭代”的，最小業務閉環不滿足的情況下，很難驗證需求的準確性，很可能會因為功能的缺陷導致了商家給出不好的反饋結果；我們就誤以為求證失敗，很可能是閉環沒閉住，根本還沒到驗證那一步就被棄用了。

現在我們找到了求證點，做好了最小業務閉環，下一步就是要聊產品了。

三、MVP產品要像“針”

我們都知道，一款好的產品一定是極端值較高的產品，如果一個產品什么都滿足了一點一定不是好產品——這是常識，放到MVP產品上需要把這個點打的更加極致，這也就是為什么說MVP產品是一根針的原因。

產品設計要非常小同時精準，一針扎下去要么扎不透說明沒做對，要么一針見血說明打中了。

我們先來看看TOC和TOB的業務有什么不同——C端面向消費者行為鏈條短，B端面向企業，環節多行為鏈條長；所以做C端產品我們可以通過非常感性的維度去激活用戶從而拿到反饋結果，這個結果往往是數據導向；而做B端就相反了，要做到可靠安全以及合理，這是非常理性的，而且是群體的理智容不得你有半點風險；B端的MVP結果就相對不太容易被數據反映出來，各多的是主觀體驗和主觀選擇。

B端還面臨另一個問題，服務企業需求完全不同，A和B不同B和C不同，A和C也不同，你沒有辦法像服務C端用戶一樣去一個需求解決清一色所有人的問題。

這就需要我們有更強的標準化能力，我們要找到這些企業里我們要做的產品中所求證的那個點下的共有維度。

還有一個不得不提的關鍵字，“成本”我們做MVP的本質就是去求證，如果沒有成本的限制mvp就失去了意義，就不夠精益了；但是我們也不能為了做小產品而去為了小而小，必須要能夠滿足最小的業務閉環。

這里本來要寫個案例的，但是我把我們三個失敗的MVP寫完的時候發現涉及到一些沒辦法公開的內容，所以很遺憾我找不到更好的純TOB或SaaS案例來描述了。

C端的案例很多但是我并不想寫在本文。

四、跨行業創業TOB產品如何做MVP

在跨行業做產品的時候，我們無論如何深入的了解行業了解商家，都一定無法和行業里的資深從業者的認知平齊，那我們有什么好辦法來解決跨行業產品的MVP問題呢？

可以試試“核心用戶倒推法”，我們先透徹了解商戶的運營模式，找到你需要求證問題的最匹配的商家，然后去無腦滿足他們的需求——這個方法很有風險，但是相對比較適合跨行業創業者；這個思想是來自“信任度加權” 是指我們給每個人都需要聽取周邊專業人士的意見，然后在不同維度給不同的專業人士貼上一個權重，在我們決策的時候可以去放棄自己的一些執念，選擇去相信權重更高的人的意見，這樣可以提升整體的成功率。

當一個跨行業創業者去做早期產品驗證的時候，可以采用這個方法——我們把不同的商家在不同的維度打一個權重分，然后在拋出我們要驗證的問題，在各個商家中吸收意見和需求；有的是正向的有的是負面的，然后根據商家的權重分進行對沖，最終會得到一個結論，這個結論大概率不是創業者心中的最佳答案，但它是值得去嘗試的答案。

五、現值與價值是MVP結果的衡量標尺

如何驗證我們的核心問題是不是值得做呢？

從兩個維度來看——現值和價值。

現值是指這個功能在現在市場值得是當前市場中的價值，當下行業中需求可能的確存在；但是是否會隨著市場的發展開始萎縮，我們當下做的這件事情，在未來的發展軌跡上是否還會存在，是不是會被更高維度需求直接覆蓋掉，這就非?？简瀯撌既说臎Q斷力。

價值很簡單可以理解，最近《價值》這本書也很火，我們更多把價值對標為長期價值，也就是相對忽略眼下的利益，把目光放到更長遠的未來——這個是SaaS廠商這一端的視角。

還有一個視角是對商家的解釋，我們都知道商家不會因為你比他的產品便宜一萬塊錢就去選擇那個更便宜的，商家會看誰給我帶來的價值最大化；這個商戶眼里的價值就比較難衡量了，包含降本增效、品牌溢價、或者是單純的創始人喜好，維度太多，我們有個感受就行。

那這兩個維度和MVP的驗證結果有什么關系呢？

我們公司目前還是創業階段，還沒有到可以加碼增長的時候，這個階段的SaaS最大的特點就是需求不完整，商戶無法在你一家得到多個維度問題的解決；那么把單點問題切透讓這一個單點成為行業中最大的價值輸出產品，以這個核心視角去規劃MVP去驗證各類產品功能。

我們拿到求證結果后，就需要做一個對比，現值和價值的對比，完全偏向于長期價值可能會導致早期增長乏力PMF持續跑不通——過于偏向現值會導致經歷分散，大量的MVP被驗證通過，團隊壓力劇增，短期數據可觀但很快到達增長極限，獲客難度也會提高，你發現商戶覺得你挺好但是就是用不起來。

所以去平衡一個求證點帶來結果的現值和長期價值，最好的狀態是結果在我們期望的戰略發展道路上不偏不倚。

六、最后

本文和40萬有啥關系，我們團隊從創立到現在大約花了差不多40萬，我們踩了很多坑，做了很多不能說壞也不能說很好的產品功能。

于是在一個焦慮睡不著的夜里，決定痛改前非，把過往的反思和嘗試總結成了這篇文章，希望可以激發你的深度思考。

作者：張大倫，公眾號：張大倫（ID：zhangdalun010）

本文由 @張大倫 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于 CC0 協議