SaaS産品設計方法論

有這樣一(yī)個場景：

老闆：我(wǒ)有⼀個特别棒的想法，優先級很高，你趕緊把方案産做出來。

産品經理：保證效率！我(wǒ)馬上就開(kāi)始畫原型，然後内部評審，接着推進開(kāi)發。

這時候部分(fēn)産品經理急于表現，需要将需求快速落地，第⼀反應就是開(kāi)始執行，所以經常會發生(shēng)⼀種情況，産品經理很努力的去(qù)做，把需求或想法百分(fēn)百的去(qù)還原，但結果老闆或用戶體(tǐ)驗完之後發現，這并不是我(wǒ)想要的功能。

出現這種情況的原因是産品經理沒有了解到這個需求背後的動機和目的，這是很多小(xiǎo)夥伴容易出現的問題。而SaaS産品設計，不僅僅隻關注設計，在此之前我(wǒ)們更要關注産品的定義。需要我(wǒ)們想清楚這個需求對應的場景是什麽，場景中(zhōng)的需求價值是什麽。之後才是結構化的框架把功能設計出來。

1.    SaaS産品設計痛點場景拆分(fēn)

1.1. SaaS産品經理的工(gōng)作方式

SaaS産品經理⼯作本質是從發散到收斂的⼀個過程。發散是指産品的定義，收斂是指産品的設計。但往往很多産品經理⼀上來就開(kāi)始收斂了，開(kāi)始畫原型，好⼀點的産品經理可能先去(qù)思考這個功能影響的範圍，影響的面。最後梳理出⼀個腦圖，用這個腦圖去(qù)跟開(kāi)發去(qù)碰，但是⼀個優秀的産品經理除了⼀上來就收斂之外(wài)，其次需要我(wǒ)們思維先發散，最終産品定義這個場景對應的價值是什麽。理解業務是進行需求梳理與功能設計的前提。

2.    SaaS産品不同維度的認知(zhī)

2.1.     SaaS産品認知(zhī)的歧義

很多人認爲SaaS産品是toB産品，但從本身定義軟件即服務來看，即沒有說是toB也沒有說是toC。而廣義的SaaS定義是既有toB也有toC（比如印象筆記/石墨⽂檔）。從軟件交付方式來講，SaaS本身作爲一(yī)種交付模式，本身不存在toB或toC之分(fēn)。從商(shāng)業模式來講，如果我(wǒ)們把toB産品定義爲基于互聯網提供服務，⽤以提升企業效率，增加企業收⼊的産品，那麽SaaS産品可以算是B端産品的⼀個分(fēn)支。

2.2. SaaS産品不同維度的認知(zhī)

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

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

SaaS産品特點：

雲端架構：SaaS公司提供服務器、數據庫等硬件，無需本地部署；

成本下(xià)降：無需客戶承擔基礎設施成本、日常運維成本，付費(fèi)靈活；

用戶按月/年支付費(fèi)用，而非⼀次性購買，體(tǐ)驗提升；

後續升級維護由SaaS公司負責，通過數據驅動叠代。

SaaS産品業務階段：整體(tǐ)劃分(fēn)爲四個階段，基礎産品完善期、行業産品深入期、生(shēng)态建設期、再創新。

3.  我(wǒ)們通過什麽方式去(qù)理解業務

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

對業務的理解我(wǒ)們可以由抽象化轉換爲具象化，本質需要從行業模式和運作流程去(qù)了解。懂行業模式是要能夠理解約定俗成的玩法和規則是什麽。懂運作流程是行業中(zhōng)某個企業不同崗位/角色如何各司其職的。運作流程是行業模式的直觀體(tǐ)現，行業模式⼜爲理解運作流程提供指南(nán)針。

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

⾏業模式：從宏觀角度，我(wǒ)們了解行業内企業相應業務的玩法，從而抽象出通用的玩法和規則，這樣我(wǒ)們才可以了解企業的核心痛點，其次也爲SaaS産品及服務提供方向指南(nán)。

運作流程：從微觀角度，對于每個企業我(wǒ)們需要了解企業内部不同員(yuán)工(gōng)是如何操作的，最終實現公司業務運轉，了解這些才能使我(wǒ)們産品設計更加落地。

3.2.     行業模式（宏觀）：如何快速了解一(yī)個行業

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

網上做行業分(fēn)析的方法有很多，重要的是需要找對維度，不能隻停留在大(dà)範圍層面，而是需要聚焦于我(wǒ)們自身業務的邊界。關于維度層面這邊跟大(dà)家分(fēn)享五個分(fēn)析行業的維度，分(fēn)别是：行業基礎信息、外(wài)部經營環境、内部市場環境、标杆企業分(fēn)析、SaaS競品分(fēn)析；

