編輯導語：對于產品經理而言，產品在快速落地前，需要切實了解執行產品背后的動機及目的，這樣可以避免用戶體驗感不佳。本文將分為以下六方面對SaaS產品設計進行探討交流，值得閱讀學習。

有這樣一個場景：

老板/用戶：我有?個特別棒的想法，優先級很高，你趕緊把方案產做出來。

產品經理：保證效率！我馬上就開始畫原型，然后內部評審，接著推進開發。

這時候部分產品經理急于表現，需要將需求快速落地，第?反應就是開始執行，所以經常會發生?種情況，產品經理很努力的去做，把需求或想法百分百的去還原，但結果老板或用戶體驗完之后發現，這并不是我想要的功能。

出現這種情況的原因是產品經理沒有了解到這個需求背后的動機和目的，這是很多小伙伴容易出現的問題。而SaaS產品設計，不僅僅只關注設計，在此之前我們更要關注產品的定義。需要我們想清楚這個需求對應的場景是什么，場景中的需求價值是什么。之后才是結構化的框架把功能設計出來。

文章整體分為以下幾個部分：

1. SaaS產品設計痛點場景拆分
2. SaaS產品不同維度的認知
3. 我們通過什么方式去理解業務
4. 我們如何梳理業務判斷需求價值
5. 我們如何設計產品架構與功能
6. SaaS產品生命周期中的設計原則

以下，咱們一起進入正文~

一、SaaS產品設計痛點場景拆分

1. SaaS產品經理的工作方式

SaaS產品經理?作本質是從發散到收斂的?個過程。發散是指產品的定義，收斂是指產品的設計。但往往很多產品經理?上來就開始收斂了，開始畫原型，好?點的產品經理可能先去思考這個功能影響的范圍，影響的面。最后梳理出?個腦圖，用這個腦圖去跟開發去碰，但是?個優秀的產品經理除了?上來就收斂之外，其次需要我們思維先發散，最終產品定義這個場景對應的價值是什么。

2. SaaS產品理解業務是進?需求梳理與功能設計的前提

在這里在跟大家分享三個場景：

場景一：很多同學都是半路轉行過來做SaaS產品經理，往往會遇到不知道如何去跟進行業的趨勢，同時也不知道如何去做業務調研。而對于業務理解的欠缺也直接影響到對應的產出，這時候根據對業務理解而設計的產品方案也會被吐槽，不懂業務。這種場景我相信很多SaaS產品經理都會有許多感觸?！纠斫鈽I務難】

場景二：很多產品經理由于之前經驗習慣，專注思考單個場景下的用戶價值，在這時候會導致在思考業務場景時經常出現遺漏，從而導致業務無法閉環，終端用戶對產品感到滿意，卻沒有直接轉換成付費?！拘枨笫崂聿磺逦?/p>

場景三：產品經理進行了全盤梳理，理清價值之后，全身心投入產品設計中去，然而業務出現了?堆個性化需求，產品經理硬著頭皮單點設計，最后演變成定制化設計，導致產品邏輯異常復雜，研發成本也不斷升高，終端用戶在前端界面也會吐槽越來越復雜，不知道怎么入手了?！竟δ茉O計復雜】

出現上面三種場景情況的原因是SaaS產品有非常強的業務壁壘，所以不同行業產品經理會出現隔行如隔山的情況，產品設計不清楚具體場景的痛點和難點。其次是SaaS產品業務流程是比較復雜的，看似簡單的功能也會涉及多個角色，所以需要通盤考慮。最后SaaS產品個性化需求非常多，需要滿足不同個性化需求，所以導致設計方案復雜。

所以接下來的文章也會圍繞這三個場景去跟大家分享對應的產品方法論。

二、SaaS產品不同維度的認知

1. SaaS產品認知的歧義

很多人認為SaaS產品是toB產品，但從本身定義軟件即服務來看，即沒有說是toB也沒有說是toC。而廣義的SaaS定義是既有toB也有toC（比如印象筆記/石墨?檔）。從軟件交付方式來講，SaaS本身作為一種交付模式，本身不存在toB或toC之分。從商業模式來講，如果我們把toB產品定義為基于互聯網提供服務，?以提升企業效率，增加企業收?的產品，那么SaaS產品可以算是B端產品的?個分支。

