脫離用戶，這是做產品的大忌，這個理論幾乎每個產品經理都知道，但實際真正做到不脫離用戶的產品經理并不多，至少在火山能夠接觸到的范圍內的產品經理，就大面積地存在這樣的問題。捫心自問，在脫離用戶這條彎路上，火山也留下過不少堅實的腳印。

我之前所負責的是一款toB類的業務型產品，需求的主要渠道就來源于銷售與客服，產品設計基本是圍繞著業務需求展開的，因此，業務部門在我們公司具有非常強的話語權。而與此同時，我們產品經理接觸實際用戶的機會非常少，脫離用戶的情況基本是常態，接下來跟大家分享一個真實的產品案例。

之前，我在《為什么說完美主義的產品理念背后潛藏著一個天坑》一文中分享過一個“訂單攔截”的項目案例，這個案例主要是針對的是機票訂單，大意是講我們的客戶希望能夠在前臺用戶下單之后將機票訂單進行攔截，人工決定是否通過我們系統自動出票。但對于最終通過我們系統自動出票的訂單而言，訂單中附帶的保險也將從我們系統自動出保。

在這個功能上線大概2個月之后，我們一個新來不久的銷售同事又回來給我提了另外一個“姊妹需求”：

我們有一個大客戶表示訂單攔截的功能挺實用的，因此，對于機票訂單中附帶的航意險、航延險等產品，他們也希望可以做一個“保單攔截”的功能，因為保險產品他們也有自己的出保渠道。

聽到銷售同事說自己之前做的產品得到了客戶的認可，不僅之前做訂單攔截功能時被客戶無情否定的失落感瞬間蕩然無存，甚至還有一種幸福感油然而生。那么，在我接到這個需求之后，我是怎么做的呢？

假設你是接到這個需求的產品經理，你打算如何實現這個需求？

思考1分鐘，計時開始……

由于訂單攔截的先例已經得到了客戶的認可，而“保單攔截”是一個同類型的需求。因此，被幸福感“沖昏頭腦”的我幾乎沒有考慮這個需求的合理性，幾乎立馬就投入到了這個項目的設計當中……

首先，攔截開關是無法共用的，因為訂單攔截之后，本身保單就是需要人工出的，因此需要增加一個保單攔截的開關。

其次，需要考慮可能的攔截場景：機票訂單自動出，但是附帶的保險訂單做攔截；機票訂單手工出了之后，保單還有可能需要從我們平臺自動出，但無論如何下單的流程需要調整。

再次，需要考慮扣款流程的一些調整：如果機票自動出了，但是保單不自動出，那么扣款怎么扣？相應的，發生退票之后，退款了里流程怎么走，自動還是手工？

然后，一些可能的特殊場景：下了機票訂單，機票出票了，但是保單并未及時手工出保，需要如何處理？整張訂單的狀態算正常還是異常？

……

在經過一個星期左右的梳理之后，我基本把各類場景下的業務邏輯都梳理清楚了。當然，這次我沒再犯一蹴而就的低級錯誤，我拿著我梳理好的流程圖，找到了開發經理評估技術可行性方案，開發經理又給我補充了一些我未考慮到的場景，具體不再細說，總的來說最后，最后大概需要一個多月的工期能夠開發完成的方案，這還不包括測試的時間。

工程量不算小，但總體而言，方案可行性是沒有問題的，我又把大致的方案銷售和客服的同事都做了講解，他們基本也沒有提出什么異議。但是我總覺得哪里不太對勁，于是，我又讓銷售同事把客戶的聯系方式給了我，我把我的方案巴拉巴拉又給客戶說了一遍，而客戶的態度似乎跟銷售和客服的同事沒什么太大的差異。

此時，但就這個功能而言，我的方案已經得到了內部、外部幾乎所有人的認可，理論上說，我的產品方案在大方向上應該是沒有大問題了。但是，就在我準備掛掉客戶電話，開始進行詳細方案設計的時候，我不經意間的一個提問卻在一瞬間改變了整個局勢，最終讓我把我的整個方案全盤推翻。

想一想，這會是一個什么樣的問題？

思考1分鐘，計時開始……

“x總，我能了解下你為什么想要做這樣的保單攔截的功能嗎？”我問道。

“因為你們的保險成本需要5元錢，我們自己的出保渠道只需要4元錢左右，走你們的渠道不合算?！笨蛻粢埠翢o保留地給說了他們的想法。