通過上訴幾個維度我(wǒ)們可以快速了解⼀個行業，但是往往實際工(gōng)作場景是我(wǒ)們做出了⼀份分(fēn)析報告，但不知(zhī)道真正作用在哪⾥。這種情況下(xià)需要回歸到本質，我(wǒ)們是爲了了解行業通用規則和玩法，最終服務于自身SaaS業務。

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

先講講C端産品的用戶調研與SaaS産品業務調研的區别，C端用戶調研隻需要關注單點用戶，SaaS業務調研需要全盤考慮整個業務流程，這也是很多轉行做SaaS産品經理會按照以前的調研方式，去(qù)做業務調研，容易導緻産品流程上沒有閉環。其次C端⽤戶調研需要以用戶體(tǐ)驗爲中(zhōng)心，相對于來說SaaS産品更關注需求，解決了什麽業務問題。最後C端産品用戶需求層面相對于容易抽離(lí)共性，SaaS天然存在大(dà)量個性化需求且極度分(fēn)散。而且C端産品⼀般都是用戶可以通過共情來挖掘潛在需求，SaaS産品經理通常不是用戶，需要通過理解業務來挖掘需求。

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

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

業務調研整體(tǐ)分(fēn)三步：

第⼀：定義并選擇标杆企業。在這裏需要定義标杆企業的客戶畫像，以标杆企業的需求爲核心。客戶畫像包含（客戶/企業規模、從屬細分(fēn)類目、業務範圍），在這裏面爲什麽我(wǒ)們需要選擇标杆企業的原因是在于标杆企業需求具有代表性，相對容易抽離(lí)。其次也是因爲标杆企業的聲音有影響力，後期能夠引領其他客戶。

第⼆：梳理業務鏈條的⻆⾊。在這⼀步梳理好業務流程中(zhōng)的關鍵角色之後，我(wǒ)們需要定義角色的特征（主要負責什麽、業務目标标/KPI是什麽、職業特點是什麽），怎麽找到這些業務流程中(zhōng)的關鍵角色，第⼀可以從企業的組織架構中(zhōng)尋找，這是最便捷也是最直接快速的方法。在得不到組織架構的情況下(xià)，可以參考同類型企業的流程及角色（當然這裏的企業也是屬于标杆企業），在做整體(tǐ)角色梳理的時候我(wǒ)們必須要注意業務的閉環，如果忽略了業務鏈條不重要的角色，可能會導緻業務無法閉環。

第三：觀察與調研并行。在梳理完業務流程之後我(wǒ)們需要通過觀察與調研，理清角色的工(gōng)作流（核心流程）。對于SaaS産品來說，觀察比直接開(kāi)放(fàng)式調研更有效，這麽說的原因是在于産品很難從根上去(qù)撼動絕大(dà)部分(fēn)公司的業務模式，所以我(wǒ)們側重在還原業務，而非創造業務，還有⼀個原因是調研過程中(zhōng)多少都會有主觀成分(fēn)在，所以需要通過觀察還原業務。

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

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

4.  如何梳理業務判斷需求價值

很多産品經理在做了⼀波業務調研之後，也對業務有了⼀定程度的理解，認爲接下(xià)來就該到需求分(fēn)析了。其實不是這樣，除了對業務要有⼀個深度了解之外(wài)，還需要還原業務中(zhōng)遇到的場景是什麽，用戶需求價值是什麽。如何去(qù)判斷需求的價值，其實本質是我(wǒ)們需要在産品定義這個環節去(qù)梳理清晰。

産品定義分(fēn)兩個部分(fēn)：第⼀回歸場景（梳理并描述業務場景），第⼆理清價值（判斷場景中(zhōng)需求的價值）。

4.1.     爲什麽要回歸場景？

在這描述兩個我(wǒ)們常見的工(gōng)作場景，很多時候産品經理在提出産品方案時，大(dà)家圍繞實現細節開(kāi)始讨論的時候容易出現，‘我(wǒ)覺得’的⽅式來表達自己的觀點，每個人都有自己的想法，無法達成統⼀的意見。還有⼀種情況是在沒有理解場景的情況下(xià)直接開(kāi)始畫原型，這時候會出現我(wǒ)們産品上線之後總是不符合實際線下(xià)流程，還得推倒從來。