2. SaaS產品不同維度的認知

SaaS模式的出現很大程度上是順應用戶對數據安全和低維護成本的需求而衍生的。

SaaS產品劃分：業務垂直型（提供面向特定業務的SaaS解決方案比如：crm erp等）、行業垂直型（提供面向特定行業的SaaS解決方案比如零售電商、餐飲、醫療、制造業）行業和業務之間肯定有交叉的，?個SaaS產品既會有特定的業務，也會面向特定的行業。

SaaS產品特點：

• 云端架構：SaaS公司提供服務器、數據庫等硬件，無需本地部署；
• 成本下降：無需客戶承擔基礎設施成本、日常運維成本，付費靈活；
• 用戶按月/年支付費用，而非?次性購買，體驗提升；
• 后續升級維護由SaaS公司負責，通過數據驅動迭代。

SaaS產品業務階段：整體劃分為四個階段，基礎產品完善期、行業產品深入期、生態建設期、再創新。

三、我們通過什么方式去理解業務

1. 業務理解=行業模式（宏觀）+企業運作流程（微觀）

對業務的理解我們可以由抽象化轉換為具象化，本質需要從行業模式和運作流程去了解。懂行業模式是要能夠理解約定俗成的玩法和規則是什么。懂運作流程是行業中某個企業不同崗位/角色如何各司其職的。運作流程是行業模式的直觀體現，行業模式?為理解運作流程提供指南針。

理解行業的限制，了解他的客觀規律從而避免走彎路，理解運作流程從而能夠還原場景，并設計功能滿足需求。所以我們需要通過行業分析了解行業模式，通過業務調研了解某個企業的運作流程。

?業模式：從宏觀角度，我們了解行業內企業相應業務的玩法，從而抽象出通用的玩法和規則，這樣我們才可以了解企業的核心痛點，其次也為SaaS產品及服務提供方向指南。

運作流程：從微觀角度，對于每個企業我們需要了解企業內部不同員工是如何操作的，最終實現公司業務運轉，了解這些才能使我們產品設計更加落地。

2. 行業模式（宏觀）：如何快速了解一個行業

SaaS產品經理算半個行業專家。

網上做行業分析的方法有很多，重要的是需要找對維度，不能只停留在大范圍層面，而是需要聚焦于我們自身業務的邊界。關于維度層面這邊跟大家分享五個分析行業的維度，分別是：行業基礎信息、外部經營環境、內部市場環境、標桿企業分析、SaaS競品分析；

通過上訴幾個維度我們可以快速了解?個行業，但是往往實際工作場景是我們做出了?份分析報告，但不知道真正作用在哪?。這種情況下需要回歸到本質，我們是為了了解行業通用規則和玩法，最終服務于自身SaaS業務。

3. 企業運作流程（微觀）：如何進行業務調研

先跟大家講講C端產品的用戶調研與SaaS產品業務調研的區別，C端用戶調研只需要關注單點用戶，SaaS業務調研需要全盤考慮整個業務流程，這也是很多轉行做SaaS產品經理會按照以前的調研方式，去做業務調研，容易導致產品流程上沒有閉環。其次C端?戶調研需要以用戶體驗為中心，相對于來說SaaS產品更關注需求，解決了什么業務問題。最后C端產品用戶需求層面相對于容易抽離共性，SaaS天然存在大量個性化需求且極度分散。而且C端產品?般都是用戶可以通過共情來挖掘潛在需求，SaaS產品經理通常不是用戶，需要通過理解業務來挖掘需求。

4. 運作流程要素與調研步驟

業務調研最終是為了理解業務的運作流程，運作流程包括的元素有什么：企業（通過定義標桿企業描繪客戶畫像）、角色（通過查看組織架構和參考同類型企業來梳理角色特征）、流程（通過觀察與調研了解核心業務的工作流）。

