本文由作者?王戴明?發布于社區 對于大部分SaaS公司來說，產品標準化程度決定了企業的生死。今天，我們就站在產品經理的角度，來看看SaaS從0到1的標準化設計應該怎么做。限于篇幅，本文對如何畫流程圖、如何制作原型等基礎技能就不再敷述，側重闡述實現SaaS標準化設計的要點。 為便于大家理解，本文會以一個案例為線索，一步一步演示如何從0到1設計一款SaaS產品。01SaaS與自用系統的差異 雖然同為B端產品，SaaS與自研系統的差異卻非常明顯。從根本上來說，SaaS產品需要服務于眾多企業：少則幾十家，多則幾萬家。因此，對業務的包容性需要很強。代價則是產品迭代速度相對緩慢。 自研系統由于只服務于一家企業，強調的是貼身服務，因此對產品包容性要求較低，但是很強調迭代的速度。雖然SaaS和自研產品的邏輯是類似的，但是對產品經理能力的要求卻有一定差異。 具體可以參考下圖：內部B端產品經理更多是輔助角色。因此比較強調深入參與和支持業務，通過協調甚至推動業務部門，達成公司目標。 SaaS產品經理就不一樣了，因為負責商業化產品，是公司實現營收和盈利的核心環節，所以比較強調產品本身的架構能力和設計能力。 我個人認為，衡量SaaS產品經理的優劣，其中一個重要的標準就是：當用戶數不斷增加，產品功能會不會被推翻或大幅修改，即能不能多做加法，少做減法和改法。02標準化的意義 產品標準化對SaaS公司至關重要，曾經聽某知名SaaS公司大區總監說，某個百萬級項目談得非常好，約定4個月交付上線。 結果到了第3個月，客戶要求推倒重來，按客戶實際業務重新開發。這位銷售總監抱怨道：“前面談得好好的，就用標準化產品。但到項目后期，客戶卻說產品滿足不了業務需求，真是搞不懂。” 這就是典型的產品能力支撐不了銷售能力。如果這樣的項目很多，SaaS公司就很難盈利。具體來說，SaaS標準化有以下三個重要意義： 1. 降低邊際成本SaaS公司最大的成本投入是研發成本， 如果每一個項目都是通過配置完成交付，這意味著隨著用戶數的增加，研發成本會被逐步攤薄，最終形成規模效應，因此標準化是SaaS公司盈利的關鍵之一。 2. 沉淀最佳實踐B端客戶真正希望購買的是“行業最佳實踐”，即便SaaS公司具備豐富的行業經驗，也了解行業標桿的業務策略和執行方案，如果SaaS產品不能體現和支撐這些“最佳實踐”，那么推廣和執行的成本都會很高。 所謂標準化，其實就是把領先企業的解決方案進行提煉，再固化到系統中。這些固化的解決方案，是SaaS系統的靈魂。 3. 積累產品能力如果SaaS公司依賴運營而不是依賴產品來保障“客戶成功”，那產品和產品經理的價值都會大打折扣。標準化會不斷增強產品的配置能力，使得產品越來越厚重，價值越來越高。也只有厚重的B端產品，才能磨煉和體現產品經理的產品能力。03標準化策略 標準化策略是SaaS產品策略的重要組成部分，可以分為三個部分，分別是： 1. 產品版本標準化策略標準化最重要的策略，是確定“不滿足哪些客戶的需求”。 “一套產品吃遍天下”的傳統軟件時代，已經過去了。即便我們要占領多個細分市場，也要謹慎判斷，是否通過“一個行業版本”滿足全部客戶的需求。 比如，在快消品行業，經銷商和生產商的管理模式差異是比較大的。對于經銷商來說，組織和權限的管理是相對簡單的，也不涉及嚴格的外部賬號管理；而品牌商則有復雜的多組織管理的需求，包括外部組織和賬號的管理。 再比如，經銷商的價格體系是相對簡單的，不同等級的客戶可能會有對應的價目表，部分客戶會簽訂特定的價格協議；但是品牌商的價格體系則復雜很多，不同分公司、不同區域、不同商圈等級都會影響具體的價格。這是因為“價盤”是品牌商的生命線，所以精細的控制是有必要的。快消品經銷商和品牌商需求差異 當然，并不是說，我們一定不能在一個版本滿足多個行業的需求。過去SAP、Oracle的成功已經證明這一點是可以實現的。但是，SaaS引以為傲的正是足夠“高可用”的系統。過于臃腫的產品，會大大增加客戶的使用成本。 反過來說，“一個版本滿足所有需求”當然是不正確的。但是如果盲目的橫向擴充版本，也會給SaaS公司帶來沉重的研發負擔。 比如，當我們面對“非處方藥”行業的客戶，是否需要劃分出一個版本呢？雖然并不是快消品行業，但是“非處方藥”卻在學習快消品行業的分銷模式。在這種情況下，如果我們提供的是分銷SaaS產品，就暫時沒有必要單獨為“非處方藥”劃分一個行業版本出來。 2. 功能層標準化策略標準化第二重要的策略，是決定“哪些功能不標準化”。對于大部分SaaS，90%以上的功能是能夠在產品層面進行標準化的，但是可能有10%的功能是很難標準化的。分清楚哪些功能可以“在產品層面進行標準化”，也非常重要。 比如，中小企業對報表的需求相對簡單，因此報表功能是相對容易標準化的；但是對于百億級企業來說，報表是一個高度復雜且不能妥協的需求，因此對于還沒有BI或者PaaS產品的SaaS企業來說，暫時進行定制也是一個可行的選擇。 3. 開發層標準化策略對于無法“在功能層進行標準化”的功能，我們要想辦法在開發層進行標準化，即通常我們所說的PaaS，現在流行的叫法是“低代碼”。 低代碼是一個很“古老”的事物。我還在Oracle公司的時候，就很頻繁的使用Oracle的低代碼能力了——我們又叫personalization。通過它，我們可以改變字段的屬性，也可以嵌入SQL甚至package。 也就是說，即便是能夠靈活二次開發的傳統軟件，也非常依賴低代碼。更不用說二次開發相對困難的SaaS公司了。因此，如果一家SaaS決意要做大，PaaS能力就不是可選題，而是必選題。 但是，自研PaaS平臺確實是一個費錢的工作，并不是所有SaaS創業公司，都能夠輕易負擔得起的。好消息是，中國SaaS正在進入平臺時代，釘釘、企業微信逐步增強的低代碼能力，有望幫助SaaS公司低成本的擁有“PaaS自由”。04標準化設計難點 和自研系統相比，SaaS產品的設計更依賴長遠規劃。這是SaaS設計的核心，也是SaaS設計的難點。重視長遠規劃，主要是由于兩個原因： 1. 控制開發成本由于標準化強調配置能力，因此同樣一個功能，所需要的開發量可能是自研系統的數倍。一旦開發了拙劣的功能，就可能對開發資源造成驚人的浪費。 2. 便于持續迭代更重要的是，作為“公用產品”，SaaS必須保持簡潔性：如果系統充斥著一堆雞肋的功能，且有少數企業堅持在使用，那么會對系統迭代造成阻礙。讀者可以思考一下，當規劃的新功能與這些雞肋功能產生沖突，產品經理應該如何處理？ 因此，好的SaaS設計就是盡量做“加法”，避免做“減法”和“改法”。 當然，標準化設計對產品經理本身也是有要求的。我常常比喻，所謂的標準化設計，就像在棋盤上放棋子：棋盤就是產品經理所擁有的架構能力，棋子就是具體的需求。沒有棋盤，就不可能正確落子。05標準化設計步驟 從設計過程來說，標準化設計可以遵循以下四個步驟： 1. 策略層梳理所謂策略層梳理，是站在相對宏觀的層面梳理業務，具體又包括以下步驟： 1）明確業務范圍 企業的業務可以分為前中后臺業務，前臺業務包括商城APP等，中臺業務包括CRM、訂單管理、物流管理等，后臺業務則包括HR、財務等。 我們首先需要明確，第一版SaaS產品版本主要是滿足哪一塊業務需求。劃定好了邊界，才能匹配公司的戰略和資源。 案例： 一家知名快消品廠家找到某SaaS公司（簡稱A公司），希望開發一款管理銷售人員的移動APP。經過溝通，SaaS產品經理小李意識到，客戶的需求實際上是分銷管理，包括銷售訂單管理、銷售人員管理和門店管理等。 雖然A公司有服務于快消品‘經銷商’的分銷管理系統，但是一直苦于無法切入利潤更豐厚、收入更穩定的快消品‘品牌商’市場，這正是一個非常好的機會。2）梳理經營策略所謂經營策略，其實就是企業的打法 比如：在線下分銷業務中，用戶企業是采用深度分銷？還是兼有直銷？搞清楚客戶的經營策略，才能理清產品研發的思路。 此外，我們必須明白，SaaS是給一個行業的眾多客戶使用的。因此，我們還需要對企業所在行業的經營策略進行梳理。這樣，一方面可以將客戶的經營策略匹配到行業的經營策略，便于我們抓住本質，確保產品的通用性；另一方面，也可以通盤考慮未來的拓展方向，提前打好架構基礎。 比如，快消品線下分銷常見的策略包括大批發制、多級分銷、深度分銷、直銷、車銷等，而深度分銷又分為廠家覆蓋模式和經銷商覆蓋模式。作為產品經理，有必要全面梳理這些模式，才能在產品設計時胸有成竹。 案例： 小李和客戶溝通后，發現該快消品廠家主要采用了大批發制、直銷和深度分銷三種經營策略，屬于行業比較經典的打法，可以先開發這三種分銷模式，同時兼顧到未來向多級分銷和車銷的拓展。

