編輯導讀：從產品新人到產品專家，都逃不過需求調研，不同階段進行需求調研的方法論、關注點、理解能力都有很大差異。本文作者將需求調研分為了4重境界，一起來看看吧。
好像有近4個月沒寫產品類文章了，並不是偷懶，而是這期間經歷了裸辭-休整-求職-入職這一系列的事情，沒有太接觸一線的產品和業務，所以這段時間更多是在思考職業和生活上的一些問題。
而這幾天恰逢入職2個月整，剛好完成了第一個從0到1的迭代、和客戶有了很多頻繁的接觸，於是也藉此積累了很多素材，有關於需求調研的、關於產品架構設計的、也有一些關於資料模型的，那這次先來和大家一起分享下對於需求調研的理解。
對於產品經理而言，需求調研是一件老生常談的事情，也是產品經理最重要的基本功之一。
那是不是成長到5年、10年的產品經理就不需要做需求調研了呢？
當然不是。
首先，需求調研做的好壞，很大程度上決定了一款產品的成敗，其價值無需過多贅述，所以這件事並不只能交給初級或者入門的產品經理來做；
其次，需求調研本身並不是簡單的調查問卷、現場採訪聊天這麼簡單的事情，它是一項由深到淺、由外及裡不斷能夠去提升的能力點。
從產品實習生到工作5年10年的產品專家、產品總監，誰都逃不開要做需求調研，但區別就在不同階段進行需求調研的方法論、關注點、理解能力都有很大差異。
因此，結合筆者過往的經歷和接觸到的一些優秀產品經理身上所展現出來的能力，我把需求調研分為了4重境界，大家可以看看自己當前在哪一層？
01 境界1：全盤傾聽，全盤照做境界一很好理解，就是使用者說啥你就做啥，常見於剛畢業或者剛入門做產品的新人。
例如，使用者說這個列表他需要能夠匯出來，那產品經理就照做、直接給程式設計師提需求加了匯出的功能，反正使用者原話就是這樣，那產品也是在遵循「滿足使用者需求」這樣一個大原則，能有什麼問題呢？
沒錯，原話確實如此，是使用者親口說來的，但這其實還是存在3個問題：
1. 使用者親口說出的需求，並不一定是他的真實需求舉個很簡單的例子，在你生氣的時候，你能保證說出的每句話和真實想法一樣麼？不能。那使用者也是一樣的，也許這個功能對他本身可有可無，但鑑於花了錢付了費，那自己多提點需求和功能豈不是更賺了？所以，出於各種不直接可見的目的和情緒，親口說出來的需求也需要再加以判斷和甄別。
2. 使用者說的到底是需求還是解決方案？先來看一下需求和方案的區別：需求是使用者遇到的問題以及產生的訴求；而方案則是用於滿足這些訴求和解決這些問題的方法。
而使用者往往習慣於說方案而不是訴求。例如，“給我加一個匯出功能”“沒有名字查詢的功能的話，我們就完全沒法用了”等等，這就是典型的解決方案。
一旦你按照使用者所說的方案照做，看起來似乎是滿足了他的需求，但使用者畢竟不是專業的產品經理，他們所提出的方案肯定會受限於業務和經驗，這些方案是否能夠解決當前和長期的問題、是否是最優方案、是否又能夠解決其他使用者的類似問題都是存疑的。
因此，當用戶開口說出需求時，一定要「嗅覺靈敏」，判斷這是方案還是需求。如果使用者說的是方案，那就一定要從方案-訴求-問題這3層刨根問底、找出問題真正的根源。
3. 照做能解決一個人的問題，但不能解決一群人的問題個體是有很大差異性，更不用說組織或企業了。如果使用者說什麼你就做什麼，那A使用者要這個功能，B使用者說不要，那到底該如何取捨和抉擇？使用者的需求經常會出現矛盾和利益衝突，照做是不能解決大部分人的問題的。
總而言之，境界一的優點在於能夠仔細傾聽使用者，而缺點就在於照做，這也是很多剛入行產品在入門路上的必經之路。
02 境界2：選擇性傾聽，帶著方案去調研前面說境界一的優點在於能夠仔細傾聽，肯定有人會想：這很難嗎？傾聽什麼時候也變成一種需要單獨拎出來說的優點了？
講真，很難，因為境界二就是這樣一群選擇性傾聽的產品經理。
當產品經理工作一段時間後，沉澱了一些經驗也解決了一些問題，內心便逐漸不再像以前那樣面對使用者「唯唯諾諾」，開始有了很多自己的想法。
在這樣的情況之下，當你在進行需求調研的時候，其實在問問題之前內心就已經臆想 和規劃出了一套自認為行之有效的解決方案：面對使用者，你所有的問題設計和願意聽到的答案都會被用來證明「自己是對的」這件事，而不是在解決真正的問題。
需求調研變成了你用來給自己方案蒐集和新增證據的方式。
講個自己的真實案例吧。
2017年正值小程式創業風口，當時筆者就想和朋友一起做一款活動報名的小程式。因為自己本身也是活動的組織者和參與者，因此，在內心對這個小程式有了一定雛形之後，便開始找身邊的朋友開始了調研之旅。
在調研過程中，有活動組織者吐槽說：“現在我們活動報名都要在APP裡，每個人報名還要去下載APP，這樣很不好用”。
聽到這裡我喜出望外：誒，小程式不就可以完美解決這個問題嗎？無需下載、還不耗記憶體，這不是很貼合用戶訴求嘛！那隻要我們上線了和原有APP一樣的功能，使用者肯定就會拋棄原來使用的那款APP，轉而使用我們的小程式。
但事實上，最終來使用我們小程式進行活動報名的人遠遠沒有我們最初所設想的那麼多。為什麼呢？就是因為當時陷入了選擇性傾聽、帶著方案去調研的陷阱：
1. 人群選擇有傾向性因為想做小程式，所以我們當時的調研人群核心為使用APP進行管理和報名的人群。這樣一來，小程式確實在下載、記憶體和輕量化上相較APP會有很大優勢。但其實，我們在無意中透過選擇有傾向性的人群來佐證自己想做小程式的這件事。
2. 問題設計側重於自身產品的優點正是看準了小程式在輕量化上的優勢，所以問的問題會很傾向於使用成本、下載註冊等方面利於小程式發揮的問題，而沒有問到一些活動、管理、報名等這類更核心的真實訴求。
因此，這樣帶有傾向性的選擇和傾聽讓我們覺得小程式能夠很好的解決使用者當前的問題，但我們其實忽略了一大批透過群內手動發帖/跟帖報名的俱樂部群體、忽略了產品替換成本的問題、忽略了小程式對微信版本有要求、甚至很多人都不知道小程式入口等這些基礎性的問題，最後也導致了整款產品的Roadmap制定過於樂觀、而現實卻和預想千差萬別。
整體而言，境界1和2都是自己親身經歷過的階段，但現在看來，這些都不是需求調研的能力層問題，而取決於一個人對人性、對問題、對社會的認知到底有多深刻。
03 境界三：認真傾聽，找準根本問題在逐漸踩完境界1和2的坑之後，產品經理就會來到境界3：認真傾聽、找準根本問題。
解決問題的前提是先能夠找準根本問題，而問題都是被一層又一層的聲音和表象所包圍的，一不小心就會掉入境界1和2的陷阱中。
境界1中，解決問題的產品經理是一種唯唯諾諾、任人擺佈的姿態；境界2中，解決問題的產品經理是一種高高在上、自以為是的姿態。而境界3所要求的姿態是一種不評判、平等對話的姿態。
在這層境界中，產品經理能夠拋開自己的預設和猜想，全心做好一個傾聽者的角色，並且有自己的調研方法論（使用者故事、使用者畫像/分群等），能夠清晰地從「方案-訴求-問題」或是「問題-訴求」去剖析使用者。
不知道大家是否瞭解心理諮詢的過程，在一場心理諮詢中，心理諮詢師會透過傾聽和引導，幫助使用者逐漸卸下防備和顧慮、吐露出真實的心聲，當然使用者調研自然是沒有這麼多時間和精力去關注到每一個使用者的，但這種平等對話的思路和引導方法值得借鑑。
當然，需求調研有非常多的方法論，限於篇幅這裡就不展開講了。但是呢，在境界3需要大家重點關注的是此時面對使用者的態度是不高不低、不卑不亢，這裡已經和境界1和2有了很大的不同。
04 境界四：調研組織，尋找各方利益平衡點前面3重境界都在強調單一的人群，但是隨著toB和toG行業的盛行，越來越多的產品經理需要從單一的人群轉為對龐大的企業和組織進行需求調研。
不同於單一的人群，複雜的組織若要良好的運轉起來，其各部門和鏈條之間勢必存在著非常多互相制衡和約束的關係，而這些是是很難透過調研這種擺在明面上的方式問出來的。
因此，境界4進行需求調研的難度和量級將遠遠大於前面3層。
在這一層的關鍵點除了選擇好關鍵人進行對應深入訪談之外，還需要意識到2點：
1. 使用者並不是表面上看到的職業角色那麼簡單他們背後其實是各重身份的交疊：業務負責人、某專案的關鍵把控人、關鍵大領導最相信的得力員工等等，如果僅僅停留在一個單一的職業角色，那麼很可能就會踩坑。
2. 需要識別出各個部門之間不同的利害關係這些隱藏在需求背後的利益點可能是由於流程的上下游、績效考核方式、和關鍵領導關係親疏等造成的，這類企業中人情世故的問題會極大程度上影響我們的產品真正推進和落地的情況。
所以，能夠真正達到第四層需求調研境界是一件很難的事情，因為你面對的不是一個簡單的人群，而是複雜的組織和組織關係，這需要有極強的洞察力和對人情世故的理解能力。
假如你只聽了A部門的訴求並給予了滿足，但有可能會損害同一公司內B部門的訴求，那麼，這個方案就很難在一個公司推行下去；再比如，你按照客戶公司Leader的想法推進了一項方案，但是關鍵執行部門卻不怎麼配合、總是敷衍推行，那麼，這也許就可能和該部門的績效考核方式有一定關係。
所以，在境界4的組織需求調研中，除了需要像境界3中一樣找準每個人的訴求之外，還要梳理出每個小組織、每個個人之間的利益關係圖，最終真正能夠解決問題的一定是能夠相對很好平衡各方利益點的方案。
最後，在寫這篇文章的時候，我也想到了喬布斯——一位聲稱自己從來不做使用者調研的產品傳奇，他曾經說過這樣一句話：消費者並不知道自己需要什麼，除非你把產品展示給他們看。
但是呢，大部分人可能都會像俞軍在《俞軍產品方法論》裡說的B類產品經理一樣——缺乏天分、但有很強的學習和迭代能力。如果你不是喬布斯這樣的天賦型選手，那就還是老老實實做好調研吧，日積月累的調研也能夠幫助我們積累出非常好的嗅覺能力。
以上，就是筆者對於需求調研4重境界的理解，大家可以對比看看自己當前在哪一層、未來需要提升和進階的方向在哪裡。
作者：冰冰醬；公眾號：產品冰冰醬
本文由 @冰冰醬 原創釋出於人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議。