現在我(wǒ)們回想上⾯兩個場景中(zhōng)爲什麽出現這種情況，本質是因爲産品經理對外(wài)（項目組其他人），完成⼀項任務肯定是需要多個部門多個角色頻(pín)繁的傳遞用戶需求，因此使用一(yī)套易理解，貼近實際的溝通的⽅式就很重要，而場景就是通行于不同角色之間解決産品問題的語言。

對内（自身思考）産品設計我(wǒ)們需要先發散後收斂，因此動⼿畫原型，寫文檔之前我(wǒ)們需要做⼤量的思考，調研。邏輯基點是用戶⾯臨的實際情況到底是什麽樣的，即回歸場景。

4.2.     單個場景與多個場景

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

4.3.     場景我(wǒ)們該如何去(qù)描述

回歸場景我(wǒ)們需要通過⼀種通⽤的場景描述方式，對内形成自己的思考基點，對外(wài)讓大(dà)家形成共識。在這裏跟大(dà)家分(fēn)享⼀種場景描述方法，場景描述的7要素（用戶、環境、時機、目标、動作、截止、任務）SaaS産品的場景是真實存在的，不是憑空捏造的。需要在真實業務中(zhōng)得到驗證。場景描述方式本身不重要。重要的是對外(wài)能夠形成統⼀的認知(zhī)，對内思考能夠還原用戶實際情況才是關鍵。

針對單⼀的場景我(wǒ)們可以通過單⼀場景描述方式去(qù)還原，針對多個場景時我(wǒ)們可以借助場景需求清單，場景需求清單是多個場景串聯形成的結構化信息，他是⼀個業務鏈條下(xià)的場景拆分(fēn)後的需求集合，場景需求清單可以幫助我(wǒ)們梳理業務鏈條下(xià)的場景關系，避免遺漏影響業務閉環的場景。基于之前的調研，找到關聯步驟/流程，根據流程還原每個流程下(xià)的代表性場景，并拆解出需求。核⼼步驟提煉成三步：第⼀梳理出清晰地業務流程、第⼆将場景歸類到流程中(zhōng)、第三基于場景拆分(fēn)用戶需求；需要注意的是每個流程下(xià)可以寫多個具有代表性的分(fēn)⽀場景，同時我(wǒ)們也可以把⻆⾊标注出來。

當場景清單足夠龐大(dà)時，我(wǒ)們需要對原有的場景需求清單進行抽離(lí)，抽離(lí)出最關鍵的類别/流程，以及其中(zhōng)不可或缺的場景形成場景需求清單，這⼀步的核心在于如何抽離(lí)（需求理解業務），說到核心場景我(wǒ)們需要前面提到的業務閉環，業務閉環我(wǒ)們可以定義他爲爲了完成目标下(xià)的最小(xiǎo)步驟的集合，核心場景即最小(xiǎo)步驟的展開(kāi)，對于最小(xiǎo)步驟依賴于對業務的理解，需要站在業務員(yuán)的角度，來看哪些是不可或缺的，同時我(wǒ)們需要考慮到意外(wài)情況下(xià)的分(fēn)支場景，如果出現意外(wài)情況而導緻業務無法進行，業務無法閉環，那麽也會導緻用戶放(fàng)棄使用産品。講到這裏我(wǒ)們發現核心場景也是MVP版本。

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

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

價值主張（宏觀）：爲特定用戶群體(tǐ)提供差異化價值，價值主張是進行需求判斷的第⼀原則，SaaS産品應該盡可能滿足每個客戶的個性化需求，但不該包含與價值主張完全不⼀緻的需求。如果在實際工(gōng)作中(zhōng)遇到需求判斷經常找不到方向，也許應該開(kāi)始思考産品的價值主張。

需求價值（微觀）：需求的兩種價值⼀是⽤戶價值（給産品⽤戶帶來什麽），另外(wài)⼀種是商(shāng)業價值（給SaaS⼚商(shāng)帶來什麽），針對用戶（我(wǒ)們提供業務閉環類價值、效用類價值、體(tǐ)驗類價值）、對于SaaS廠商(shāng)（收入價值、對自身是否能夠采集到更多的業務數據價值）。在SaaS産品中(zhōng)用戶價值中(zhōng)最常見的是效用價值。

4.5.     如何找出場景中(zhōng)的需求價值

找出價值我(wǒ)們需要做的三件事：第⼀需求的用戶價值是否與産品價值主張相契合？第二用戶的需求價值具體(tǐ)類型是什麽，表現在哪裏？第三需求是否存在商(shāng)業價值，表現在哪裏？

