作為産品經理，你做完一件事，别人問你怎麼做的，你能說好嗎？如何在說的過程中，體現出你的邏輯思考能力、需求分析能力、優先級排序能力和解決問題的能力？如何讓你的經曆變成經驗，變成可遷移的能力，變成别人可複制的技術？

今天給大家介紹一個案例，主人公叫Ver。他是我的學員，Ver曾給我講了一個故事，聽完他的故事之後，我覺得這就是産品經理的工作典範，能成為複制到需求分析階段的藍本，照着這個做，不會有問題。

一、故事背景

Ver之前在一家在線教育公司，做面對學校的基于SaaS平台的在線排課系統。這一看就是TO B的産品崗位，B端客戶，那都是客戶爸爸呀。可李悅就是把B端金主爸爸的需求優先級排在了後面，為什麼他敢這麼幹？

大家都知道，從事B端的産品經理可能經常會遇到這樣一種情況：當你已經完成最近的需求排期後，新功能開發也在有條不紊地進行，這時候，BD和銷售卻跑過來跟你反饋說，有一個重要客戶急需某個功能，需要我們盡快開發出來，這時你應該怎麼做，是趕緊去重做需求排期嗎？

其實，不止是B端，還是C端，總會有一些臨時突發的需求出現，發生這種情況的時候，很可能就打破我們之前的産品節奏了。更何況，作為産品經理，你是接受需求的前線，你接到需求後，和研發去提，研發不同意咋辦？這是一個天雷，劈在了你的身上，到底怎麼辦呢？

别急，身為産品經理的我們需要有一套清晰的邏輯思維去甄别、去分析，這時我們可以使用産品經理最常用的“三闆斧”——用戶、場景、需求。

萬變不離其宗，“用戶——場景——需求”這個公式，一定要變成下意識的判斷。

二、确定用戶

首先我們要知道提需求的人是誰，可能有人說，當然是用戶了。但我們了解真的了解我們的用戶嗎？

我們知道，B端産品服務的對象通常是企業、商戶、政府部門、事業單位等。

通常情況下，決定是否使用産品的決策人和真正的産品使用者并不是同一類人，很可能是上下級的關系，而産品面向的使用者通常是對應某類職業的人群。

這時請注意，這類人在使用産品時的身份标簽是他所做的職業，産品面對的用戶是剝離個體興趣，更多是帶有集體屬性的人群。

這也意味着用戶更關注産品能否滿足我所做的業務場景需要，至于頁面美不美觀，圖标好不好看，并非核心重點。

三、場景需求分析

面對需求，我們應該有什麼樣的處理方式呢？

首先，任何需求都是基于場景的，我們需要弄清楚：用戶提到的需求中的場景是什麼？

一天銷售跟我說：“學校老師希望在“教師無課查詢”模塊裡面，增加“文件導出功能”，并說是老師特别提出來的，是個剛需。”

這時，我跟銷售說：“需要跟老師進一步溝通下這個需求的具體場景。”

之後老師表示需要根據無課的時間情況做調課，但因為有時出差在外不方便，所以需要導出文件用手機看。

這時就可以發現：老師提出的需求場景是實際存在的，但他提出的需求并不是真正能完成他任務的需求，而給出一個問題的解決方案。

請注意這裡，老師是直接提出了一個解決方案。這是什麼意思呢？

一個問題，往往包括了兩部分：一部分是問題空間的，隻有問題；另一部分是解決方案空間的，是這個問題的解決方案。

很多時候，用戶或者産品經理，其實都會把問題空間的事情，直接變成解決方案空間的。就問題而言，這裡老師遇到的問題是什麼呢？

老師的問題是：如何在無課的時候進行調課？

所以，通過進一步詢問，就會發現：其實老師真實需求是需要在移動場景下去完成工作上的調課，真正需要做的是做移動端的調課功能，而不是導出課表文件。

導出課表文件，能讓老師收獲一個什麼呢？

老師能收獲一個課表文件，然後老師就在課表文件上，找哪裡沒有課程？找到之後呢？老師就會想着把課程調到這裡呀。但是，之後怎麼辦？老師肯定還會和銷售說，我想把這個課程調過來，完成了這個需求，才出來真需求。産品能接受，研發能接受嗎？

所以，要分析老師真實的使用場景，以及場景下的需求分析。

四、優先級排序

接下來才是需要思考的是我們真的需要做這個需求嗎？或者說這需求是真的有必要馬上去實現嗎？

這時，我們可以套用産品的價值公式來分析需求價值：

需求價值=用戶廣度*需求強度*需求頻率

還是以上面的案例為例，排課系統的實際使用用戶是學校的教務老師，大多數學校老師的工作場景主要是圍繞在學校内的，也就是說有經常出差的老師占比并不高。

那做移動端的調課功能是需要經常出差的老師的痛點嗎？

在實際調研中發現平均每周學校的調課記錄有十幾條，說明調課在學校使用中是一個較高頻的場景，作為經常出差在外的老師來說，有這個移動端調課功能的确是能方便不少。

但在當時我們還沒有開發移動端的APP，即使要實現周期也很長，所以這個需求并沒有被采納。

五、服務 = 産品 人

這時可能有人會問，B端的一個客戶可能就養活了大半個公司的人，就因為分析後需求優先級不高就不滿足客戶提的要求了嗎？

通常來說若客戶對公司足夠重要，公司也會盡量滿足客戶的需求，這時産品經理要各種資源更容易一點，即使再小衆的需求也能被提到很高的優先級。

但出現需求不能馬上實現的情況又該怎麼辦呢？

首先，要明确我們提供的是服務，産品隻是個外在形式。雖然現在許多B端的産品主推SaaS（産品即服務），這個叫法實際并不準确，我認為對B端的服務=産品 人。

正所謂“産品不行人來補”，當産品不能馬上很好滿足用戶需求時，就需要通過運營人員的工作代替産品的不足。

如上面的案例，給出的解決方案是若老師在外有調課需要，可以告知公司的排課人員代為調課，并将調課後結果告知給老師。

别忘了我們之前分析的B端用戶特征，他們核心關注的是業務能否順利完成，至于形式如何是次要的。

六、總結

總結一下，當有突如其來的需求時，我們考慮的思路：

首先，是看我們需求來源——他們是誰？是否為産品的直接使用者？并且B端用戶特點是是更關注業務實現效率，他們的行為特征往往更取決于所處職業的集體特征。

其次，需求對應的場景是什麼？是否為用戶真實要解決的問題場景？解決方案是否僅為一種，是否還有其他方案？

最後，通過分析需求價值公式（需求價值=用戶廣度*需求強度*需求頻率）決定需求的優先級。

最後，B端的服務效果往往取決于産品與人（運營人員）共同努力，當無法通過産品及時解決用戶需求時，可以考慮通過人工的方式為用戶解決問題。

作者：大林的小白，gzxdqc，百度數據産品經理

本文由 @大林的小白 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部