作為產品經理，每日面臨洶涌澎湃、撲面而來的需求，做的最頻繁的決定就是Yes, or No,這是一個亙古不變的嚴肅問題。咋辦？

 

答：以用戶或客戶場景驅動為核心，即可做出正確決定。

 

-----跟沒說一樣，因為大部分人還是不知道怎么操作！

 

 

 

 

慣例：從誤區說起

 

在很多企業里，產品的大量需求不是來自客戶或用戶的真實需求，而是來自于：

 

1. 領導指示

 

很多企業的產品，尤其是To B的產品里，經常有“某總”的一句話需求。在某次匯報上，“某總”提出，應該做xxx，于是這句話就被錄進了產品的Backlog里。而且有這樣的不成文慣例：領導的職位越高，他的需求的優先級就越高。更極致的，有的企業的看板上增加了一個加急通道，命名為：領導先走（鑒于保密，不方便貼圖，遺憾！）

 

2. 年度戰略規劃

 

很多企業每年有年度戰略規劃，由于規劃要給高層領導匯報，因此要做得高大上。很多貼近用戶的功能沒法拿得出手，不吸引高層的眼球，也無法爭取到資源來投入這個產品。于是，戰略規劃里的產品是艘航空母艦，而實際你只需要一個小快艇。既然規劃了就得落地一些功能，因此就這樣，一些不貼近用戶的航空母艦式的設備安裝到了一個小快艇上。

 

3.  行業競爭

 

有的企業，用“行業領袖”、“業界第一”這樣的目標牽引所有的產品，導致產品經理的注意力轉移到先進性上，而不是以用戶為中心。這里要區分的是：先進性與滿足甚至超越用戶期望不是一回事。比如，你的產品有先進的人工智能技術，夠先進，但是核心的基礎功能不能黏住用戶，也是白搭。

 

以上三點的根本原因是：企業做產品以領導為中心，而不是以用戶為中心。

 

 4. 對市場上競品的模仿

 

很多產品經理，看到競品有什么，自己就急忙做進去，這是最大的忌諱。你的產品要體現的是你的核心價值主張，而不是體現別人的核心價值主張。大量地模仿競品，說明自己不自信，不知道做什么更好，或者人家的某個功能設計太好了，你無法超越，只能抄襲。

 

5. 產品經理自己的假設

 

產品經理依據自己的經驗和知識，判斷某個需求應該做，這樣無可厚非，但是，需要當心的是，你認為某個需求該做的依據是什么？是有相關的用戶場景經歷？還是自己單方面地以為？很多時候是產品經理單方面“以為”，但是他是那樣地確信，連自己都難以區分那是個需要驗證的假設，還是已經驗證的認知。歷史文章產品經理，不要浪費自己和別人的生命|產品洞見介紹了不驗證假設的后果。

 

 

當然，并不是說以上渠道來的需求一律不該做，而是說：不管從什么渠道來的需求，要帶到用戶或客戶的場景中分析是否成立。決定不做比做更困難，也更重要。

 

我們以用戶為中心，聽取用戶的反饋，但一定不是用戶所有的需求都做。什么都做的產品，就是個大雜燴的四不像，從而會失去競爭力，失去用戶。按照筆者的經驗，用戶提的需求，70%都是不需要做的，但是我們還是要聆聽那100%的反饋，否則無法篩選出來那些該做的30%的需求；如果是To B的客戶已經購買的產品，情況有些不同，即使我們不做也要給出變通的解決方案，或者引導客戶使用現有的解決方案。不論如何處理，哪怕采取外交手段，既不能讓客戶沮喪，也不能隨便就妥協接納，除非我們做的客戶高度定制化的產品。

 

 

不管是什么類型的產品，面對一個需求，我們要仔細分析：用戶或客戶要解決什么問題，這個需求在什么場景下發生，是不是剛需。說起來容易，做起來難。問以下三個問題即可：

 

 

 

1、還原：用戶提的是個需求呢，還是個解決方案？

 

通常，用戶以為自己提的是個需求，其實是他腦子里設計的解決方案。

 

案例

曾經一個用戶跟我提出：

“我希望你們產品里提供郵件通知功能，每天早上8點鐘提醒我有哪些事務代辦”。

這是個典型的解決方案。用戶的真實需求是：

“我希望有個方法提醒我有哪些要做的事情，以便于我安排當天的工作。”

