與C端產品不同，SaaS產品通過挖掘並實現業務場景中的需求而存在。那麼做產品前，我們又要如何挖掘需求呢？筆者認為可以從回歸場景與價值判斷兩部分做起。

在做SaaS產品的過程中，需求並不是憑空產生，而是業務鏈條中實實在在的場景中的需求。

與C端產品不同的是，C端產品可以通過發散的思維創造場景，從而創造需求。

而SaaS產品存在著業務壁壘，只能從業務中還原場景，並且需要將業務鏈條中的所有必備場景都還原出來，否則業務無法閉環，一旦上線，用戶將無法使用甚至需要將整個產品推倒重來。

在對SaaS產品進行需求分析之前，我們需要回歸場景，梳理並描繪出所有必備的業務場景，然後再判斷場景中需求的價值，以判斷該需求到底要不要做。

本文將結合美容院信息管理系統項目中的需求分析，從回歸場景和價值判斷兩個方面闡述需求分析。

一、回歸場景

1. 為什麼需求要回顧場景

產品經理的工作中，可能經常會面臨這樣子的一種情況，老闆提一個需求，說我們要上線一個搶購功能。然後在我們跟研發同學溝通的過程中，就老是被懟，「我覺得這個功能不應該做，我的資料庫又要重構……，我覺得你這個搶購時間有問題……，我覺得人數限制應該是……，」巴拉巴拉一大堆，我們跟研發的吵得不可開交，誰也不服誰。

出現這種情況，除了產品經理自己沒想清楚需求外，還缺少了一種共情的描述需求的方式，來跟研發、乃至老闆、客戶進行有效溝通。

因此我們需要尋找一種介於項目協同的角色之間，大家都能理解的，描述需求的溝通方式，回到場景，看用戶面臨的實際問題是什麼，為什麼會提出這樣子的需求。

2. 通過場景7要素描繪場景

場景7要素指的是，「誰」在某一個特定「環境」下，出現了某一個特定的「時機」，為了達到某一個「目標」，做了一系列「動作」，跟某一「介質」發生了交互，完成了某一特定「任務」。

如：Coco是美容院美容顧問，今天在店裡上班的時候，來了一位進店來的美女，為了留住這個客戶，Coco將美女引到休息區並倒了一杯茶，開始用iPad給美女介紹自家的療程，美女被其中的一個療程吸引並決定做，於是Coco通過iPad下單，並帶美女進了包間。

通過上面的描述，我們就可以和客戶以及研發同學都能很好的溝通需求了。

對客戶：我們的系統可以直接用戶展示美容店內的療程套餐，種類豐富多樣且免除了傳統的紙質手冊的列印成本。顧客選擇好套餐之後可以即時下單，下單信息同步到管理後台，美容師可以馬上看到並準備好套餐所需的物品，提高了溝通效率。

對研發：我們需要創建套餐功能、套餐展示功能、套餐下單功能……

場景7要素所描繪的場景，主要是闡述了用戶有怎樣的需求，並通過怎樣的解決方案達成了這個需求。

如：Coco的需求是為了留住客戶促成下單，往深度需求來說就是通過下單提升自己的業績。她的解決方案是盡心盡責的周到服務，以及對自家業務的專業度，通過系統進行下單，以留住客戶。

3. 場景需求清單-描繪閉環業務鏈條上的全場景

通過對業務的調研，結合上述的場景7要素的描述，我們得到了場景需求清單。

當然，整個業務鏈條中的場景並沒有那麼少，這裡羅列出的是核心的需求場景清單。B端產品研發成本過高，需要在過程中不斷的試錯，核心需求場景清單的特點是，清單中的場景能讓業務形成閉環；清單中每一個場景都有清晰的串聯關係。因此，通過核心場景清單，可以作為版本的疊代驗證產品。

4. 小結

產品設計的過程往往是先做加法再做減法。將所有業務中的角色梳理清楚，深入場景分角色梳理各自的需求，儘可能多的收集，不用怕收集到的是錯的，或者是偽需求，後期我們再通過需求的價值，判斷該需求做不做、為誰做、誰先做等問題。

二、價值判斷

1. 為什麼要做價值判斷

在我們做C端產品的時候，每天掛在嘴上的是用戶體驗，這就要求我們需求考慮極致的用戶價值，以提升產品的用戶量和用戶活躍度。通常都是把流量做起來之後，才會考慮商業變現，可以說是對商業價值的考慮微乎極微。

而SaaS產品不同，SaaS產品天生就是靠賣產品給客戶而賺錢的，因此在考慮用戶價值的同時，更需要考慮需求對自身的商業價值。

2. 價值判斷的兩大原則

在我們對需求價值進行判斷的時候，會通過價值判斷的兩大原則進行判斷：

（1）宏觀層面：產品的價值主張

產品的價值主張指的是，為特定的用戶群體提供差異化的價值。價值主張是一個產品的方向和原則。

比如美容院信息管理系統，它的價值主張是：給美容院企業提供全鏈條的信息化管理服務。

（2）微觀層面：需求的價值

需求的價值包括用戶價值和商業價值

• 用戶價值：該需求給產品的用戶帶來了業務閉環；給用戶帶來了便利性、安全性等效用；給用戶帶來了權威、身份認同等體驗類價值。
• 商業價值：該需求能否促進客戶的簽單和續單，給企業帶來收入；該需求能否採集到足夠的業務數據反哺系統，以帶來更大的價值。

下面來羅列一下美容院信息化管理系統中的一些需求，判斷是否具有商業價值。

