起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識SaaS 產品設計中，如何理解產品與需求？
SaaS 產品的需求處理跟其他產品不同，本文作者基于 SaaS 產品的特點，分享了在SaaS 產品處理需求過程中的一些思考。
不知道作為 SaaS 產品經理的你，在日常工作中會不會經常碰到下面這些情況：
- 銷售：“我跟你講，這個客戶試用后提出了這么幾個需求，你趕緊推進做了，我就能繼續推進簽單?！?/li>
- 運營：“你們能不能做個人員導入的功能??？這樣我們和客戶新增人員的時候就不用一個一個添加了?！?/li>
- 老板：“當下這個需求很緊急，其他的先放放，優先做這個?！?/li>
這個時候，作為產品經理的你，該怎么辦？
要知道，每個客戶都是公司的上帝，況且這些問題都在實際的業務場景中真實存在，很少存在憑空想象的偽需求。
所以對 SaaS 產品經理來說，重點不是如何過濾需求，而是能夠做出需求價值的判斷，持續為客戶提供服務。
那么接下來，我會闡述一下關于 SaaS 產品「需求價值」的理解，希望能幫到你。
一、明確產品和需求的價值
1. 知己，理解產品的價值主張
產品的戰略主張是需求過濾篩選的第一步，而早在產品設計之前，戰略主張就已經確定了。
簡單說，可以將它理解為產品的戰略層，通常是由老板和公司高層制定。
而處于執行層的我們大多數情況不會參與制定，只需要理解并在產品推進過程中貫徹這一理念。
比如某公司做的是餐飲行業做智能視頻監控管理，這時有客戶提出一個“需求”，希望希望能在管理后臺，可對部分違規項進行隱藏處理。
同時對方承諾如果上了這個功能，在續約的同時還會幫你介紹新的客戶。
說白了，這個功能背后存在很客觀的商業價值。
這時你會不會動心呢？先別急，讓我們來分析一下這個“需求”。
首先，將這個“需求”回歸業務場景，思考并調研他們要解決的目標問題是什么。
在了解后發現，他們在做向上匯報時，隱藏某些巡檢項可以減少相應的處罰。
而這就是他們間接向業務人員反映提出這個“需求”的動機。
要知道通常來說，業務人員的關注點補上問題背后的含義和動機，而是這個客戶能否拿下。
因此也會很容易將他們的“需求”，直接傳遞給產品經理。
當然，這個例子說的比較直，在實際場景中其實復雜很多。
回歸到公司產品的價值主張，是希望幫助商家杜絕后廚人員的違規，提高吃客的餐飲安全。
而隱瞞意味著會淡化監管，導致違規項無法整治，最終影響吃客的食品安全。
所以這個“需求”，顯然是違背了產品的價值主張，即使這個“需求”存在巨大的商業價值，產品經理也絕對不能妥協去做。
換句話說，這也是作為一名產品經理的底線。
到這里你可以想想，你們公司產品的價值主張是什么？
說實話，很多產品經理是不清楚的，甚至公司管理層都沒想明白，這時候就需要我們自己思考并明確產品的價值主張了。
不僅是為產品負責，也是為自己負責。
2. 知彼，判斷需求的價值
這里結合 SaaS 產品，從客戶價值和商業價值兩個維度去分析。
（1）客戶價值
SaaS 產品是對企業業務的一種解決方案，因此首先需要夠保證業務的閉環，也就是滿足「可用」。
先不說業務上的提效與降本，如果企業上下游的業務人員都用不起來，這款產品本身也就沒有價值。
所以在處理 SaaS 產品的業務閉環上，首先需要將核心流程和分支流程都考慮在內，設計時要做到先增后減。
其次是需要達到「易用」，比如人員的批量導入，通訊錄部分人可見，這類需求不會影響業務的整體閉環，但會讓客戶使用起來更方便。
最后就是「好用」，而這對于 SaaS 產品來說更偏向「個性化」，比如管理層的頭銜，重要人員的標簽區分。
目前我接觸到「個性化」需求，更多的是數據看板的模型和導出 excel 表的樣式，這些需求往往會伴隨著更多的商業價值。
所以這里要記住一點，對方提出的任何需求都是圍繞著企業業務展開的，產品經理需要時刻保持好奇心，挖掘背后的含義。
（2）商業價值
對于 SaaS 產品來說，讓客戶簽單和續約是最常見的方式。
除此之外經常被忽略的一點，就是對業務數據的采集。
對于我們公司的視頻監控智能算法來說，需要通過不斷的采集、識別、矯正，反復訓練來提高識算法的準確性。
因此會采取免費試用與接入對方攝像頭的策略，推廣讓更多的商家去使用。
要知道如果是免費的產品，對方的心理預期不會很高，容忍性也比較強，同時也會提出很多的建議。
總結來說，產品的價值主張為需求價值的判斷提供方向和原則，而需求價值反哺產品進一步鞏固價值主張。
二、價值是需求判斷的風向標
根據上面的闡述，我們明確了「產品價值主張」和「需求價值」，接下來需要進行需求的實際判斷。
這里列舉以下幾種常見的情況。
1. 我們要做哪些需求
這里舉一個我自己的反例：
產品是將實體門店巡檢線上化，實現信息化管理。
我們系統早期沒有權限管理模塊，只有后臺寫好的一些權限，而且是用「職位」這個字段做過渡。
然后有客戶提出了這么一個問題，目前他們會使用公司內部的人做門店的暗訪巡檢，也就是說這個人在公司本身可能是「財務人員」，但他這時需要「神秘顧客」的身份，那么在填寫他職位的時候就無法完成。
當時我在接到這個需求時，沒做深入的理解，就配合產品經理做了落地，最后用一個標簽「神秘顧客」的方式“解決了這個問題”。
結果等了幾周這個功能上線后，人家早就用職位填寫神秘顧客這個方式解決了。
事后我去反思這件事，發現雖然業務場景不存在偽需求，但問題要不要解決，需要產品經理深思熟慮后做出判斷。
實際上，如果我們的產品有財務模塊，這個問題本質其實是權限分配的問題。
而這種情況，我們應該圍繞著產品的已有功能，引導用戶只填寫「神秘顧客」行不行，如果不行還會存在什么問題，一步一步深挖場景和問題。
這才是解決問題的方式。
那么下次，如果對方提出了具體的問題，我會如何進行功能價值判斷呢？
這里用四象限來提供一個判斷模型，這里需要注意的是第二象限與第四象限。
2. 權衡業務鏈間的不同角色
首先強調一點，SaaS 產品服務的是購買決策人。
因為很簡單，他們才是購買 SaaS 產品客戶，而那些一線的執行人員，并非決策人員，優先滿足他們不會帶來任何商業價值。
因此從客戶企業和自身公司考慮，產品經理首先要判斷決策人是誰，以他作為中心向四周發散來解決問題。
但要注意，這里并不是說忽略使用者的體驗，而是要想辦法做到平衡。
舉個例子：
某企業區域負責人會要求督導巡檢上報執行結果，可以理解為寫日報的這種方式。
但實際上，有的督導一天會巡檢多家門店，也就是他們會巡檢完成一家門店，寫報告然后提交，然后再巡檢下一家門店。
那么對于這個問題，你會如何解決呢？
最簡單的方式就是做個寫日報的功能，然后讓督導每日完成即可。
實際上你可以想象，這個功能上線后一定會增加他們的工作量，導致巡檢的降效，執行人員的抱怨。
而如果從業務場景和問題的角度去分析，我只要讓上級負責人能夠看到執行結果即可。
因此對于這個需求，最后的解決方案是在 PC 端選擇任務抄送人，完成后抄送人會收到報告和數據統計的結果。
這樣區域負責人不僅可以選擇性的查看，同時督導也不需要每天寫巡店報告。
3. 評估需求的優先級
SaaS 產品需要按照業務流程排列需求優先級，在「02 知彼，判斷需求的價值」中已經提到。
這里再借助 Kano 模型做詳細說明。
（1）必備型需求
這類需求屬于對方工作流中不可或缺的基礎，對此重點不是要不要做，而是要怎么才能做好。
舉個例子：
通常來說，企業管理的方式一般是自上而下，這也是產品目前的核心流程。
但由于這次疫情，會存在自下而上的匯報，也就是除管理者下派的任務，底層執行人員會根據店內情況做問題上報。
首先這個需求符合產品定義，其次結合業務場景，它的價值是能補充業務閉環。知道很多企業，會要求門店人員即時上報門店情況，并做到信息留檔。
對此我們的處理方式，先基于疫情做了一個「疫情上報」，放在 App Banner 位，做初步功能驗證和迭代調整，而后續可以作為新功能正式上線。
（2）期望型需求 + 興奮型需求
通常會伴隨著興奮型需求一起提出，而我們要考慮這個需求能否解決對方關鍵的業務問題。
畢竟對于 SaaS 產品來說，收入的途徑主要還是靠產品能否賣的出去。
而除此之外的需求，可以從影響面和?ROI?兩個維度去進行排序。
常見的就是數據看板內容，以及數據導出的樣式，而這里要注意一些用戶價值高，但商業價值不明顯的需求，比如人員導入。
事實上這類需求只能說讓對方用起來更方便，但帶來商業價值程度很低。
因此這類需求要結合對方的忍受程度，做謹慎考慮。
寫在最后
以上就是關于 SaaS 產品設計中，如何理解產品與需求，到如何判斷需求優先級的思考分析框架，也是我現在接到需求后，做出判斷的回復對方的依據。
但說實話，想要完全掌握，實際上還是蠻困難的，我現在也只能稱得上入門而已。當然這也是一個好的開始，慢慢地在實踐中不斷的反思與修正它，最后成為自己思考和分析的習慣。
實踐的積累會讓我們的決策質量越來越高，能夠從容面對更多復雜的情況。
讓我們一起加油，一起共勉。
作者：空，公眾號：小木盒產品記
本文由 @空 原創發布于人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基于CC0協議
謝謝分享，復盤能得到很多收獲。