本文作者以親身經歷為例，回顧了自己在B端SaaS化過程中遇到的問題以及經驗，與大家分享。
這是書籍和經驗造就的坑坑。
在很多的書籍或者方法論中，認為SaaS產品應該實現標準的需求，當遇到個性化需求的時候，要把它抽象化，抽象成很多企業可以共用的樣子。
開始的時候我信了，數十次碰壁之後我發現，這可能也是中國沒有一個可以走向世界的SaaS產品的原因原因之一。
聊聊第一個坑：我們做To B的SaaS服務，有一天，一個客户跟我説，我要看我們公司不同門店的數據，你幫我處理下吧。
那時候使用系統的基本都是餐飲類企業，調研了多家企業又分析了競品，發現這是個標準需求呀，我們挺高興，在系統裏增加了一個“門店”的標籤。
好多用户反饋，你們這個功能好呀，我都能按門店查詢啦，再也不用導出來一點點對賬啦……
隨着業務發展，慢慢接入了好多房地產行業的用户，客户説，我得按小區統計數據，你們支持嗎？
我們一看，這跟門店不是一個意思嘛，問人家門店行不行，客户説：我是小區，不是門店。
我們想，書上説了，要抽象，專門開了10次會議討論，終於確定了一個詞“業務類型”。
那時候覺得自己特牛，終於可以支持多個行業場景啦。什麼餐飲門店、物業小區、建築項目、不同業務線，都往上靠吧！
然後，業務又發展了，有了更多的合作伙伴，更多的行業使用這個產品。
於是，每天每天，電話、微信羣、面對面會議，總有人問“業務類型”是什麼呀？怎麼用呀？
在同一個人第80次問我的時候，我哭了。邊撓桌子邊問：“姐，我如果讓它叫門店你能理解嗎？”
東北小姐姐扯着嗓門説：“那有啥不理解的呀，你早這麼叫我都不問你。”
除了跪下，我還能怎麼辦……
這時候我不得不想，抽象，是不是錯了。
如果同一個概念，門店就叫門店，小區就叫小區。
在客户使用系統前，選擇下行業，系統根據行業區分後顯示對應名詞，是不是這個溝通和學習成本就沒這麼高了？
或者，還有哪些更好的方式，能即使用客户常用的名詞，系統又能兼顧不同情況呢？
SaaS化，到底是把客户的需求抽象後實現，還是直接實現客户的需求，系統通過靈活的配置兼容多場景，低學習成本推廣呢？
我傾向於後者。
這篇文章從寫完到發佈，經歷了大約一個月左右的時間。
我在網絡言論方面，是個膽子有點小的人，對於這種理論與實踐衝突比較大的情況，總想多方位的求證，在不同的場景和行業裏得到證實之後，才敢胡説八道。
在求證過程中，我發現有太多太多名詞無法理解，因為用詞不一致導致大量無效溝通甚至產品推進難度大的情況。
究其原因，是大家在常識方面不一致。
常識，讓有些人心有靈犀，默契自成；常識，也讓一些人，説着同一種語言卻無法溝通。
不同地區、行業、職業、教育背景、原生家庭甚至不同性別的人，都各自有自己的常識。這些在C端產品中備受重視的客户細分，到了B端，因為業務的複雜性，有時候會被無意識的忽略。
尊重對方的習慣的時候，同樣獲得尊重。不論是人還是產品。
而抽象，屬於一種融合，是進行了深入理解甚至邏輯處理後的結果。首先挑戰人的習慣，其次挑戰人的惰性，再次考驗人的記憶力和理解力。
遇到類似問題時，多想幾套方案，不侷限於抽象，不拘泥於常識，也許會遇見更多的驚喜。
這個坑，部分原因來自公司的組織架構過於細碎，另一部分原因，可能來自於需求提出人及接收人的認知偏差。
我曾在一個產品羣問小夥伴“你們公司有售前、需求分析師、產品經理”這些崗位嗎？
有很多小夥伴所在的公司，都同時存在這三個崗位。
to B 的SaaS服務，常常會包含定製化，項目和產品並存。這種情況下，需要設計及處理某需求的人，接收到的需求，中間被轉了多手的情況，屢見不鮮。
需求方需要從執行人或者子公司中將需求收集上來，這是第一波信息傳遞。這個時候，多數情況下還是在表述執行人在做某件事的過程中遇到了什麼問題，期望得到解決。
如果需求方有IT部門，業務同事會將需求轉達給IT部門，這是第二波信息傳遞。
之後，再由需求方的業務同事或IT同事將需求轉述給供應商的銷售或售前經理，售前經理再轉述給需求分析師或產品經理，中間經過多次的信息傳遞。
產品經理聽到的需求，很多時候會被表述為“希望支持一個功能，方便客户在做XX的時候更XX”。
中間夾雜了不知道多少人在聽到需求時，下意識給出的解決方案。
如果做信息傳遞的所有人，對要使用的系統都充分理解，並行業知識紮實，所提出的解決方案很有可能是可用的，但這種情況極少存在。
所以，需求保鮮，是一種能力.
對需求的準確表達，能讓SaaS路上的坑少很多。
有些需求，確實需要通過系統支持某個功能來實現，可是還有很多，需要通過服務、培訓等等其他方式實現。
這在信息傳遞的過程中，常常被關注於系統的同事們忽略。
這是中台路上好大的一個坑。
不同系統間互相依賴，進度不同步，信息不同步，客户需求迫切等等原因，最容易孕育畸形。
中台是這幾年才有的一個概念，概念提的很好，對公司的統一性管理，確實有效。
但因為它是新事物，產品的融合過程中，已有的業務系統，往往會比中台進度更快。
有些權限類需要用户體系中台實現的功能。客户馬上就要用，中台還在開發基礎功能，在中台重要緊急程度不夠；在業務系統，重要緊急程度卻極高，業務系統有時候不得不單獨創造一個概念，先支持需求，讓客户可用。
等後續中台跟上來的時候，發現業務系統的好些概念，跟中台的功能衝突；這時候再跟客户解釋，可能已經解釋不通。
怪胎，就這麼產生了。
三國有言“天下大勢，合久必分，分久必合”。
在產品發展過程中，總會包含很多階段性產物。某一個階段覺得很合理的場景，後續總覺得越看越怪，還找不到原因。
這時候，不妨跳出當前這個圈圈，到更大的圈子裏俯瞰全局，也許只是路在別人的腳下而已。
這是慾望的坑。
市場機會和開發週期是有限的，慾望是無限的，有時候，接受不完美，也是一種能力。 每一次新做一個產品，總有人覺得你描繪的，不是這個產品全部的樣子。
期望你能描繪的更大更全更廣闊。於是，本是想做一顆玻璃球，讓娃娃在沙發上就能玩耍，公司的銷售能力也是在這個程度。
可是，因為不夠大不夠全，可能最後變成了做一個足球。產品是做大了，好不好的不好説。問題是：去哪裏找個足球場供娃娃踢足球呢？又去哪裏找一起玩耍的小夥伴呢？
慾望可以有，夢想也是個偉大的詞；一旦脱離了本心和能力範圍，有可能連本可以走出去的那條路，最後都找不到了。
中國很多的企業，活不過五年。總結失敗原因的時候，得有多少是因為產品越滾越大，獲客越來越難造成的呢？
小而精未必不美。
精準定位、快速試錯、逐次迭代，對於團隊的資源使用情況及市場把握情況可能更合適。
作者：一米；公眾號：產品人兒
本文由 @一米 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議