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

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

這是書籍和經驗造就的坑坑。

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

開始的時候我信了，數十次碰壁之后我發現，這可能也是中國沒有一個可以走向世界的SaaS產品的原因原因之一。

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

那時候使用系統的基本都是餐飲類企業，調研了多家企業又分析了競品，發現這是個標準需求呀，我們挺高興，在系統里增加了一個“門店”的標簽。

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

隨著業務發展，慢慢接入了好多房地產行業的用戶，客戶說，我得按小區統計數據，你們支持嗎？

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

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

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

然后，業務又發展了，有了更多的合作伙伴，更多的行業使用這個產品。

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

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

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

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

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

如果同一個概念，門店就叫門店，小區就叫小區。

在客戶使用系統前，選擇下行業，系統根據行業區分后顯示對應名詞，是不是這個溝通和學習成本就沒這么高了？

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

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

我傾向于后者。

這篇文章從寫完到發布，經歷了大約一個月左右的時間。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

之后，再由需求方的業務同事或IT同事將需求轉述給供應商的銷售或售前經理，售前經理再轉述給需求分析師或產品經理，中間經過多次的信息傳遞。

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

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

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

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

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

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

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

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

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

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

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

但因為它是新事物，產品的融合過程中，已有的業務系統，往往會比中臺進度更快。

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

等后續中臺跟上來的時候，發現業務系統的好些概念，跟中臺的功能沖突；這時候再跟客戶解釋，可能已經解釋不通。

怪胎，就這么產生了。

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

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

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

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

這是欲望的坑。

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

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

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

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

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

小而精未必不美。

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

作者：一米；公眾號：產品人兒

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

題圖來自Unsplash，基于CC0協議