• 大批發制

大批發是廠家把貨賣給批發商，由批發商再進行二次分銷。大批發模式雖然是比較粗放的分銷方式，但是當廠家管理能力不足時，采用大批發模式可以實現快速鋪貨，因此仍然是常見的一種分銷模式。

• 直銷制

快消品行業有40%左右的銷量，都是通過以大超市為代表的現代通路完成的。這些大超市往往是區域連鎖甚至全國連鎖，可以樹立品牌形象，但是進入門檻高、談判過程復雜，因此，往往是由快消品廠家直接進行合作。

• 深度分銷

深度分銷是快消品分銷的重要方向。實行深度分銷的企業，往往已經具備一定的規模和管理能力。他們將區域進行劃分，指定經銷商專營，強調終端門店的鋪貨率、陳列、新品普及率等。

對于企業來說，深度分銷可以最大化挖掘終端門店的潛力，提高新品和高毛利商品的銷售量，并有效的阻擊競爭對手。因此，這種模式一直是伊利、康師傅、可口可樂等大型快消品企業的重點分銷模式。

3）梳理業務難點相對于傳統軟件，SaaS是后來者

根據產品替換公式：新產品價值>舊產品價值+替換成本，只有SaaS提供了更大的價值，客戶才會考慮購買。退一步說，即便沒有競爭的傳統軟件，SaaS也必須解決“以前無法解決的問題”，才能在激烈的競爭中站穩腳跟。

