對SaaS產(chǎn)品來說，如何兼顧完善的產(chǎn)品功能與制作產(chǎn)品耗時之間的矛盾呢？SaaS到底做到什么程度才可以正式對外讓用戶使用呢？這對這個問題，筆者給出了自己的思考與解答。

剛剛做完一個SaaS的重構(gòu)，花了一年多的時間，因為新系統(tǒng)的功能必須要大于老系統(tǒng)才行，不然用戶現(xiàn)在使用的功能怎么辦呢，工作都沒法開展了。

但如果是一個全新的SaaS，肯定不能這么做，等系統(tǒng)做大做全了出去賣，且不說這漫長的時間內(nèi)是否已被競品捷足先登了，這也非常不符合MVP，萬一跑偏了，這試錯成本相當(dāng)?shù)拇蟀　?/p>

但如果只做了一點功能就拿出去賣，客戶會用嗎？如何和競品完善的功能PK呢？

不得不思考這個問題：我談?wù)勎业南敕?，如有不?dāng)請指正。

一、核心閉環(huán)已打通

做一點功能就拿出去賣不是說隨便做一點就行，至少要把核心的閉環(huán)打通。

這個核心閉環(huán)怎么定？還是要根據(jù)目標(biāo)用戶的需求來。

1. 定位目標(biāo)用戶的核心業(yè)務(wù)閉環(huán)

我們在做之前都會對系統(tǒng)有個整體的規(guī)劃，比如說我做基層醫(yī)療機構(gòu)的診療SaaS，那診前、診中、診后三大環(huán)節(jié)是一個完整的系統(tǒng)藍(lán)圖。

核心閉環(huán)也就是說，把這里面用戶最急需、使用頻率最高的功能串聯(lián)起來，各角色人員能通過系統(tǒng)完成任務(wù)的流轉(zhuǎn)和協(xié)作。這也是每個SaaS自己的核心靈魂。

比如我們的目標(biāo)用戶是衛(wèi)生所、診所，我們想要取代的是傳統(tǒng)的寫病歷、開處方的his系統(tǒng)，所以我們的核心是診中環(huán)節(jié)：

像診前環(huán)節(jié)：預(yù)約 → 登記 → 分診，以及診后環(huán)節(jié)：隨訪、用藥提醒，下次就診提醒等，是重要的組成部分，但不是核心。

當(dāng)然如果是做專門的預(yù)約系統(tǒng)和隨訪系統(tǒng)，在那個系統(tǒng)里，預(yù)約和隨訪就是主角了。所以系統(tǒng)定位不同，核心環(huán)節(jié)也是不同的。

2. 做哪些功能支撐這閉環(huán)？

我們上面其實只是初步確定了流程的閉環(huán)，但不是完整功能的閉環(huán)，我們都知道，在這流程背后，還需要一些輔助功能和基礎(chǔ)數(shù)據(jù)的支撐。比如接診患者時，需要有病人庫的信息；開處方時，先要錄入藥品信息；收費時，價格也是要提前設(shè)置的。

還有一些系統(tǒng)底層的功能，比如說診所的入駐、管理，用戶的賬號、角色、權(quán)限等。

如果需要員工在手機上操作，C端的功能也是閉環(huán)內(nèi)的一部分，比如藥師掃碼盤點藥品庫存。

完整的功能閉環(huán)一般是要考慮多個平臺和多個終端的，比如說這樣的：

我們不妨先把涉及到的功能點都列出來，然后做減法，比如說運營平臺的功能可以先不做，用戶新增和管理先直接操作數(shù)據(jù)庫。這樣直到功能最簡為止。

二、非核心功能有替代方案

如果用戶用了我們的系統(tǒng)，那其他重要的功能怎么辦呢？比如說有慢病的患者，醫(yī)生會每隔一周詢問下身體情況，他們當(dāng)然希望能通過系統(tǒng)完成，直接通過微信和對方聊天，然后把隨訪的情況記錄到系統(tǒng)里面，這樣方便長期管理。

但我們的功能還不支持，所以我們要先給他們想好解決方案，一般就是這2種。

1. 沿用線下解決方案

很多B端用戶是傳統(tǒng)行業(yè)剛步入信息化建設(shè)，之前都是采用的人工方式，不妨繼續(xù)堅持一段時間，雖然麻煩一點。

像上面的情況，醫(yī)生可以打印出一張隨訪表，每次隨訪后把結(jié)果填寫在表里，拍照傳到病人庫中留檔。熟練電腦操作的，也可以用Excel來做。

2. 打通其他系統(tǒng)

有些用戶規(guī)模比較大，本身就會用好幾個系統(tǒng)，我們就要考慮是否可以和其他系統(tǒng)打通。

