本文作者以親身經(jīng)歷為例，回顧了自己在B端SaaS化過程中遇到的問題以及經(jīng)驗，與大家分享。

一、抽象化處理需求是悖論

這是書籍和經(jīng)驗造就的坑坑。

在很多的書籍或者方法論中，認為SaaS產(chǎn)品應該實現(xiàn)標準的需求，當遇到個性化需求的時候，要把它抽象化，抽象成很多企業(yè)可以共用的樣子。

開始的時候我信了，數(shù)十次碰壁之后我發(fā)現(xiàn)，這可能也是中國沒有一個可以走向世界的SaaS產(chǎn)品的原因原因之一。

聊聊第一個坑：我們做To B的SaaS服務，有一天，一個客戶跟我說，我要看我們公司不同門店的數(shù)據(jù)，你幫我處理下吧。

那時候使用系統(tǒng)的基本都是餐飲類企業(yè)，調(diào)研了多家企業(yè)又分析了競品，發(fā)現(xiàn)這是個標準需求呀，我們挺高興，在系統(tǒng)里增加了一個“門店”的標簽。

好多用戶反饋，你們這個功能好呀，我都能按門店查詢啦，再也不用導出來一點點對賬啦……

隨著業(yè)務發(fā)展，慢慢接入了好多房地產(chǎn)行業(yè)的用戶，客戶說，我得按小區(qū)統(tǒng)計數(shù)據(jù)，你們支持嗎？

我們一看，這跟門店不是一個意思嘛，問人家門店行不行，客戶說：我是小區(qū)，不是門店。

我們想，書上說了，要抽象，專門開了10次會議討論，終于確定了一個詞“業(yè)務類型”。

那時候覺得自己特牛，終于可以支持多個行業(yè)場景啦。什么餐飲門店、物業(yè)小區(qū)、建筑項目、不同業(yè)務線，都往上靠吧！

然后，業(yè)務又發(fā)展了，有了更多的合作伙伴，更多的行業(yè)使用這個產(chǎn)品。

于是，每天每天，電話、微信群、面對面會議，總有人問“業(yè)務類型”是什么呀？怎么用呀？

在同一個人第80次問我的時候，我哭了。邊撓桌子邊問：“姐，我如果讓它叫門店你能理解嗎？”

東北小姐姐扯著嗓門說：“那有啥不理解的呀，你早這么叫我都不問你?！?/p>

除了跪下，我還能怎么辦……

這時候我不得不想，抽象，是不是錯了。

如果同一個概念，門店就叫門店，小區(qū)就叫小區(qū)。

在客戶使用系統(tǒng)前，選擇下行業(yè)，系統(tǒng)根據(jù)行業(yè)區(qū)分后顯示對應名詞，是不是這個溝通和學習成本就沒這么高了？

或者，還有哪些更好的方式，能即使用客戶常用的名詞，系統(tǒng)又能兼顧不同情況呢？

SaaS化，到底是把客戶的需求抽象后實現(xiàn)，還是直接實現(xiàn)客戶的需求，系統(tǒng)通過靈活的配置兼容多場景，低學習成本推廣呢？

我傾向于后者。

這篇文章從寫完到發(fā)布，經(jīng)歷了大約一個月左右的時間。

我在網(wǎng)絡言論方面，是個膽子有點小的人，對于這種理論與實踐沖突比較大的情況，總想多方位的求證，在不同的場景和行業(yè)里得到證實之后，才敢胡說八道。

在求證過程中，我發(fā)現(xiàn)有太多太多名詞無法理解，因為用詞不一致導致大量無效溝通甚至產(chǎn)品推進難度大的情況。

究其原因，是大家在常識方面不一致。

常識，讓有些人心有靈犀，默契自成；常識，也讓一些人，說著同一種語言卻無法溝通。

不同地區(qū)、行業(yè)、職業(yè)、教育背景、原生家庭甚至不同性別的人，都各自有自己的常識。這些在C端產(chǎn)品中備受重視的客戶細分，到了B端，因為業(yè)務的復雜性，有時候會被無意識的忽略。

尊重對方的習慣的時候，同樣獲得尊重。不論是人還是產(chǎn)品。

而抽象，屬于一種融合，是進行了深入理解甚至邏輯處理后的結(jié)果。首先挑戰(zhàn)人的習慣，其次挑戰(zhàn)人的惰性，再次考驗人的記憶力和理解力。

遇到類似問題時，多想幾套方案，不局限于抽象，不拘泥于常識，也許會遇見更多的驚喜。

二、要解決某個場景下某個問題，而非支持某個功能

這個坑，部分原因來自公司的組織架構(gòu)過于細碎，另一部分原因，可能來自于需求提出人及接收人的認知偏差。