因此，梳理清楚業務難點，明白“客戶為什么選擇我們”，是非常重要的工作，可以讓我們把資源集中在最關鍵的功能上。而不是分散資源，做那些客戶雖然愿意使用，但是不構成“差異化競爭力”的功能。

案例：

經過和客戶溝通，小李了解到，其實客戶之前已經耗費上百萬實施了某國際知名品牌的CRM系統，但是移動端的用戶體驗非常糟糕。除了使用上不夠高可用，需要反復培訓才能上手；低下的操作效率和緩慢的響應速度，更是使得系統的推廣困難重重。

客戶為什么選擇由A公司來開發分銷系統，就是在體驗了A公司的移動端產品后，認為產品的用戶體驗非常優秀，可以解決當前系統推廣的最大難題。了解到客戶的訴求后，小李意識到：這個針對快消品廠家的SaaS系統，設計的重心要放在移動端。

快消品行業普遍存在銷售人員學歷低、管理難的問題，如果通過移動端大大提高員工效率、降低員工使用難度，那么該SaaS產品將對快消品品牌商產生巨大吸引力。

2. 業務層梳理

業務層梳理，最有效的做法就是畫業務流程圖。流程圖的重點在于，產品經理要幫助客戶梳理清楚業務和需求，避免錯亂和遺漏。而做到這一點的關鍵，是產品經理要有一定的架構能力，即知道典范的流程應該如何流轉。