我這才意識到，其實客戶需要的 “保單攔截”功能，這只是一個表象需求，根本需求實際上還是成本考量。而實際上，我們渠道的保單成本是可以降到3.5元左右的，也就是說可以比客戶自身渠道的成本還要更低。而出現5和3.5元的保險成本的信息失真，可能是由于新來的銷售同事對于業務不熟導致的。后來，經過跟客戶的再次溝通，我們把保險成本的信息給客戶做了一次重新的傳遞，客戶當即表示：“那這樣的話，就用你們的保險好了，我們還不用人工去盯著，人工成本也省下來了，還省心?！?/p>

最終，我們在產品上再沒有投入1分錢的人力物力，通過改變客戶的想法的方式就滿足了客戶的需求，與此同時，還幫助客戶降低了采購成本，實現了雙贏。

案例分享完畢，發生在火山身上的這個真實的項目案例是否帶給你某些啟發？

思考1分鐘，計時開始……

火山復盤

在這個案例中，我想當然的認為“保單攔截”和“訂單攔截”是同樣合理的需求，犯了一個很明顯的錯誤——缺少需求調研，再將這個錯誤升華一下就是——脫離用戶，而這個錯誤直接導致的影響就是，它讓我對偽需求的分辨能力直線下降！

作為一家toB類型的互聯網企業，火山所在的創業公司跟大多數面向B端的互聯網公司一樣，銷售在公司的話語權非常強，尤其是早期的時候，我們大部分的需求基本上都是被銷售牽著鼻子走。后來隨著業務量上升，主要的需求來源從銷售轉移到了運營，于是我們的產品思路又圍繞著內部運營的實際業務展開。產品經理脫離用戶基本是一種常態。有時候哪怕明知道他們提的需求不合理，產品經理想跟他們爭論一下甚至都沒有底氣，因為我們接觸用戶真的沒有他們多，有時候爭論急眼的時候，他們甩出來一句“你了解客戶還是我了解客戶”可以直接把產品經理“噎死”。

但無論是銷售還是運營，實際上都不是我們產品的最終用戶，終端用戶的實際需求經他們轉述之后勢必產生信息損耗或失真?；诙值挠脩粜枨笞龀鰜淼漠a品，勢必很難把握用戶的核心痛點和真正訴求，最終導致我們做出的產品如同隔靴搔癢，根本無法為用戶創造真正的價值。脫離用戶的產品經理，勢必難以有效地掌握產品的走向，無論最終是被銷售還是被運營所主導，都只會停留在具體的功能需求落地執行層面，頭痛醫頭腳痛醫腳，無法挖掘到用戶的真正需求。按照如此的路數做產品，也許我們拼盡全力，最終可以給我們的用戶提供無數更快的馬，卻永遠無法給他們提供一輛更快更舒適的車。

因此，無論toB還是toC，要想做出真正好的產品，脫離用戶都是產品經理的大忌！然而，畫原型、做方案、寫PRD，與老板溝通、與程序員溝通、與設計師溝通、與業務部門溝通、各類會議、跟蹤項目進度……產品經理日常的工作如此之細碎繁雜，每天泡在用戶當中顯然也是不現實的。

那么，如何保證產品經理的日常工作正常推進的同時又不脫離用戶呢？在最后，火山把自己總結的幾個小建議分享給大家，希望可以對大家有所幫助：

1. 做任何需求，跟需求方做需求調研是最基本的產品工作，是絕對不能省的；
2. 如果這個需求來自于明確的終端用戶，則在內部需求調研之后需要向終端用戶做直接的需求調研。跟終端用戶去聊，了解他們在想什么，他們有什么痛點，他們最想解決的問題是什么，這也是不能省的，不能想當然地認為業務、銷售同事做過需求調研了，就可以不再跟用戶去做調研了；
3. 在有了大致的產品方案之后，再跟終端用戶聊一聊，看看方案是否有方向性的問題，及時發現、修正方向性的問題；
4. 在原型文檔出來之后，如果條件允許的話再給客戶展示一下原型方案，在提交開發之前盡可能地發現并修正一些細節性問題。

后記

產品是做給用戶用的，但做產品的產品經理卻不了解用戶，看似很不可思議，可這樣的情況卻也并不鮮見，哪怕是從業3年以上的產品經理也不例外。將一個需求轉化為具體的產品落地方案，做到無懈可擊也不是沒有可能的，但是產品經理往往會忽視的一個問題就是，這個需求到底要不要做？而想清楚這個問題往往比前者更加重要和意義深遠，產品經理如何才能對這個問題做出更加明智的判斷？這個能力是多方面因素決定的，但需要時刻銘記的一點就是——永遠不能脫離用戶。

本文由 @ 火山 原創發布于人人都是產品經理。未經許可，禁止轉載。