如何找到使用者真正的需求

之前的文章有提過，有些不合格的產品經理會把使用者說的直接當作需求，比如產品需要做一個數據展示平臺給業務用，業務說需要看幾張資料表，因為現在還要去拉資料庫，太麻煩了，你就給我展示出來吧。於是這個不合格的產品經理便會把業務說的這幾個資料表展示出來。更有甚者，有些產品會說反正有地方可以看，不用給業務做了。不要覺得詫異，在沒遇見之前，我也是不相信有這樣的“產品經理”。

那合格的產品經理會怎麼處理呢？第一肯定是想弄清楚業務為什麼會關注這些資料，或許他們關注這些資料是為了更具體的目的，比如查詢問題。我現在規劃這個需求就是這樣，大概舉例描述一下，這些業務是因為發現某些正常接入的酒店無法正常在外網展示售賣或者產量很低，因為他們想通過檢視對接過程中的一系列資料查一下到底問題在哪。那其實作為產品，我需要做的是幫助他們找到那些無法正常在外網展示售賣或者產量很低的酒店，並且直接告知他們原因以及修復的辦法。再深一層，我發現一般是供應商讓他們幫忙拉資料，然後發現問題後讓業務幫忙查，最後問到產品或者開發，然後原路把資訊反饋給供應商。那這樣的話，我就應該把這塊需求面向供應商去做。

最終確認把這塊需求對外去做，首先當然是去調研供應商的需求，瞭解清楚供應商到底在乎哪些資料，為什麼，然後再去定位到真正的需求。這裡額外提一點，就算是供應商再關注，還是需要公司評估這部分資料是否可以直接對外，資訊保安要做好（雖然無形會增加很多流程和時間）。那麼問題來了，怎麼去了解供應商的需求呢，因為產品並不是直接對供應商的，業務才是直接對供應商的。我呢，開始天真的以為，直接調研業務，問清楚他們目前為止，供應商一般會讓他們提供哪些資料，為什麼提供這些資料。後來真正調研的時候才發現，業務說的好像都是他們關心的需求。比如某些特殊操作的原因和明細，而且他們會把這些需求放在優先順序極高的地位。開始覺得也對，供應商應該也很關心為什麼被特殊處理了。不過為了保證需求真正來源供應商，後來我還是自己做了份調查問卷，首先從業務那邊蒐集到了很多需求，最後整理出來後拜託各個業務發給供應商自己去選擇他們認為的最緊急的三個需求，最後發現業務覺得優先順序最高的那個並不是供應商選擇的排名第一個的需求。原因其實很簡單，因為那是特殊操作，所以只是少部分的供應商才存在，只是因為存在這種問題的供應商總是找業務，所以給他們的感覺就是這個需求很多也很急。

所以個人認為需求調研一定要直接找到產品的使用者，一層都不能隔。好，現在一層也不隔了，你還是會發現使用者的思維一般只會單線發散。比如產品如果問使用者平時在操作過程中有沒有什麼地方覺得麻煩的地方，比如重複人工操作的或者看很多地方才能解決一個問題的？使用者可能會說沒有，特別是一直在用的，只要不出錯，習慣後就覺得很順手了。那這種時候如果產品經理對業務瞭解，那可以舉例說：你這個資料要去這個模組檢視，可是跟這個資料關聯的另外一個數據要去另一個模組檢視，如果我做在同一個頁面是不是就可以讓你輕鬆點。稍微靈光點的使用者，這個時候可能就會說了，其實我還會在那個模組檢視那個資料，應該也可以做到一起。那瞭解到這個程度，其實就可以確認需求是有的，那就說明價值是存在的，你可以繼續挖了。繼續挖就是前面提到的一定弄清楚為什麼要看這些資料，最終目的是什麼，確認真實需求。如果產品經理對業務一點都不瞭解，那還是先了解業務，不然問題都提不出來。

所以總結下來，如何找到使用者真正的需求：

1，以縮短需求路徑，提高效率為目的