如果是針對大客戶的SaaS，那么建議到客戶現場呆一段時間。大客戶的要求比較細致，現場溝通可以提高溝通的效率；如果是針對小客戶的SaaS，那么建議你先找到幾個種子用戶，通過流程圖，確保1.0版本是他們能夠接受的MVP（最小可行產品）。

流程圖繪制細節是基本功，這里就不再敷述。下面放一張我曾經繪制的流程圖供大家參考：

案例：

一開始，該快消品企業認為自己的需求很簡單，主要是業務人員在手機端錄入銷售訂單，再通過接口實時傳送到已有的ERP系統即可，如下圖：

小李并沒有急于下結論，而是在黑板上畫出了典范的分銷管理流程，然后按照流程環節逐個進行梳理，如下圖：

經過梳理，小李很快發現，該廠家對于區域連鎖賣場等大客戶，采取的是廠家業務員拜訪、工廠直接發貨的直營銷售策略；對于非連鎖便利店等小客戶，采取的是廠家業務員拜訪、經銷商發貨的深度分銷策略。因此，客戶實際上有兩種不同的銷售管理流程，如下圖：

流程梳理清楚，設計思路也就清晰了。同時，小李專業的需求梳理方法也得到了客戶認可，客戶領導當場表達了合作的意向。

3. 多組織架構設計

企業業務的開展，是基于多個部門的相互協同和相互監督的。當用戶在使用SaaS系統時，流程流轉、數據安全性都必須符合企業協同與管控的要求。這就需要我們設計好組織、角色和權限功能。而這里面最有難度的，就是多組織架構設計。

比如，某飲料公司為擴大銷售規模，分別在A市和B市建立了分公司，各負責一個大區的生產和銷售。為便于管理和激勵分公司團隊，公司決定兩個分公司獨立核算利潤，并根據實現的利潤進行分紅。

為支持兩個分公司的獨立核算，并防止數據泄露，該飲料公司IT團隊決定分別給兩個分公司建立一個“利潤中心組織”。

在“利潤中心組織”下面建立了相應的“角色”，并分配了相應的“功能”比如銷售訂單、發貨功能等等。最后，將相應的“角色”分別分配給了兩個分公司的員工。

這樣，A公司員工建立的銷售訂單，所產生的收入和利潤數據，均會統計到A公司。且銷售訂單、收入和利潤等數據，只能由A公司的員工查看。B公司亦如此。

多組織架構實際上體現了企業責權利的劃分，決定了組織間協同與風險管控策略。由于企業越大，組織架構就越復雜，管控要求也越高。因此，越是針對大型企業的SaaS，越需要重視多組織架構的設計。

當然，如果是針對小企業的SaaS，多組織架構就相對簡單了，大家把角色和權限管理設計好即可。

案例：

小李梳理發現，客戶下設2個獨立核算的營業部，每個營業部下面都有若干經銷商。

對于直營的KA門店，只能由對應營業部管理數據和處理業務；對于經銷商管理的便利店，只能由對應經銷商管理數據和處理業務。同時，經銷商所屬的營業部，也具有這些便利店相關數據的管理權。

小李設計了“利潤中心”組織類型，并創建了兩個利潤中心組織：江東營業部和江南營業部。

經銷商A、經銷商B、KA門店C都屬于客戶（具有不同的客戶類型），在客戶信息上加上“所屬組織”字段，通過該字段，將這3個“客戶資料”都分配江東營業部。這樣，就只有江東營業部的人員可以看到他們的資料以及業務數據。

對于便利店a、b、c、d，則通過類似的方式，關聯到對應的經銷商，確保經銷商之間業務信息的隔離。

4. 產品功能設計

作為SaaS設計的主體，產品功能設計又可以分為應用架構設計和詳細功能設計。

1）應用架構設計

