產品經理不要做需求的傳聲筒，而是要做需求的翻譯機。
不做需求的傳聲筒
一直以來C端的產品遵循以用戶為核心，B端的產品也是以客戶為核心，那什麼才是以用戶為核心呢，難道就是用戶說什麼，我們就要做什麼嗎？
福特汽車的故事告訴我們，用戶需要的是一個更快的馬，但是最後提供的是一輛汽車。如果我們根據用戶說的去做，那就沒有福特汽車的出現。
用戶即便知道自己想要什麼，也容易受到認知的約束，而給出侷限的解決方案。在那個沒有汽車都是馬車的時代，用戶的需求是更快的交通工具，而我們需要做的是通過用戶的“需求”找到真正的解決方案。
所以以用戶或者客戶為中心是需要產品經理站在用戶角度，去思考用戶的痛點是什麼，然後通過產品來解決的這個痛點。而不是當做需求的傳聲筒，把用戶的需求傳遞給研發而已。把用戶需求翻譯為產品需求，這就是產品經理需要做的事情。
需求傳聲筒的危害
如果我們一味的聽從用戶的需求，沒有弄清楚用戶真正的意圖，結果做出來的功能客戶又不要，白白浪費了公司的成本和資源，尤其對於小公司這樣的損失是非常嚴重的。
在早期流行手機發短信的時候，座機的使用比手機普遍，那是有用戶提出，手機不是人人都有。但是家裡一般都是有座機，為什麼家裡的座機不能提供一個發短信的功能呢？
後面做座機的公司，讓研發團隊加班加點，做出一個可以發短信的電話座機。滿心歡喜的向客戶推薦著新功能，賣出去了很多電話機。
後面回訪客戶發現，大部分的消費者壓根就沒用過這個功能，這下他們疑惑了：這麼好的功能，為啥沒人用呢？
其中，有位年輕的客戶反饋說：我最近正在談對象，有一次我用家裡的座機給對象發了一條短信，沒想到，家裡的七大姑八大姨回來後一翻座機，都能看到我的短信記錄，然後，我就不用這個功能了。
這家公司才恍然大悟：天啊！我忽略了短信是一個私密的功能，誰也不想把自己的秘密曝光在大眾面前，然後趕緊回公司緊急撤銷了這個功能。
如何做需求的翻譯機
什麼是用戶需求與產品需求？
用戶需求就是用戶從自身角度，使用某一產品或服務過程中遇到的問題從自己的經驗和想法中提出的需求。
產品需求是挖掘、提煉、分析用戶真實需求，從而得出的具有普遍價值，並且符合產品定位的解決方案。解決方案可以理解為一個產品，一個功能或服務。
那用戶需求與產品需求有什麼關係呢？在蘇傑老師的博客中介紹了一種分析模型：Y模型。
把用戶需求翻譯為產品需求的過程就是需求分析，通過原始需求，我們挖掘用戶需求、分析需求，然後輸出為產品解決方案。
無論是自己的創新想法，還是市場調研，或者說來自其他方面的需求，最終彙集到產品經理手裡，我們需要從5個方面進行需求梳理：誰提出這個需求、需求背後的動機、用戶故事（用戶-場景-路徑）、產品定位、可行性和實現成本等多重因素下，綜合判斷出最有”性價比“的需求。
決策哪些要做、為什麼要做、怎麼做，同時也要給出哪些不能做、哪些暫緩做、為什麼不能或暫緩？
1. 誰提出的需求
首先需要了解這個需求是誰提出的。因為任何一個產品都是目標用戶的，需要根據產品服務的對象，確定客戶的等級，哪些是核心用戶，哪些是邊緣用戶。我們最終服務的核心用戶是誰，我們需要優先考慮這部分人的需求，而一些邊緣人員提出的需求可能不一定會相應。
在面對to B或者to G產品中，掏錢買產品的用戶成為客戶，而真正使用產品的用戶我們稱為最終用戶。客戶與最終用戶可能是同一個人也可能不是同一個人。例如釘釘，購買釘釘的是公司領導，而主要使用釘釘的是企業的員工。
我們需要分析出這個需求滿足的用戶是不是這個產品的目標用戶。
比如：釘釘軟件中，用戶反饋很不喜歡群裡面已讀和未讀的消息狀態，但是這個功能釘釘依然保留，甚至是他的核心亮點。因為這個需求滿足的是領導層的需求，我們需要優先考慮領導層，所以就犧牲了員工的一些利益。
2. 需求的動機
用戶從來只是表達他想要的，但這不一定是解決方案。知道誰提出的需求之後，我們需要多問幾個why，挖掘出用戶為什麼要提出這個需求，他是希望解決什麼問題。只有瞭解需求真正的問題，我們才能提供合適的解決方案。
比如一個屌絲經常吃外賣的屌絲，突然想自己做個蛋炒飯，可是他不知道應該是先放蛋還是先放飯，於是就在百度貼吧發佈一個帖子：蛋炒蛋是先放蛋，還是先放飯。很多人回帖：先放蛋。最後蛋炒飯沒吃成，鍋還糊掉了。他仰天大喊：你們都是騙子，為什麼不告訴我要先放油。
這個例子告訴我們，其實他真正的問題不是先放蛋還是先放飯，而是他不會做蛋炒飯。
3. 用戶故事
既然已經知道需求提出者會自覺/不自覺地對需求進行加工，那麼當我們拿到這些構建於不同需求方自身經驗之上的“半成品解決方案”時，務必不能直接開始考慮“怎麼做”。而搞明白“為什麼做”，在不明確需求的前提下談方案，根本就是耍流氓。
我們可以從用戶、場景、路徑3個方面，梳理的用戶故事。
- 用戶：瞭解這個需求涉及到哪些人員，對同一個功能，可能存在多個不同的角色的用戶，他們的需求可能不一致。
- 場景：分析這個需求是在什麼場景下存在，窮盡所有可能的使用場景。
- 路徑：在完成功能的梳理，那便是利用流程圖將功能進行串聯，梳理每個角色需要通過哪些環境才能完成這個任務。
經過需求確認之後，梳理出這需求故事：「什麼樣的用戶」在「什麼場景下」，遇到了「什麼樣的問題」，使用「什麼路徑」來解決。
例如下圖中是信息查詢平臺中用戶反饋的需求：
在這個用戶需求中，涉及到了2個目標用戶：申請查詢人員和運營商反饋信息人員。
場景：申請查詢人員，需要通過發起查詢申請單，然後運營商跟進申請單的查詢內容，反饋查詢結果，但是目前查詢專員發現運營商有部分反饋錯誤的情況。
路徑：考慮到目前這2個用戶之間，運營商是配合查詢專員的工作，這個任務主要是查詢專員來推動，所以需要由查詢專員在原來的申請單上門，重新發起查詢任務，以便運營商引起重視，重新反饋。
經過分析之後的需求故事：【查詢人員】在【申請查詢任務之後，運營商反饋結果】，會偶爾出現【運營商反饋的文件與查詢內容不一致的情況】，需要讓【查詢人員在原來的申請查詢任務上面，繼續發起查詢請求】。
4. 產品定位
我們需要考慮這個需求，是不是符合產品的定位與產品的邊界，是不是在這個產品的服務範圍內。
比如：考試系統中，我們依賴的是第三方的一個題庫系統，通過從題庫系統中抽題，來組裝一套試卷，給用戶進行考試。那麼組裝試卷的用戶希望我們提供一個在線修改試題的功能，因為他們發現有一些試題存在問題，希望可以修改。
從這個考試系統的產品定位，這裡負責的是組裝試卷，進行考試。試題的問題，需要反饋到第三方的題庫系統中，進行修改。
那麼這個需求就是不符合產品定位和產品邊界的，考慮到問題的出現，考試系統不會提供在線修改錯誤試題的功能，但是可以提供一個反饋試題問題的信息入口。
5. 可行性和實現成本
雖然現在產品經理一般不懂技術，但是在需求分析過程中，我們還需要考慮需求的可行性，已經實現這個需求的成本。
如果一個非常低頻的需求，我們克服了技術難度，但是最後用戶很少使用這個功能，那麼就這是資源和人力的浪費。
比如：客戶提出需要系統上傳的文件支持在線預覽和在線編輯的功能。首先用戶上傳的文件類型非常的多，比如word、txt、excel等。客戶如果發現文件有問題可以刪除錯誤文件，重新上傳，並不是一個影響使用。
目前如果自己去開發在線編輯的功能成本肯定很多，如果調用第三方也是需要增加一筆費用，而客戶目前並不想承擔這筆費用。那這樣的情況下，這個需求目前就是滿足不了。
總結
大多數用戶提的需求只是「自以為是」的解決方案，而不是產品需求。用戶在使用產品過程中，會遇到令用戶「體驗不爽」的點，也就是「痛點」，此時用戶會從自己的角度出發，基於自己的經驗提出一個解決方案，這就是「用戶需求」。
實際上，用戶提出的解決方案往往能夠簡單地解決該用戶遇到的問題，但其實這是一個個性化的解決方案，往往不具有普遍性。
用戶遇到的問題具有普通型，但是這個解決方案不具有普遍性，產品經理的工作就是找到這個問題所在，找到一個能夠滿足絕大多數用戶的解決方案，這個解決方案才是「產品需求」。
題圖來自Unsplash，基於CC0協議。
閱讀更多 人人都是產品經理 的文章
