起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識關于SaaS 產品功能設計，我的實踐思考
本文中，筆者將結合自己參與產品重構以及做SaaS產品的實踐，與大家分享一些關于產品功能設計的思考，希望對你有所啟發。
在上篇文章《關于「產品架構設計」，我的實踐思考》中，講述了當時我們是如何做的架構設計。
但在實際工作中，我們更多的還是做功能設計。
如果說架構是骨，那么功能就是其中一塊塊的肌肉，而字段屬于連接整體的經絡，最后這個系統會像人一樣運作起來。
在產品基礎完善期（即生命周期的萌芽期）， SaaS 產品為了滿足核心場景的需求，會不斷的增加功能，滿足對方的業務訴求。
如何高效完成 SaaS 產品的功能設計，這是我作為產品新人的主要工作，因此需要不斷的積累經驗，提高產品方案的質量。
接下來，我會與你分享關于 SaaS 產品功能設計的一些思路，希望對你有用。
01 這個問題，需要通過功能來解決嗎？
我剛入行時，當面對一個業務問題的時候，首先想到的是我該用一個怎樣的功能來解決它，流程是什么樣的，以及原型該怎么畫。
而實際上我提出的解決方案不僅解決不了本質問題，同時因為方案被無數次打回來，導致對自信心的打擊很大，甚至那時候覺得自己不適合做產品。
那么，問題到底出在哪了？
經過這段的時間的沉淀，我發現之前自己「解決問題」的思路不對。
在分析問題時，應該「先定義，再發散，后收斂」。
而不是重復做「收斂」的動作，那樣只會跟無頭蒼蠅一樣亂撞。
因此我總結了一下，當面對一個問題時，應該先明確以下這幾個點。
1. 確定問題與現狀
最常見的方式就是提問，我們需要通過合理和高效的提問，圍繞著問題去收集相關信息。
作為產品經理要時刻謹記一句話，對方說的往往只是解決方案，而非問題和現狀。
意識到這一點，通常我會問這么幾個問題搞清現狀。
（1）你們遇到了什么困難？
要知道，當你用「困難」作為提問關鍵詞時，對方的表達就不再是「我要怎么樣」，而是會說「現在是怎樣」。
因此以這個問題作為開頭，對方會下意識回顧事情發生的始末，回答過程中也會連帶出很多相關信息。
產品經理需要做的，就是基于對業務的理解，對流程、角色、利益關系等關鍵信息保持敏感，完成信息的初步采集。
（2）在系統上如何操作？
我們的目的，肯定是希望產品能夠為對方提供完善的服務。
所以通過「問」和「看」對方在系統上的操作，不僅能確定問題在系統層面的不足，還能發現其他的一些操作問題。
（3）目前是如何解決的？
最常見的情況，就是系統還沒有做相關的解決方案，也就是這部分業務問題在系統上是缺失的。
那么我們就需要做相關的業務調研，從功能的層面去解決這個問題。
2. 最簡解決方案
我們都說做產品要做 MVP（最小可行性），其實做功能也是一樣。
我們要以最簡單的方式來解決對方的問題，方便日后的拓展，或是重做。
這里要切記「最簡」不代表「缺失」，業務閉環是做 SaaS 產品基本邏輯。
（1）已有功能的優化
有的時候不是我們沒有這個功能，而是這個功能對方不知道，或者是說用不起來。
作為產品經理，需要對當前系統已有功能非常的了解。
那么面對這種情況，可以選擇先做系統層面的講解，然后再去考慮如何優化。
（2）視覺或交互上的調整
這里的核心理念，還是用最小成本去解決對方的問題。
比如組織架構的樹狀展示方式，單擊是選中，雙擊是折疊 / 收起操作，這就能解決他們查看對應層級人員的視覺干擾問題。
（3）利用通用功能（增刪改查）來解決
這些功能既通用，認知成本又低，作為基礎的解決方案正合適。
比如客戶存在任務執行一半，要求不必再做的問題，我們需要先考慮「刪除」這個功能能否解決問題，而不是上來就做一個「任務停用」的功能。
如果上面這些問題你都搞清楚、弄明白了，那么接下來就會進入到功能設計的階段。
02 設計功能，滿足客戶的個性化需求
對于 SaaS 產品來說，客戶的需求存在多樣化，因此在設計功能時一定會考慮「可配置」。
這么做的目的，一是希望前端頁面簡潔高效、內容清晰，且能夠滿足不同客戶的業務需求。二是對于后端的功能配置，能夠做到歸類清晰、不雜亂。
那么我們該如何去做呢？
首先我們需要判斷，業務流程與現有方案差別的大小。
如果差別大，我們需要從系統層面來配置，比如線下教育行業的上課流程存在兩種。
那么對于少數企業的情況，可以考慮在面對這些用戶時，將系統邏輯后臺寫死。
但如果業務流程與現有方案差別小，那僅從功能層面進行配置即可，這種就很常見了。
然后就進入到具體的功能設計流程，主要分為 3 個步驟。
1. 找到對應模塊
如果說每個模塊是解決「一類業務問題」，那么每個功能就要對應解決「單個業務問題」。
例如我之前做的一家少兒編程機構的管理后臺，主模塊分為市場管理、銷售管理、教師管理、教務管理等。
那么對于線索回海這個業務問題，肯定要在銷售管理模塊下做功能設計。
2. 判斷是否做成可配置
先用一套四象限法則，介紹一套判斷的方式。
上圖來自網絡
先說一下第二象限，對于 SaaS 產品來說，如果我們選擇要滿足企業的個性化需求，尤其是他們占比還比較小，那我們要重點考慮「商業價值」。
如果對方希望你能幫他解決，但不愿意付錢，那么就要提高警惕了，這個業務問題對企業來說不價值沒那么大。
再說一下第四象限， 這里重點要從 SaaS 產品公司的 ROI（投入產出比）來分析，不能為了滿足客戶而忽略公司的生存。
最后就是第一象限和第四象限，這其實比較好理解，這里就不做過多贅述。
3. 設計它的默認設置項
這里需要產品經理能夠從大量客戶的個性化場景中，找到最核心的場景，并以此為依據將該選項作為功能的默認配置。
這樣做的本質，是希望減少誤操的可能性。
寫在最后
當然，任何事物都存在兩面性，實際中也不要將所有功能都作為「可配置」。
一來這樣會降低系統的易用性。
要知道，客戶要的不是你的可配置，而是能高效、簡潔的完成自己的工作內容，而每個配置項意味著對方需要多一步思考。
過多的配置項不僅造成頁面的不簡潔，同時也會增加流程的步驟。
二來會帶來極高的開發成本。
如果配置項中的另一種選擇沒有客戶使用，這無疑也是在浪費開發資源。
而這個問題的起因，又回來到了產品經理對業務的理解能力不足，需要加強業務調研的能力。
以上就是我對 SaaS 產品功能的設計的理解，接下來就是希望你我在實踐中，不斷的理解與調整。
愿你我一起加油，共同成長~
作者：空；公眾號：小木盒產品記
本文由 @空 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議。
對于需要對接老的系統的需求，如果系統沒有提供接口，用什么方式進行兩個系統的數據對接？
MQ消息是否可行？
功能可配置固然是美好的，但用戶的使用難度和開發難度會增加好多，不能為了炫技術而增加用戶成本?？膳渲靡话闶窃诨景姹玖鞒虥]問題的基礎上優化而來。
個人覺得：SAAS平臺能力，給了產品和客戶打破固化思維束縛的能力，激發了產品和業務開放思維模式，以全新的思路去思考和重構
什么叫模式切換頻率，能舉例說明么
以某信舉例，設置 → 隱私里的「加我為好友時需要驗證」，這個功能就可配置。
對于我們這種普通用戶，我們常是作為開啟；
對于一些公開號，通常會作為關閉；
這當中的切換就涉及到頻率。
當然，對于大體量產品，就算只有0.1%的用戶存在這方面訴求，體量也很驚人了。