所謂應用架構設計，即各系統應用的整體結構圖。

相對于自研產品，SaaS的應用架構設計更為關鍵。合理的應用架構可以減少功能重復、避免數據混亂和降低系統拓展的難度。而一旦在不合理的應用架構上搭建起功能模塊，并且擁有一定數量的企業客戶后，修改的成本就非常高了。

相對來說，自研產品的糾錯成本就低得多。畢竟只有一家企業在用，只要和業務部門協商好，推翻重建也不是不可以。

對于產品經理來說，應用架構設計的重點要做到低耦合、高復用。所謂低耦合，是將功能按照業務相關性，分為多個系統應用。系統應用之間通過API進行交互。

這樣，單個應用的升級，對其他應用的影響就小很多，從而提高了系統的敏捷性。比如，銷售訂單管理、倉庫管理和CRM就可以獨立為多個應用，并且在必要的時候分配給不同的團隊負責。

所謂高復用，即將各個模塊所共用的功能抽離出來，單獨形成一個系統應用。

這樣，一方面確保了信息來源的一致性，另一方面簡化了系統，避免了重復開發。比如，客戶信息在銷售訂單管理、CRM、TMS（運輸管理）等系統應用中都會用到，是有必要獨立成一個應用的。

應用架構設計雖然沒有標準答案，但實際上不管是傳統的Oracle ERP系統，還是新興的各大電商、SaaS系統，都有非常成熟的應用架構設計。多研究競品，再結合實際情況進行適當的調整是應用架構設計的好方法。

案例：

考慮到A公司已經有獨立的客戶信息系統，也有成熟的商品管理系統，小李決定直接復用這些系統。為了滿足品牌商的需求，小李增加了一些新的功能，比如商圈管理、價格策略管理等。

其實，復用客戶信息管理和商品管理模塊，小李還有長期的考慮，即未來品牌商版本和經銷商版本可能會打通，形成交易型的SaaS產品。如果兩個版本共用一套基礎數據功能，會有利于將來的數據集成和流程整合。

2）詳細功能設計

SaaS詳細功能設計很考驗產品經理的系統經驗，從設計流程上來說，SaaS功能設計也遵循通用B端產品設計流程，如下圖：

但是，SaaS系統面對的是多個企業的具體需求，而這些具體需求看起來總是千差萬別的；更困難的在于，產品經理并不能確定未來會面對什么樣的企業，也就無法預知所有的需求。

在這種情況下，產品經理可能就會面臨各種尷尬局面，比如：

• 功能升級需要大幅修改原有功能，開發抱怨；

• 功能升級改變原有體驗，客戶抱怨；

• 功能上線后，沒有人使用，團隊抱怨；

• 功能上線后，客戶說需求變更了，各種人抱怨。

所以SaaS詳細功能設計很考驗產品經理的規劃和深度思考能力，具體來說，SaaS產品經理需要做好以下幾點：

• 長遠規劃，謹慎設計

從0到1的SaaS，往往是從一小群客戶的需求起步。當客戶數量較少，功能也不多的時候，產品的設計缺乏約束，很容易野蠻的生長。

比如，買贈是消費品行業常用的促銷手段。在某些情況下，贈品需要關聯到主品，比如買5瓶大可樂送1瓶小可樂。產品經理為了設計和操作方便，可能選擇直接在訂單行上新增字段，體現贈品名稱和數量。

這樣的設計在面對簡單需求的時候，可能不會出現問題。但是一旦遇到比較復雜的情況，比如：

需要管理贈品發貨；

買5增2，買5瓶大可樂送2種贈品；

需要和ERP系統集成等情況時，就會出現問題。

正確的做法是，主品和贈品都放在獨立的訂單行，擁有相同的字段，并且通過“贈品”字段來標識該訂單行是否贈品（打勾即為贈品）。因此，作為SaaS產品經理，不能夠只盯著眼前的需求，而應該放眼長遠，盡可能考慮全面。

另外，SaaS產品經理必須承認：即便通曉所有需求，我們仍無法確定全部需求的優先級。因此，一般情況下，產品經理只能挑選那些最有價值的需求優先進行滿足。而且，每一次的設計都應該是MVP，從而避免暫時不需要的功能被提前開發。