我曾在一個產(chǎn)品群問小伙伴“你們公司有售前、需求分析師、產(chǎn)品經(jīng)理”這些崗位嗎？

有很多小伙伴所在的公司，都同時存在這三個崗位。

to B 的SaaS服務，常常會包含定制化，項目和產(chǎn)品并存。這種情況下，需要設計及處理某需求的人，接收到的需求，中間被轉(zhuǎn)了多手的情況，屢見不鮮。

需求方需要從執(zhí)行人或者子公司中將需求收集上來，這是第一波信息傳遞。這個時候，多數(shù)情況下還是在表述執(zhí)行人在做某件事的過程中遇到了什么問題，期望得到解決。

如果需求方有IT部門，業(yè)務同事會將需求轉(zhuǎn)達給IT部門，這是第二波信息傳遞。

之后，再由需求方的業(yè)務同事或IT同事將需求轉(zhuǎn)述給供應商的銷售或售前經(jīng)理，售前經(jīng)理再轉(zhuǎn)述給需求分析師或產(chǎn)品經(jīng)理，中間經(jīng)過多次的信息傳遞。

產(chǎn)品經(jīng)理聽到的需求，很多時候會被表述為“希望支持一個功能，方便客戶在做XX的時候更XX”。

中間夾雜了不知道多少人在聽到需求時，下意識給出的解決方案。

如果做信息傳遞的所有人，對要使用的系統(tǒng)都充分理解，并行業(yè)知識扎實，所提出的解決方案很有可能是可用的，但這種情況極少存在。

所以，需求保鮮，是一種能力.

對需求的準確表達，能讓SaaS路上的坑少很多。

有些需求，確實需要通過系統(tǒng)支持某個功能來實現(xiàn)，可是還有很多，需要通過服務、培訓等等其他方式實現(xiàn)。

這在信息傳遞的過程中，常常被關注于系統(tǒng)的同事們忽略。

三、某個需求不管怎么實現(xiàn)，都覺得怪怪的，那可能不該你來實現(xiàn)

這是中臺路上好大的一個坑。

不同系統(tǒng)間互相依賴，進度不同步，信息不同步，客戶需求迫切等等原因，最容易孕育畸形。

中臺是這幾年才有的一個概念，概念提的很好，對公司的統(tǒng)一性管理，確實有效。

但因為它是新事物，產(chǎn)品的融合過程中，已有的業(yè)務系統(tǒng)，往往會比中臺進度更快。

有些權限類需要用戶體系中臺實現(xiàn)的功能?？蛻赳R上就要用，中臺還在開發(fā)基礎功能，在中臺重要緊急程度不夠；在業(yè)務系統(tǒng)，重要緊急程度卻極高，業(yè)務系統(tǒng)有時候不得不單獨創(chuàng)造一個概念，先支持需求，讓客戶可用。

等后續(xù)中臺跟上來的時候，發(fā)現(xiàn)業(yè)務系統(tǒng)的好些概念，跟中臺的功能沖突；這時候再跟客戶解釋，可能已經(jīng)解釋不通。

怪胎，就這么產(chǎn)生了。

三國有言“天下大勢，合久必分，分久必合”。

在產(chǎn)品發(fā)展過程中，總會包含很多階段性產(chǎn)物。某一個階段覺得很合理的場景，后續(xù)總覺得越看越怪，還找不到原因。

這時候，不妨跳出當前這個圈圈，到更大的圈子里俯瞰全局，也許只是路在別人的腳下而已。

四、加法做多了，容易找不到路

這是欲望的坑。

市場機會和開發(fā)周期是有限的，欲望是無限的，有時候，接受不完美，也是一種能力。
每一次新做一個產(chǎn)品，總有人覺得你描繪的，不是這個產(chǎn)品全部的樣子。

期望你能描繪的更大更全更廣闊。于是，本是想做一顆玻璃球，讓娃娃在沙發(fā)上就能玩耍，公司的銷售能力也是在這個程度。

可是，因為不夠大不夠全，可能最后變成了做一個足球。產(chǎn)品是做大了，好不好的不好說。問題是：去哪里找個足球場供娃娃踢足球呢？又去哪里找一起玩耍的小伙伴呢？

欲望可以有，夢想也是個偉大的詞；一旦脫離了本心和能力范圍，有可能連本可以走出去的那條路，最后都找不到了。

中國很多的企業(yè)，活不過五年?？偨Y(jié)失敗原因的時候，得有多少是因為產(chǎn)品越滾越大，獲客越來越難造成的呢？

小而精未必不美。

精準定位、快速試錯、逐次迭代，對于團隊的資源使用情況及市場把握情況可能更合適。

作者：一米；公眾號：產(chǎn)品人兒

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

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