編輯導語：本文作者圍繞剛剛完成的一款營銷業務中台産品，從平台化産品的設計要點，以及To B産品中小微企業與大型企業的區别這兩個方面，對平台化産品進行了分析，一起來看一下吧。

在過去的2個月裡，筆者和團隊小夥伴們一起完成了2件事：從0-1搭建了一款營銷業務中台産品，同時也完成了該中台産品的一次升級。

這個從0-1的過程讓我很興奮，也讓我積累了非常多的寫作素材，甚至在第一次寫這篇文章的初稿時，寫了4000多字都感覺還有一堆想說的沒有寫進去。

所以，今天核心圍繞這款營銷業務中台産品，想來和大家先分享其中一個感觸最深的主題：平台化産品。

為什麼會突然把話題引入到平台化産品呢？

這是因為自己所面對的客戶規模發生了巨大的變化。

以前筆者所負責的産品核心面向小微企業，而現在卻以大型企業為主，二者在組織人事、業務流程、付費能力&意願上等有着巨大的區别。

而這些區别逐漸倒逼産品由單一縱深的業務場景逐漸轉向注重平台化、高度複用化的方向，倒逼自己也需要盡快開始調整以往的産品設計理念和思路。

因此，本文想站在一個剛剛入行平台化産品2個月、曾經從事小微SaaS産品2年半的産品視角，和大家分享自己對平台化産品的一些體會，因入門時間有限，故以分享為主，如有不對，歡迎大家指正與探讨。

本文将分為以下2個部分：

1. To B産品中，小微與大型企業的3大區别
2. 平台化産品的3個設計要點

enjoy～

01 To B産品中，小微與大型企業的3大區别

雖然早在進入To B行業之前就了解過大型企業在組織人事、業務流程等各方面與小微企業的差異，但隻有親身經曆之後，才能真正感受到其巨大的區别。

區别一：組織/流程/角色差異巨大

以前做教培SaaS，一個培訓機構最多就十幾或者幾十個員工，部門也很簡單，除了老師比較多之外，其他人員如前台、财務、教務基本屬于一個部門一個人，甚至大部分情況下，這些角色多是身兼數職，一個人幹着2、3個人的活。

在這種組織架構之下，基本不需要什麼複雜的流程，甚至像報名訂單的提交、審核、收款一個人就操作完了。

總而言之，小微企業在組織/流程/角色上的特點是：組織架構簡單、員工身兼數職、流程簡單但也有比較混亂。

而大型企業則截然不同。

大公司大多是專人專職、分工明确，這就保證了整個工作流程相對明确，但角色多、鍊路長，跨部門配合極多。

例如，大公司的運營人員要創建一個營銷活動，他會經曆以下5個步驟：

1. 在線下做好完整的活動方案規劃
2. 交予領導彙報溝通
3. 溝通通過後，在線上營銷系統進行對應的活動創建
4. 創建成功後，需要交由領導和财務等進行層層審批
5. 審批通過後，再考慮推至C端使用

如果是小微企業，可能一個運營人員和老闆面對面溝通好了之後，就直接在後台操作并進行活動上架了，幾個小時就能搞定；但大公司裡，這個流程一走可能就是幾天甚至幾周，沒錯，流程複雜且冗長，但也有效降低了出錯的風險，保證營銷活動不會出現大面積的災難。

因此，從上述的例子可以看出，小公司在做事上更「快」，而大公司則相對更側重于「準」；再投射到我們所提供的To B産品上來看，就會在訴求上有非常大的區别。

區别2：小公司需要契合度80分的産品，大公司卻需要99分

在兩段工作經曆中所面向的客戶對比之下，小公司往往在契合度達到80%左右就會産生一定的付費意願，采購者核心看重整個産品中自己最需要的那部分能力（而不是全部）。

因為對于小公司而言，生存下來才是王道。通過軟件或者系統來改善和提升自身盈利是一件錦上添花的事情，那在這樣的訴求之下，性價比就變得很重要。畢竟如果真的要花幾十幾百萬去買一款完全符合自身訴求的産品，首先，産品也很難帶來量變的價值，其次，公司的盈利都不一定能夠這筆開銷，甚至沒準産品還沒摸透，公司都垮了。

而大公司則可以用财大氣粗來形容了。隻要開了标就意味着已經劃好了一定的預算區間，那麼他們在采購To B産品時，則會以一個甲方的角度來看待産品，更多關注在明确的預算之下，哪一家公司能夠更高的契合自身業務。