這就是SaaS謹慎設計的原則。

• 深度思考，究竟精神

SaaS設計的糾錯成本，遠高于自研產品。但是，SaaS產品經理離客戶往往比較遠，不容易深入參與客戶的日常經營。

相對而言，傳統軟件時代的項目制，需求設計師可以在一個客戶現場駐點數月進行需求調研和系統開發；而自研產品的產品經理，則幾乎天天和業務方在一起溝通。

SaaS公司的研發團隊龐大，不可能都派駐到客戶現場，因此產品經理往往需要兩頭兼顧，既要把客戶的需求搞透徹，也要做好設計，讓研發能夠順利工作。

在這種情況下，SaaS產品經理就必須具備“究竟精神”：對客戶的每一個需求刨根問底，究其本質。我一直堅守一個原則：永遠相信客戶有一個痛點，但是永遠不要相信客戶有一個正確答案，也把這個原則送給大家。

• 便覽競品，死磕細節

SaaS為什么能夠搶占傳統軟件的市場？最重要的原因并不是SaaS更便宜，而是SaaS的出生就帶有移動化、社交化的屬性。但是，移動端設計的難度是PC端設計的好幾倍。原因除了手機屏幕更小，同時也是因為移動端操作是在戶外，場景更復雜，對體驗和效率的要求也更高。

比如：快消品車銷業務員為了完成一天的拜訪任務，拜訪一個客戶的時間平均不能超過5分鐘。為了節約時間，業務員需要一邊卸貨一邊拿著手機下訂單。因此，“錄入銷售訂單”這個頁面必須足夠簡單和高效。

比如：在輸入商品數量時，就可以直接錄入多單位數量（不需要選擇單位），如“1箱/3瓶”。并且允許通過加減號來增減數量。

這樣，當業務員搬下車1箱3瓶酸奶（假設1箱酸奶有9瓶），他就不需要再計算出“1箱3瓶等于12瓶”才能錄入系統，這就可以大大提高業務員的操作效率。

要做好SaaS交互設計，除了和UE同學充分溝通和探討，更重要的是多研究和學習競品。所謂三人行必有我師焉，何況我們是從0到1的設計SaaS呢？

案例：

在進行報表設計時，客戶有幾張已經使用了5年的核心統計報表，客戶領導希望新的報表仍然沿用以前的統計邏輯。但是，小李仔細分析后，發現以前的邏輯并不是最優的。

因為客戶的部門和人員每年都會調整，而原報表是根據“訂單-人員-部門”的對應關系，來計算銷售業績。這就導致進行同期對比時，歷史年份和最新年份的業績基礎并不公平。

比如，去年的A部門，有10個人員，管轄a片區；今年的A部門，有20個人員，管轄b片區。如果簡單的把去年A部門業績和今年A部門業績做對比，實際上是有失公允的。

小李和客戶的項目負責人進行了溝通，由于這個客戶是快消品行業最頂尖的企業之一，項目負責人也屬于比較自信的領導，因此一開始小李的建議并沒有得到重視。

但是小李堅持與客戶進行溝通，指出“在分銷模式下，只有便利店和對應的區域是相對穩定的。因此應該用A部門所負責c區域的今年業績，和c區域去年業績做對比，這樣才是真正公平的”。

最終，客戶領導被小李說服了，他當著眾人的面夸獎了小李。而有了客戶領導的配合，項目的推進也非常順利，最終成功上線。小李也借助這個項目完成了SaaS的從0到1。不久，他又將這個SaaS產品銷售給了其他的大客戶，幫助公司成功完成在大客戶市場的突破。

總結

SaaS產品的設計，很強調產品經理的架構能力。如果用一句話對本文做個總結，那就是：畫好棋盤，放好棋子。

祝大家，設計出一款改變世界的SaaS產品。

↘好文推薦： 俞軍：產品經理必備的2個模型 用戶細分指南：6種模型與5類維度 產品方案：我的PRD撰寫規范點個“在看”吧

總結

以上是生活随笔為你收集整理的SaaS产品设计，从0到1案例实操的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。