起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識我在B端SaaS化路上，挖了多少坑
本文作者以親身經歷為例，回顧了自己在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協議
感覺很多東西都要做成模塊化，針對性的調整，但是做成模塊化也會做的很龐大
我們面對企業客戶不光是因為需求價值傳遞鏈路失真，在很多tob的場景內我們忽略了我們的產品在企業整體IT架構中的姿勢，缺乏全局性思考。
感覺業務還是需要抽象化，具體問題過于細碎和龐雜，需要抽樣一個類似模型的東西，來找通解。在有了通解之后在去場景里面適配
如果一直個性化，其實問題解決成本會比較高
其實我更期待的是，能找到一種共性的方式，去把一些個性化需求實現。
您提到的業務抽象化是第一步，確實是需要的；
模型搭建好后，如果能夠通過人機交互或者系統處理，又滿足了每個行業的個性化認知，這是最好的。
我有了基礎的思路，但如何執行，還在思考。
個人感覺抽象化和個性化并不沖突，因為抽象化之后，要校驗在各個場景下是否合理，如果不合適就像文中所說，做個性化處理。