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