【PM｜理解需求】如何挖掘使用者與產品的需求？淺談使用者開發的眉角
快速瞭解使用者研究中，重要的心態與立即可用的技巧
在上一篇的產品管理：理解產品經理在做什麼中，提到產品經理的核心概念在於「以產品滿足利害關係人的需求」。同時也延伸一個概念，產品經理和專案經理不可能都只做產品或專案管理，而是偏重的比重不同。
開發產品的過程，也通常會經歷之前提到的七個步驟，只是會根據實際的狀況調整每個步驟的多寡。
Table of Content 本文大綱
- 使用者需求之於產品開發
- 如何獲得使用者需求
- 如何做好使用者開發
一、使用者需求之於產品開發
在上課的過程中，我對於講師提到的這句話印象深刻。
Product Manager 最重要的角色，便是辨認何者才是真正重要的需求；而非提供大量的點子。
過去我常認為，PM 應該是團隊裡最懂產品或專案的人，也因此應該要能夠給予產品設計上的意見；但在過去 Garena 和管顧公司的經驗中，逐漸發現 PM 之所不可或缺，不是因為他需要最會設計產品，而是需要找出真正需要滿足的需求，並給大家一個可以發揮的舞台。
在我的訪談與上一篇提到產品界常見的 3 種 PM 中，每一種角色所對到的終端使用者（亦即最終使用產品的人）都不同。也因此在挖掘使用者需求的過程中，找尋哪一些人是利害關係人，哪一些人是終端使用者，是 PM 最重要、也是首要的任務。
實際訪談經驗
舉我訪談一些 PM 的經驗，對於 2B 的產品來說，購買的人卻是企業；但真正的使用者卻是員工。因此對於利害關係人來說，需要同時瞭解員工的需求，以及提出企業在乎該產品的實際效益，是 2B 的 PM 需要負責的任務。
在設計產品時，要注意產品使用者和願意付費的利害關係人是否相同。
二、如何獲得使用者需求
I. 使用者需求：EMUC Model
那麼，究竟該如何獲得使用者的需求呢？這是個沒有唯一解的問題。可以以簡單的框架 EMUC，來盤點是否有疏漏的使用者需求管道。
- Employee｜各個員工，甚至是創業者本身
- Metrics｜通常會以指標作為警訊，進一步挖掘使用者需求
- Users｜從員工、指標發現問題後，通常會開始進行使用者研究
- Customer & Client｜真正會為該產品付錢的人，例如企業或付費玩家等
這裡也需要特別區分 User 和 Customer 的差異。User 是使用產品的人，通常需求非常明確；Customer 則是真正為產品付錢的人，有時付錢的人並不真的會用產品（例如企業），因此需求較模糊。
II. 獲得使用者需求的方法
在獲得使用者需求的方式，這裡可以列出常見的幾個方法，並分享個別的優劣勢，可根據個別的需求使用。
但就算擁有這些管道，仍然要注意「樣本偏誤」與「倖存者偏誤」等問題。有時候更願意回饋的使用者，也可能因此擁有某些特質，亦或是願意接受訪談的使用者，可能恰好都符合某種特性。最後卻將這些偏頗的結果，當作是全體使用者的意見。
也因為在挖掘使用者的需求，最重要的技能仍然是訪談，因此也把我的訪談流程與技巧的文張貼在下方。
A. 客服 & 官方管道回饋：
這是最常見、最容易蒐集到使用者回饋的管道；但問題也最明顯。下面這句話，可以很好地表達這個管道的問題：
「如果當初我去問顧客到底想要什麼，他們會回答說要一匹跑得更快的馬。」 — 亨利・福特
因為使用者在使用產品時，通常不會知道真正的問題是什麼。也因此就算蒐集到 A、B、C 等敲碗次數眾多的功能，仍然需要瞭解使用者真正面對到的問題是什麼？如何才能真地解決問題？
舉個我過去在創業時開發產品的例子，當時使用者在使用我們諮詢服務後的回饋，說了如果真的有一份完整的報告會更好；但當我進一步訪談使用者的感受，得到的反饋卻是：「如果諮詢完後卻什麼都沒有拿到，感覺就很浪費錢」。
因此對於消費者來說，當時真正的需求可能不僅僅是諮詢時提出的解方，也包括了是否有具體獲得的安心感，這可能才是使用者真正的需求，而非一份包山包海的諮詢手冊。
B. 用戶問卷調查：
這也是常用的管道，成本會比上述的使用者主動回饋還要來的更多，包括設計問卷、投放與回收分析等。然而更嚴重的問題在於，問卷很有可能會有偏誤。
舉個實際的例子，在訪談時聽到說如果把 NPS 的題目放在越前面，分數就會因此越高。這也說明問卷的結果很有可能會有偏誤；但真正重要的是你想要獲得什麼，以及你打算怎麼驗證這個結果？
C.數據探索分析：
這在資料科學的領域中，有個專有名詞稱為探索數據分析（Exploratory Data Analysis）。藉由數據的結構、分配與極端值等，來尋找出資料中隱藏的洞見，鼎鼎大名的行銷故事「尿布與啤酒」便是其一。
但仍然要記得，數據只能提供現象，因果只有「使用者」才有辦法回答。當然，這裡談的是獲得使用者的需求，因此實驗的 A/B Testing 等方式就不算在這個範圍內。
E. 用戶需求訪談：
常見的用戶訪談方式分成兩種，分別是對於個別使用者訪談的 Interview；另一種則是以群體為主的焦點訪談團體（Focus Grouping Discussion）。其優點在於能夠獲得更加深入的洞見與質性結果；缺點則是若回答涉及隱私可能會讓使用者隱藏結果，以及很容易因問題不當而得到錯誤的結果。
舉個實際的例子，過去在 Garena 訪談時，很習慣會問使用者「你們覺得遊戲體驗哪裡好、哪裡不好？」若有不好的地方，就會追問「你覺得不好玩的原因是什麼？」
這樣的問題在理性上沒有問題，但有趣的是一開始我在焦點訪談團體獲得的主要原因是手感不佳，在沒隔多久後的個人訪談，我卻獲得原因是匹配系統的不友善。
明明都是同一位玩家，在僅僅一兩週後卻獲得了不同的質化結果。除此之外，在《只有一半的真相》這本書也提到，曾有科學家嘗試偷改中立選民自己寫的議題偏好問卷，竟讓 70% 的選民悄悄為改變的立場背書。
因此在訪談時，必須要注意訪談到的需求並不是聖旨，只是後續實驗的敲門磚。
E. 老闆 & 利害關係人的需求
這是常見、但卻非常棘手的需求來源。因為老闆或企業客戶，有時並非產品真正的使用者；卻決定了是否購買產品的開發大權。因此常聽見的「隕石開發法」便是客戶或老闆突然來了一句：「不然來開發這個好了。」下面的員工便需要想辦法完成該功能，無論是否真的有使用者需要它。
因此，在接收到這樣的需求來源時，切記需要從老闆或客戶的角度去思考，他們真正在意的是什麼，並將解決方案導向至真正的問題。但這個領域筆者的經驗也仍然不夠，因此僅能給予初步的觀點。
三、如何做好使用者開發
光是這一章，都可以開一個學門了，因此本章會專注在做好使用者開發的心態，以及一些立即可用的技巧。之後也會在下一篇，將過去訪談的經驗，以及過去設計整套使用者研究的問卷經驗整理給讀者。
最核心的問題：Who, What, and Why?
在做使用者開發（Customer Development）中，最重要的莫過於瞭解我們要幫誰解決什麼問題。因此在設計思考（Design Thinking）中也有了觀點 POV（Point of View）：
對____來說，需要____解決方案，因為_____很重要
分別對應的就是 Who、What 和 Why。其中在使用者開發與訪談的過程中，回答「Why」是整個過程中最重要的事。豐田生產方式（TPS，Toyota Production System）的創始人大野耐一給員工的第一課便是：
連問五個「為什麼」？
透過連續問自己五個為什麼，讓自己跳脫原本表層的現象，進一步深挖隱藏在表象背後的需求，而滿足真正的需求，才能讓使用者感到驚艷。
POV 檢驗法
在設計思考的領域中，也提供了一個簡單的方式來檢驗因果關係是否強烈。只要我們把前面提到 POV 的「解決方案」和「原因」對調，如果發現句子仍然通順，就代表我們其實沒有發現真正的原因。
驗證假說
接著進一步思考，當我們執行解決方案後：
- 使用者會產生什麼變化？
- 這個變化的假設有哪一些？
- 哪一些假設最為危險？我們需要測試哪些假設？
這些問題都是在發現 POV 之後，需要進一步在產品開發時驗證的假設。
這裡也放上兩堂網路上蠻多人推薦的課程；筆者礙於時間尚未開始上課，如果有有興趣的讀者可以參考看看。
進一步思考法：發生之後，還會發生什麼？
當我們挖掘出關鍵的因素之後，需要思考的是接下來的事件：
當我們「執行」這項行動後，未來還會發生什麼。
為什麼需要思考這個問題呢？因為當我們執行之後，很有可能在一開始符合我們的預期，但在使用者習慣之後，就失去我們原本期待的成果了。
舉個實際的例子，現在應該很少人會在 GAP 沒有打折的時候，去買他們的產品了。當業者發現打折能夠讓刺激消費者增加購買慾望後，便長時間地使用促銷戰術。
然而消費者會漸漸發現到，既然 GAP 這麼常打折，那我便沒有必要一定要在平常的時候購買，導致原本用於刺激銷售的折價戰術，變成了沒有折價消費者便不去購買的反效果。
Summary: Customer Development
在過去上大學與工作時，總覺得使用者研究就是發發問卷，以及和使用者聊聊。直到真的開始以設計思考、Persona 和輔以心理學進行研究後，發現自己把使用者研究看的太過簡單，無論是訪談時的技巧、問卷的設計、使用者的心理偏誤等，都會影響研究的成效。
直到開始工作後，發現問卷設計有偏誤，連直接訪談都會有偏誤。這也開始讓我意識到，心理學對於使用者體驗與研究究竟有多大的影響。因此想提供給讀者最後一個 Key Take away 是：
很多理所當然與經驗，不代表它就是正確的。
以上面這段小結，與各位讀者共勉之。若文中有任何筆誤或你覺得有趣想要討論的內容，都歡迎直接留言或 mail 到我的信箱喔！
**【希望用你的掌聲來投票與支持】**
拍 5~10 下：簽個到，表示支持（感謝你的鼓勵啊啊啊）
拍 10~30 下：希望我可以多寫一些文章！有你這位讀者，寫這篇也心滿意足了！
拍 30~50 下：內容對你感覺很有共鳴，希望能多分享給周圍的朋友！謝謝你願意把我的文章閱讀完
如果你喜歡筆者在 Medium 的文章，可以拍個手（Claps），
也歡迎你分享給你覺得有需要的朋友們。
You May Interest In:
- 【產品經理｜挖掘需求】產品經理如何訪談用戶並分析找出需求？
- 【產品經理｜產品開發】理解產品經理在做什麼？如何開發？
- 【產品經理｜指標設計】如何為產品設計恰當的成功數據指標？
- 如何快速上手資料科學專案流程（上）
- 快速上手資料科學專案流程全攻略（下）
- Lean Analytics — 總說數據分析，你在分析什麼？