業務調研整體分三步：

第?：定義并選擇標桿企業。在這里需要定義標桿企業的客戶畫像，以標桿企業的需求為核心?？蛻舢嬒癜蛻?企業規模、從屬細分類目、業務范圍），在這里面為什么我們需要選擇標桿企業的原因是在于標桿企業需求具有代表性，相對容易抽離。其次也是因為標桿企業的聲音有影響力，后期能夠引領其他客戶。

第?：梳理業務鏈條的??。在這?步梳理好業務流程中的關鍵角色之后，我們需要定義角色的特征（主要負責什么、業務目標標/KPI是什么、職業特點是什么），怎么找到這些業務流程中的關鍵角色，第?可以從企業的組織架構中尋找，這是最便捷也是最直接快速的方法。在得不到組織架構的情況下，可以參考同類型企業的流程及角色（當然這里的企業也是屬于標桿企業），在做整體角色梳理的時候我們必須要注意業務的閉環，如果忽略了業務鏈條不重要的角色，可能會導致業務無法閉環。

第三：觀察與調研并行。在梳理完業務流程之后我們需要通過觀察與調研，理清角色的工作流（核心流程）。對于SaaS產品來說，觀察比直接開放式調研更有效，這么說的原因是在于產品很難從根上去撼動絕大部分公司的業務模式，所以我們側重在還原業務，而非創造業務，還有?個原因是調研過程中多少都會有主觀成分在，所以需要通過觀察還原業務。

觀察的方式我們可以通過駐場，深?業務需求方的工作場景，觀察他們平時的工作方式。在觀察的同時我們也需要得到這個角色的工作流是什么樣子的？有沒有標準化流程？在什么情況下，執行了那系列任務，完成了什么業務上的目標？還有?種方式輪崗機制，有機會的話能夠直接上手體驗業務方的工作是最好的。用戶調研主要從流程維度和具體場景維度去設計調研問題。

在理解業務這個層面上我們需要循序漸進的，理解業務沒有太多的技巧，通過觀察和調研交叉，了解用戶/用戶需求，并通過產品設計滿足需求，了解反饋，進而根據反饋持續滿足需求—-通過不斷地這樣循環深耕業務，才能不斷深化對業務的理解。

四、SaaS產品如何梳理業務判斷需求價值

很多產品經理在做了?波業務調研之后，也對業務有了?定程度的理解，認為接下來就該到需求分析了。其實不是這樣，除了對業務要有?個深度了解之外，還需要還原業務中遇到的場景是什么，用戶需求價值是什么。如何去判斷需求的價值，其實本質是我們需要在產品定義這個環節去梳理清晰。

產品定義分兩個部分：第?回歸場景（梳理并描述業務場景），第?理清價值（判斷場景中需求的價值）。

1. 為什么要回歸場景？

在這個跟?家描述兩個我們常見的工作場景，很多時候產品經理在提出產品方案時，大家圍繞實現細節開始討論的時候容易出現，‘我覺得’的?式來表達自己的觀點，每個人都有自己的想法，無法達成統?的意見。還有?種情況是在沒有理解場景的情況下直接開始畫原型，這時候會出現我們產品上線之后總是不符合實際線下流程，還得推倒從來。

現在我們回想上?兩個場景中為什么出現這種情況，本質是因為產品經理對外（項目組其他人），完成?項任務肯定是需要多個部門多個角色頻繁的傳遞用戶需求，因此使用一套易理解，貼近實際的溝通的?式就很重要，而場景就是通行于不同角色之間解決產品問題的語言。

對內（自身思考）產品設計我們需要先發散后收斂，因此動?畫原型，寫文檔之前我們需要做?量的思考，調研。邏輯基點是用戶?臨的實際情況到底是什么樣的，即回歸場景。

2. 單個場景與多個場景