對於上表所羅列的一些需求即對應的價值，我們可以看出，像發放優惠券等店鋪營銷模塊，以及跨店儲值等連鎖店鋪管理模塊，可以摘取出來，跟標準版的產品差異開，客戶需要通過付費升級才能獲取的功能，便具有一定的商業價值。

價值主張是價值判斷的第一原則，儘管我們需要儘可能滿足每一個客戶的個性化需求，但與產品但價值主張不一致的需求則堅決不做。

3. 如何判斷需求該不該做

從上述價值判斷的兩大原則我們可以知道，需求該不該做，首先需要符合產品的價值主張，其次還需要判斷該需求是否擁有用戶價值和商業價值。

（1）符合產品的價值主張

我們曾經做過一個商城的項目，當時客戶提出一個需求，希望展示在前端的商品銷量可以後台修改。我們分析一下這個需求的價值。

• 用戶價值：商家可以在後台修改商品的銷量，則用戶購買時可以產生一定的引導作用，對商家而言是有價值的。

• 商業價值：如果我們做了這個功能並設置成收費模塊，則商家也會為了尋求更大的利益而選擇付費，因此也有一定的商業價值。

但是，在我們做這個商城項目之前，我們訂立的產品價值主張是：幫助中小型建材領域的商家成功。而修改商品的銷量這個需求，對於一個成功的商家而言，是恥辱，對於消費者而言，是欺詐，完全違背了價值主張，因此，堅決不做這個需求。

（2）需求的價值

當一個價值符合產品的價值主張之後，我們可以進入下一步，判斷該需求的用戶價值和商業價值。這裡使用象限法進行分析，將商業價值設置為橫坐標，用戶價值設置為縱坐標，得出如下圖。

• 需求1：既有用戶價值也有商業價值，要做。
• 需求2：用戶價值很高但是沒有什麼商家價值，這種需求要謹慎考慮，可以從開發的難易程度，以及投入產出比等方面考慮是否要做。
• 需求3：既沒有用戶價值也沒有商業價值，不做。
• 需求4：商業價值很高但是幾乎沒有用戶價值，雞肋功能，無法創造用戶價值，則沒有用戶使用，即便是再高的商業價值，也是一場空，這種需求也不做。

4. 如何衡量不同角色的需求衝突

在需求分析階段，常常會遇到需求衝突的情況，使用者和管理者的衝突尤為明顯。

管理者的訴求是規範化、流程化、過程可追溯、杜絕損害公司利益的事發生。

使用者的訴求是方便高效、省事，最好還能在某些方面獲得一些利益。

比如在做美容院信息管理系統的時候，在療程下單的時候，店長想要有拍照上傳的功能和協議簽署功能，美容顧問需要在做療程之前跟顧客拍照，並需要顧客簽字。當療程做完之後，需要再次為顧客拍照並上傳。而實際訪談美容顧問時，美容顧問則希望流程能簡單一點，有些步驟可以跳過，因為線下的操作已經夠繁瑣了。

通過對業務的深入了解我們獲悉，做療程前後進行拍照，是需要給顧客看療程前後的對比效果，簽署協議是為了防止顧客因療程效果不佳而產生糾紛。

如果做這個功能，則會使美容顧問的工作變得繁瑣。但如果不做這個功能，店長就無法使自己的服務標準化、流程化，可能就不會為這個產品付費。

因此，綜合考慮之後，我們側重付費者的訴求，優化使用者的體驗。這個功能我們需要做，但是在操作流程上儘可能的讓用戶的任務路徑更短，比如下單直接喚起相機等。

5. 如何判斷需求的優先級

判斷需求的優先級，這裡需要引入一個需求分析模型：KANO模型。

KANO 模型是東京理工大學教授狩野紀昭(Noriaki Kano)發明的對用戶需求分類和優先排序的有用工具，以分析用戶需求對用戶滿意的影響為基礎，體現了產品性能和用戶滿意之間的非線性關係。

• 必備型：滿足業務閉環的基本需要，如果有，用戶也不會很滿意，但如果沒有的話，用戶滿意度為負數，用戶就不會使用我們的產品。
• 期望型：已經滿足基本需求的情況下，如果有該功能，用戶滿意度就會上升；如果沒有該功能，用戶滿意度就會下降。
• 驚艷型：本來用戶沒有這個期望值的，如果有，用戶會感到很驚喜，會覺得該產品體驗很好。

那怎麼使用KANO模型來判斷需求的優先級呢？

（1）將需求按照KANO模型進行分類

我們還是以美容院信息管理系統為例：

將上表進行整理得到下表：

（2）不同的類型中判斷需求優先級

• 必備型：必備型是是業務閉環的最小需求集合，所有的需求都要做，因此不存在優先級。
• 期望型和驚艷型：存在商業價值的優先考慮，其餘的考慮對用戶的效用價值。

總的來說，判斷需求優先級，首頁代入到KANO模型中，將所有的需求按照KANO模型進行分類，然後按照必備型需求>期望型需求>驚艷型需求的優先級進行排序。

然後分層次，判斷每個層次中的需求，商業價值大的優先於商業價值小的，其他的則按照對用戶的效用價值進行排序，最終獲取需求優先級排序表。

三、總結

本文通過回歸場景和價值判斷這兩個方面，對需求調研過程中收集到的需求進行了全面的分析。

首先使用場景7要素的描述方式，結合調研結果，輸出場景需求清單。

其次通過價值判斷的兩大原則——產品的價值主張和需求的價值，判斷需求要不要做，該如何權衡需求衝突。

最後通過KANO模型，來分析需求的優先級，回答哪個需求先做的問題。

做完這一步，產品經理就可以組織開需求評審會了。

作者：客者Aven；公眾號：超越產品思維

本文由 @客者Aven 原創發布於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議