至于是郵件通知，還是其他方式，是早上提醒，還是晚上提醒，幾點合適，這些都屬于解決方案的范疇，需要深度挖掘用戶的場景才能設計合適的解決方案。如果我們就做了個郵件通知，每天早上定時發送郵件，最終很可能成為垃圾郵件。

 

 

因此，千萬不要把用戶的所謂“需求”直接錄到Backlog里，我們一定要做一個需求還原的處理工作。

 

2、場景化：用戶提的需求，具體在什么場景下產生？

 

場景包括：

Who: 哪些角色參與

 

When:什么時候，在什么條件下發生

 

Why: 要解決什么問題

 

How Often: 以什么頻次發生

 

How: 怎么發生

 

通過對場景的刨根問底，你可以甄別出偽需求。

 

案例

筆者曾經做過電子看板工具的產品經理，有用戶跟我的團隊強烈提出：

“我希望將團隊看板的幾個不同視圖切換，每天動態輪播。”

團隊覺得這個注意很好，就放到了Backlog里。我了解后，與用戶做了如下訪談：

我：聽說您想要看板不同視圖的動態輪播功能，請問您想要解決的是什么問題?

用戶: 現在的看板需要手工切換不同的視圖，不能自動播放。我們希望自動播放，不用我手工操作。

我：那么您是希望在什么情況下看自動輪播？

用戶答：每次走過去的時候，看一眼。

我：您每天大概什么時候走過去看？

用戶想了想，答：好像主要是站會的時候。平時偶爾會走過去看。

我：你們站會的時候，主要看哪些東西？

用戶：主要看用戶故事的狀態；然后看每個人名下的任務狀況；最后，看看Backlog里還有哪些重要的需求沒有啟動。一共三個視圖。

我：這三個視圖，現在切換的時候，手工有什么不方便的嗎？

用戶想了想：其實也沒有，一鍵就切換了。

我：那么自動輪播在哪些地方幫助到你們呢？

用戶想了良久：嗯…好像就是平時有輪播,我路過的時候看一眼感覺不錯。

 

 

由以上對話可以看出，用戶提出的需求屬于“如果有這個需求感覺很好”，但實質他使用這個需求的場景頻次很低，也不是剛需。這是個典型的偽需求，而用戶強烈提需求的時候自己卻沒有發覺。

 

3、思考“更”：需求如果做了，與用戶現有的解決方案比有什么優勢？

 

   一個大多數人看不到的事實：在絕大多數情況下，用戶遠沒有他自己說的那么痛，因為他已經在用一些工具或者方法解決他現有的問題。在這樣的情況下，需求其實是一個“更”字：更快、更便宜、更方便等。比如：微信比短信的及時通訊方式更便捷，由于微信的解決方案對短信有極大的超越，導致微信顛覆了短信。

 

如果你將需求做進了產品，卻對用戶的現有解決方案沒有“更”的超越，這個需求就白做了。而且，不是一個稍微“更”，而是極大的“更”。沒有極大的超越，就不要著急做。

 

案例

筆者曾經做過一款企業協同電子工具產品，發布給客戶用了一段時間后，筆者深入客戶調研，發現一些客戶雇傭專門統計度量數據的QA人員, 負責從各種工具里導出數據到Excel中，生成非常豐富的度量數據。我迸發出一個idea:如果把一些核心、通用的度量數據做到我的產品里，這個QA人員就可以解放了。客戶聽了我的提議，非常高興。于是我趕緊讓團隊做。

過一個迭代后上線了，我興奮地跟這幾個客戶通知上線消息，客戶點贊，還要求我們給團隊做培訓，講解在哪里看這些度量數據。但是過了一段時間，根據產品的運營數據，客戶從沒有訪問過度量頁面。我回訪用戶了解原因，客戶說，大家已經習慣了QA發度量數據報告，那個報告很全面，而且QA發到郵箱里，我們只需要看郵件就可以，不用登錄你們的工具看數據。

我汗顏，為啥跟當初訪談你們的時候說的不一樣呢？！結果這個需求白做了，因為沒有超越QA的手工報告。我替用戶著想給他們節省一個QA人力，但是人家其實不差一個員工的成本。

 

說在最后，產品要功能要豐富起來很容易，對需求多說Yes即可，但是產品跟人一樣，要胖起來很容易，要瘦下來很難（親身經歷！）。因為已經有用戶在用，當你想去掉一些肉，就會有用戶不開心。因此，決策的時候要小心，寧可不做，也不要多做！