除此之外，小公司就像一條小船，可以輕松地調整方向，即通過靈活的業務調整去适應系統；而大公司因為角色衆多、利益鍊複雜，就像一艘難以輕松掉頭的巨艇，很難做到為了一款外部的産品而去改變自身的流程。

這也就造成了兩者對于To B産品訴求的巨大差異。

區别3：小公司付費能力弱、替換成本低，而大公司截然相反

前面是從企業、産品的角度來進行對比，現在我們從商業的角度來看待不同規模的公司。

小公司生存至上，因此在付費能力和意願上較弱，但也因為數據量小、組織輕量化等原因，産品替換成本也相對較低，容易接受新産品；而大公司雖然付費能力強，但替換成本極高，因此對于采購更為謹慎，但好處是一旦采購，至少幾年内都是較為穩定的合作關系。

從上面的對比我們可以看出，2者在付費能力、替換成本等方面都有很大的區别。在這種情況下，同一行業内的To B産品對待不同規模的公司市場在打法上、産品定位上也會産生很大的不同。

小公司往往是一種長尾流量式的打法，付費能力雖弱但數量多、更新換代的頻率高，因此走的是量，更看重市場占有率；而大公司則是一種抓重點抓關鍵的打法，大客戶客單價高、替換成本高，一旦搭上線，那就是穩定且大額的長期收入，走的是質。

（馬太效應下，大企業和小微企業占據大頭）

通過上述的3處對比，大家是否能夠清晰的感覺出2類客戶之間巨大的差異呢？當然，這巨大的差異也在倒逼筆者盡快調整自己的産品設計思路，從單一的業務縱深方向逐漸跳出來，從更為平台化和高度複用化的角度去打磨自己當前所負責的産品。

那麼，第二部分就來和大家分享下在這短暫的2個月中，自己體會到的3個平台化産品設計要點。

02 平台化産品的3個設計要點

前面主要在進行2大客戶類型的對比，現在我們把其中對于大客戶的特點抽離出來單獨看看：組織上——流程複雜、專人專職、角色衆多；産品上——需要99分業務契合度的産品；商業上——付費能力強、替換成本高。

從組織和産品上來看，面向大客戶的To B産品勢必難逃「複雜」和「定制」二字。面對每家大型客戶都需要99分業務契合度的訴求，難道産品都要挨個定制嗎？這當然是不現實的。

因此，産品除了要提煉出核心标品之外，還要逐漸打造出平台化的能力。那麼，将産品逐漸平台化需要考慮哪些要點呢？鑒于筆者目前有限的經驗，可能很難整理地非常全面，但希望以下列出的思路能夠給予你一些幫助和啟發。

思路一：高内聚低耦合

高内聚低耦合是一個剛入行時就耳朵聽到起繭的口号，但真正能否做到、做到什麼程度卻是需要持續去思考和精進的。

用一個具體的例子來一起感受下：當我們在管理優惠券的時候，為了保證優惠券使用時對于成本的把控，需要将一部分庫存專門拿給A活動進行使用。那麼問題來了，如何保證這批庫存和A活動的關系呢？

這裡給出3種方式，你會pick哪一種？

1）運營人員創建時，手動保證一個活動對應一批券

• 當運營人員創建優惠券時，手動為一個活動創建一批庫存，在對内的命名上做一個标記，例如618老用戶專用7折優惠券
• 選擇活動時，直接選擇對應這個名字的優惠券即可，系統不做任何綁定關系的幹涉

2）在活動使用100張券時，通過凍結邏輯，為該活動鎖定這100張券

• 運營人員創建好200張優惠券
• 在A活動需要使用這批優惠券時，選擇其中100張
• 活動創建好後，需要調取優惠券系統的凍結接口，調取成功後，系統自動凍結這100張庫存「凍結意味着這100張券隻能給A活動使用」
• 當活動結束後，需要調取優惠券系統的解凍接口，将未發完的優惠券釋放回庫存池裡

3）優惠券以模闆 批次為模型進行創建，活動選擇的是券的批次

• 管理員創建好優惠券模闆
• 運營人員申請并創建好為A活動使用的券批次，并将其命名為618老用戶專用7折優惠券
• 選擇活動時，直接選擇對應名字的批次即可，系統不做任何綁定關系的幹涉

以上3種，都是目前市面上比較常見的優惠券管理方案，沒有絕對的對錯。如果現在讓你做一款面向不同活動系統、不同發放渠道的平台型優惠券系統，你認為其中哪個是更符合高内聚低耦合設計思路的呢？

個人心中的答案是第3種。