比如說診所有個專門的診后回訪系統(tǒng)，那我們是否可以直接通過接口拉取到結(jié)果，記到患者的檔案里面呢？把缺失的功能這樣給補上。

不過這也要看對方的系統(tǒng)是否支持，以及我們打通的成本。

還有個比自動獲取實現(xiàn)簡單的辦法就是，對方系統(tǒng)把結(jié)果導(dǎo)出，我們這邊支持導(dǎo)入。這樣人工工作量也不大。

可以說，核心閉環(huán)的打通和非核心功能能替代解決，這個SaaS已經(jīng)具備了對外售賣的核心條件，但不要著急，下面的2點同樣非常非常重要。一定要準(zhǔn)備充分，不然可能一推出去就慘遭失敗。

三、用戶體驗要做好

B端產(chǎn)品功能是最重要的，但僅靠功能打天下的年代已經(jīng)過去了，用戶對互聯(lián)網(wǎng)產(chǎn)品越來越熟悉，不管是B端還是C端，他們都會進(jìn)行很多橫向的對比。

用戶體驗就是產(chǎn)品的包裝和細(xì)節(jié)，在功能相似的情況下，甚至略有不足的情況下，用戶體驗會是打敗競品的強有力武器。B端產(chǎn)品也在往精細(xì)化耕作發(fā)展。

如果一個產(chǎn)品的用戶體驗不好，給人的第一印象就不好，讓人覺得不用心、不專業(yè)，一旦用戶形成了這樣的想法，后面即使功能再疊加，也很難改變之前不好的印象。

在開始售賣前，不妨多花點精力處理下這些方面：

1. 把頁面布局改的美觀清爽一點
2. 把報錯的提示改的友好一點
3. 把開發(fā)的詞句改成用戶能看懂的語言
4. 把用戶不關(guān)心的字段都隱藏掉
5. 給一些內(nèi)置數(shù)據(jù)及參考案例
6. 完善幫助文檔，建立隨時反饋渠道

四、推廣循序漸進(jìn)

不要著急招大量的銷售，大范圍的開始推廣。我們都知道，一個產(chǎn)品剛上線，不管之前測試用例有覆蓋的多全面，測試人員有執(zhí)行的多一絲不茍，上線后也經(jīng)不住用戶用，而且用戶一多爆發(fā)的問題就越多。如果貿(mào)然推廣，開發(fā)抗不住，用戶評價還差，壞了口碑。

就像很多C端產(chǎn)品一樣，比如微信的視頻號，前期會有個內(nèi)測期，開放給少量的用戶。我們也可以找?guī)准乙庀蛴脩?，先試用起來，最好是比較典型的用戶，這樣他們提出的意見比較具有參考價值，謹(jǐn)防被一些不規(guī)范化和個性化帶偏。

這個試用用戶的數(shù)量怎么定？首先明確意向用戶不等于實際使用用戶，可能我們邀請了10家來試用，真正用起來的就3家，這里面有很多原因，比如說沒有時間培訓(xùn)；當(dāng)前還在用其他系統(tǒng)；先等別的用戶用了再說，等等。前期我們假設(shè)一下這個轉(zhuǎn)化比例，估計不超過50%，后面再根據(jù)實際情況調(diào)整這個比例。

其次，評估下我們的開發(fā)人員能應(yīng)對幾家實際使用用戶的bug和功能優(yōu)化，前期可能就是2-3家。

那么先邀請5-6家來試用，等這一批差不多穩(wěn)定了，再開始陸續(xù)邀請下一批的10家。差不多過這么2-3輪，系統(tǒng)就穩(wěn)定多了，可以逐步擴大銷售范圍了。

五、總結(jié)

能從0到1的打磨一個Saas，看著他1.0版本的上線、內(nèi)測、公測、推廣，直到站穩(wěn)腳，開拓后續(xù)的業(yè)務(wù)。這應(yīng)該是很多產(chǎn)品經(jīng)理的理想，但現(xiàn)實中這樣的機會很少很少。

這是我理解的SaaS第一步推廣要做到的程度：核心閉環(huán)已打通，非核心功能有替代方案，用戶體驗還不錯。

實際驗證時肯定還會有很多細(xì)節(jié)問題，歡迎有經(jīng)驗的朋友指正。

#專欄作家#

司馬特小隊，公眾號：司馬特小分隊，人人都是產(chǎn)品經(jīng)理專欄作家。8年+互聯(lián)網(wǎng)資深產(chǎn)品經(jīng)驗，多年B端產(chǎn)品管理經(jīng)驗。具有多個從0到1的大型B端產(chǎn)品的孵化、重構(gòu)、迭代經(jīng)驗；主要教授產(chǎn)業(yè)互聯(lián)網(wǎng)產(chǎn)品相關(guān)的硬核知識點。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議