4.6.     如何判斷場景中(zhōng)的需求價值

需求來源于場景，滿足需求則産生(shēng)價值，⾯對撲面而來的需求SaaS産品經理更需要清晰理解并判斷需求的價值。SaaS産品爲什麽更需要理解價值，原因在于SaaS場景都是真實存在的，客戶就是上帝，不存在僞需求，所以需要對⼤量需求進⾏判斷。在需求判斷中(zhōng)常規會出現三種場景分(fēn)别是：

5.   如何設計業務架構與功能

5.1.     什麽是業務架構

對于SaaS産品首先我(wǒ)們理解場景七要素中(zhōng)的任何⼀個要素發生(shēng)變化，都會導緻場景不⼀樣，從而産生(shēng)不⼀樣的需求。SaaS産品有非常強的業務屬性，如果缺乏框架性思考，單點設計功能将會讓你精疲力盡，對内部來說不斷堆砌功能，開(kāi)發成本會越來越⾼，對外(wài)部來說用戶看到的信息繁雜(zá)，無法高效的完成任務，所以我(wǒ)們設計功能前需要理清架構，以⼀種全局的框架視⻆來思考。

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

業務架構：架構的作用在于建立⼀套标準化的業務模型，搭建框架，最終是爲了高效滿足用戶的不同需求。所以也就是我(wǒ)們常聽(tīng)說的後端标準化，前端個性化。理解業務是梳理功能架構的前提。

5.2.     基于目前的場景和需求我(wǒ)們如何梳理架構

梳理架構分(fēn)成三步⾛：第⼀将場景需求清單拆解到功能、第⼆将功能按不同維度整合、第三梳理模塊之間的邏輯關系；在第⼆步将功能按不同模塊分(fēn)類整合時我(wǒ)們先拿出符合通⽤模塊的功能，進行歸類整合，切記重複造輪⼦。不符合通用模塊的功能，根據業務重要程度和複雜(zá)性單獨整合。如果有必要根據業務重要程度和複雜(zá)性，繼續梳理⼦模塊。在梳理模塊之間的邏輯關系時我(wǒ)們先梳理靜态模塊（不産生(shēng)數據流），在梳理動态模塊（産生(shēng)數據流）。整體(tǐ)表面上是梳理架構圖，背後是對業務的深刻理解。

架構本質是後端業務邏輯的标準化；在完成後端标準化之後，随着産品的不斷發展，我(wǒ)們需要通過可配置的方式在前端滿足⼤量個性化需求，即前端個性化。因爲SaaS産品本身特質，我(wǒ)們需要考慮到大(dà)量個性化需求。那麽我(wǒ)們需要考慮如何設計⼀個功能滿足絕大(dà)多數需求，核心我(wǒ)們需要運用可配置去(qù)解決前端個性化需求和後端業務歸類。

5.3.     如何設計一(yī)個功能滿足不同場景需求

通過可配置化滿足客戶的個性化需求。⼀般會存在兩種情況，第⼀是業務流程與現有方案差别較小(xiǎo)，那我(wǒ)們可以從功能層面進行配置，第⼆是業務流程與現有方案差别大(dà)，那我(wǒ)們從系統層面進行配置。

在可配置層面⼀般來說包含界面布局，字段名、驗證邏輯、計算規則、審批流配置，角色配置，角色功能權限配置，用戶配置，用戶數據權限配置等。在産品設計時需要規劃好什麽樣的配置功能開(kāi)放(fàng)給客戶，什麽給到自己。原則上爲了避免客戶的複雜(zá)度，盡量開(kāi)放(fàng)小(xiǎo)範圍的配置功能給到客戶自己使用。高配置往往會造成低易用性，配置項過多會帶來頁面不簡潔，流程不高效；本質上來說用戶要的不是配置項，是低成本實現目标的功能。

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

6.  SaaS産品生(shēng)命周期中(zhōng)的設計原則

通過前面的說明，了解了SaaS産品的方法論之後，我(wǒ)們也應該了解底層的設計原則，了解原則的好處有兩點，通俗的來說一(yī)方面是可以驅動産品優化和産品經理本身的自我(wǒ)成長，另一(yī)外(wài)面則是可以消除外(wài)部給你帶來的一(yī)些負面影響。

原則是自我(wǒ)改善的有利工(gōng)具，可以在日常工(gōng)作中(zhōng)驗證我(wǒ)們自己的方法論，幫助自己成長；

有了原則，就能超脫情緒和環境的影響，自主判斷選擇最佳方案。