方案1中，券的模闆和制作被融合為了一個動作，兩個業務高度耦合，未來很難符合大公司對于兩個動作分别賦予權限進行管理的訴求。

方案2中，将庫存凍結/解凍的邏輯也與外部活動系統進行了高度耦合，這意味着任何一個需要拿優惠券的活動系統，都需要在适當的節點再額外調取凍結和解凍的接口，提升了系統間的業務耦合度。

而方案3将券的模闆管理和制作抽象為了兩個動作，未來能夠滿足更具個性化的管理訴求；同時，引入了批次的概念，無論是什麼外部系統，都可以通過批次這一個概念與優惠券系統進行交互，無需适應凍結/解凍這樣耦合的業務邏輯。

如下圖所示，微信支付營銷工具裡的代金券就是通過标準的批次API進行交互的：

那方案3如此高度抽象和解耦，為什麼市面上的系統都沒有用這樣的方案呢？

這是因為方案1和方案2本身雖然看起來不夠解耦，但如果你的優惠券系統隻需要和内部的活動管理系統進行對接，方案1和方案2其實對接起來足夠簡單，即使有業務耦合度也沒關系；同時，用戶在使用優惠券系統時，路徑也會簡單很多、學習成本很低。

所以，解耦和體驗有時候真的是天平的兩端，解耦度高雖然對于系統而言是好事，但也意味着兩個模塊的業務會存在一定的割離，用戶體驗上會有一些不流暢。這也就需要你在兩者之間努力嘗試尋求一個最佳的平衡點了。

思路二：多層抽象，靈活配置

在思路一中我們講到了券模闆和批次的這個模型，順着這個案例，我們來引入平台化設計的第二個思路——多層抽象、靈活配置。

如果你在創建優惠券的時候，按照A客戶對優惠券的訴求，把對應券的規則字段寫死，沒錯，A客戶在創建時直接創建了所需要的實例，确實省了很多事。

但你有沒有想過3個問題：

1. A客戶未來會不會有新的優惠券類型和規則需要創建？
2. 其他客戶對于優惠券的字段如果和A不一樣該怎麼辦？
3. 未來有新的大客戶希望券本身的規則管理和制券是2個權限該怎麼辦？

從這個例子我們可以看出，大公司本身個性化訴求會比較多且強烈、對功能點的管理粒度要求會非常細緻，同時，客戶的需求也可能會随着市場的變化而不斷調整。

那在這種情況下，我們就需要将一些功能抽象為多層，隻有多層才能保證更為靈活的配置。例如，這裡就可以将券模闆和實例進行分開管理，同時，券模闆層支持用戶自定義字段進行配置等。

當然，這個案例不一定非常貼合你自身的業務，但是整體的思路是我們要通過更具杠杆率的産品來獲得營收，那就勢必倒推我們的産品也需要通過多層抽象和靈活的配置做成高杠杆的功能，千萬不能來一個客戶改一次。

思路三：強大的對接能力

筆者之前在做小微SaaS時發現，大部分小微企業基本核心就用1-2款管理系統，你的管理系統基本會是一個小微商戶所用系統中的主角。但在大型企業中，你的産品很難成為客戶整家公司中的主角，大部分情況下隻是衆多流程中的一環。

這就意味着我們需要對接各種各樣的客戶自有系統和客戶采購的三方系統。

當然，對接這裡具體的技術細節我不太擅長，但這裡想提醒大家的是：

• 務必要從長遠的角度考慮如何與更多客戶對接
• 盡可能多調研大部分客戶的現有能力是什麼樣
• 關注客戶在對接上的實際訴求到什麼程度

通過綜合以上3種信息，再去考慮如何給出一個解耦度高、标準能力更強的接口規範。

這裡分享了一些在特定場景下收獲到的小經驗，還有待未來持續完善，但個人覺得好的平台化産品也應該像一款插座一樣，外部系統無需過度耦合、隻用接入插口，即可快速連接并使用産品。

以上，就是筆者這2個月來對于平台化産品的一些淺見。雖然還不夠深入，但對于此前更多關注縱深業務的我來說，自己的視野和思考的廣度都有了一定的提升（格局打開）。

打一個可能不太恰當的比喻：重業務型的産品就像迪士尼樂園一樣，給你在特定場景下沉浸式的體驗，但很難複刻、也很難響應更多遊玩的需求；而重平台化的産品就像一盒樂高，無法給你過于場景化的體驗，但卻賦予你無限可能。

作者：冰冰醬；公衆号：産品冰冰醬

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

題圖來自 Unsplash，基于CC0協議。

,