在單個場景上，SaaS產品不能創造，只能還原。這也是和C端的區別點，C端因為自己就是用戶，可以以發散的?式創造場景，從而引領用戶需求。SaaS業務天然存在壁壘，無法發散獲取，只能還原場景，且顆粒度需要更細。在多個場景上，SaaS產品需要考慮業務的閉環。同樣以C端舉例，c端產品相對簡單，重點在于單點突破核心場景。SaaS產品業務鏈長，缺少任何?個必備場景都可能?法閉環。所以回歸場景我們需要先將單個場景描述清晰，進而梳理鏈條中的全場景。

3. 場景我們該如何去描述

回歸場景我們需要通過?種通?的場景描述方式，對內形成自己的思考基點，對外讓大家形成共識。在這里跟大家分享?種場景描述方法，場景描述的7要素（用戶、環境、時機、目標、動作、截止、任務）SaaS產品的場景是真實存在的，不是憑空捏造的。需要在真實業務中得到驗證。場景描述方式本身不重要。重要的是對外能夠形成統?的認知，對內思考能夠還原用戶實際情況才是關鍵。

針對單?的場景我們可以通過單?場景描述方式去還原，針對多個場景時我們可以借助場景需求清單，場景需求清單是多個場景串聯形成的結構化信息，他是?個業務鏈條下的場景拆分后的需求集合，場景需求清單可以幫助我們梳理業務鏈條下的場景關系，避免遺漏影響業務閉環的場景?；谥暗恼{研，找到關聯步驟/流程，根據流程還原每個流程下的代表性場景，并拆解出需求。核?步驟提煉成三步：第?梳理出清晰地業務流程、第?將場景歸類到流程中、第三基于場景拆分用戶需求；需要注意的是每個流程下可以寫多個具有代表性的分?場景，同時我們也可以把??標注出來。

示例：場景需求清單

當場景清單足夠龐大時，我們需要對原有的場景需求清單進行抽離，抽離出最關鍵的類別/流程，以及其中不可或缺的場景形成場景需求清單，這?步的核心在于如何抽離（需求理解業務），說到核心場景我們需要前面提到的業務閉環，業務閉環我們可以定義他為為了完成目標下的最小步驟的集合，核心場景即最小步驟的展開，對于最小步驟依賴于對業務的理解，需要站在業務員的角度，來看哪些是不可或缺的，同時我們需要考慮到意外情況下的分支場景，如果出現意外情況而導致業務無法進行，業務無法閉環，那么也會導致用戶放棄使用產品。講到這里我們發現核心場景也是MVP版本。

4. 宏觀與微觀的價值理清（理清價值）

價值主張與需求對應的價值，兩者之間產品的價值主張為判斷需求的價值提供方向和原則，而不同需求價值的積累進?步鞏固價值主張。

價值主張（宏觀）：為特定用戶群體提供差異化價值，價值主張是進行需求判斷的第?原則，SaaS產品應該盡可能滿足每個客戶的個性化需求，但不該包含與價值主張完全不?致的需求。如果在實際工作中遇到需求判斷經常找不到方向，也許應該開始思考產品的價值主張。

需求價值（微觀）：需求的兩種價值?是?戶價值（給產品?戶帶來什么），另外?種是商業價值（給SaaS?商帶來什么），針對用戶（我們提供業務閉環類價值、效用類價值、體驗類價值）、對于SaaS廠商（收入價值、對自身是否能夠采集到更多的業務數據價值）。在SaaS產品中用戶價值中最常見的是效用價值。

5. 如何找出場景中的需求價值

找出價值我們需要做的三件事：第?需求的用戶價值是否與產品價值主張相契合？第二用戶的需求價值具體類型是什么，表現在哪里？第三需求是否存在商業價值，表現在哪里？

6. 如何判斷場景中的需求價值

需求來源于場景，滿足需求則產生價值，?對撲面而來的需求SaaS產品經理更需要清晰理解并判斷需求的價值。SaaS產品為什么更需要理解價值，原因在于SaaS場景都是真實存在的，客戶就是上帝，不存在偽需求，所以需要對?量需求進?判斷。在需求判斷中常規會出現三種場景分別是：

示例：場景需求價值清單

五、我們如何設計業務架構與功能

1. 什么是業務架構

對于SaaS產品首先我們理解場景七要素中的任何?個要素發生變化，都會導致場景不?樣，從而產生不?樣的需求。SaaS產品有非常強的業務屬性，如果缺乏框架性思考，單點設計功能將會讓你精疲力盡，對內部來說不斷堆砌功能，開發成本會越來越?，對外部來說用戶看到的信息繁雜，無法高效的完成任務，所以我們設計功能前需要理清架構，以?種全局的框架視?來思考。

業務架構是?套功能依據業務進?分類整合，形成抽象化的業務模型，架構可以幫我們理清每個業務模塊/功能間的邊界，以及他們之間的關系，在我們?對多個類似的需求時先梳理架構就可以基于場景迅速定位到對應的模塊，在設計功能時我們需要重點考慮以?個功能滿足多個類似的需求。

業務架構：架構的作用在于建立?套標準化的業務模型，搭建框架，最終是為了高效滿足用戶的不同需求。所以也就是我們常聽說的后端標準化，前端個性化。理解業務是梳理功能架構的前提。

示例：微信業務架構

2. 基于目前的場景和需求我們如何梳理架構

梳理架構分成三步?：第?將場景需求清單拆解到功能、第?將功能按不同維度整合、第三梳理模塊之間的邏輯關系；在第?步將功能按不同模塊分類整合時我們先拿出符合通?模塊的功能，進行歸類整合，切記重復造輪?。不符合通用模塊的功能，根據業務重要程度和復雜性單獨整合。如果有必要根據業務重要程度和復雜性，繼續梳理?模塊。在梳理模塊之間的邏輯關系時我們先梳理靜態模塊（不產生數據流），在梳理動態模塊（產生數據流）。整體表面上是梳理架構圖，背后是對業務的深刻理解。

架構本質是后端業務邏輯的標準化；在完成后端標準化之后，隨著產品的不斷發展，我們需要通過可配置的方式在前端滿足?量個性化需求，即前端個性化。因為SaaS產品本身特質，我們需要考慮到大量個性化需求。那么我們需要考慮如何設計?個功能滿足絕大多數需求，核心我們需要運用可配置去解決前端個性化需求和后端業務歸類。

3. 如何設計一個功能滿足不同場景需求

通過可配置化滿足客戶的個性化需求。?般會存在兩種情況，第?是業務流程與現有方案差別較小，那我們可以從功能層面進行配置，第?是業務流程與現有方案差別大，那我們從系統層面進行配置。

在可配置層面?般來說包含界面布局，字段名、驗證邏輯、計算規則、審批流配置，角色配置，角色功能權限配置，用戶配置，用戶數據權限配置等。在產品設計時需要規劃好什么樣的配置功能開放給客戶，什么給到自己。原則上為了避免客戶的復雜度，盡量開放小范圍的配置功能給到客戶自己使用。高配置往往會造成低易用性，配置項過多會帶來頁面不簡潔，流程不高效；本質上來說用戶要的不是配置項，是低成本實現目標的功能。

在判斷功能要不要做成配置時我們可以通過兩個維度來做判斷，?個是模式切換頻率，還有?個則是需求的長尾程度（用戶需求差異化程度），針對?些默認配置項判斷標準我們需要回歸到場景，在大量同?種類型的個性化場景中，找到最核心的場景，并根據場景下的功能設計設置為默認配置項。

六、SaaS產品生命周期中的設計原則

通過前面的文章，我們知道了SaaS產品的方法論之后，我們也應該了解底層的設計原則，了解原則的好處有兩點，通俗的來說一方面是可以驅動產品優化和產品經理本身的自我成長，另一外面則是可以消除外部給你帶來的一些負面影響。

1. 原則是自我改善的有利工具，可以在日常工作中驗證我們自己的方法論，幫助自己成長；
2. 有了原則，就能超脫情緒和環境的影響，自主判斷選擇最佳方案。

本文由 @技術差一般不說話? 原創發布于人人都是產品經理，未經許可，禁止轉載。

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