對 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協議

,