那場會議其實不難看。
投影幕上的頁面乾乾淨淨，彙整了近三週的使用者回饋：「希望更快」「流程不直覺」「介面看不懂」「價格有點高」。
每一條都合理，每一條都像真話，也每一條都足以讓團隊忙上兩個月。
會議室裡的人都很熟練：
產品負責人把問題分類，工程師開始想技術解法，行銷同仁補一句「市場上也這樣說」，最後把待辦事項排成優先順序。看起來一切都在掌控中。
但奇怪的是——沒有人眼睛發亮。
那種「終於抓到問題」的篤定感，沒有出現。取而代之的是一種微妙的疲倦：像你明明在跑步，卻總覺得自己一直在原地。
最後，是坐在角落的 Leo 開口。
他不是最會講話的人，甚至平常不太插話，但那天他把筆放下，輕聲問了一句：
「我們有沒有可能，一直很努力，但其實在解錯題？」
那句話像把會議室的氧氣抽走一半。
大家突然發現，自己一直在「做事」，卻沒有真正「逼近答案」。
一、照客戶說的做，為什麼常常做出「沒人非用不可」的東西？
Leo 是典型的理性派。他相信只要系統做足：訪談、問卷、競品比較、需求排序……答案就會浮出水面。
他也相信「聽客戶的話」是一種安全策略——至少錯了也不是自己的錯。
某次，一位關鍵客戶在電話裡說：「我們需要更耐用、更快的工具。」
這句話對 Leo 來說非常舒服：可量化、可執行、可寫進規格。
於是團隊把材料升級、結構加固、速度優化，做出一個性能漂亮到會讓工程師驕傲的新版本。
測試報告上滿是上升箭頭，像一場勝利。
然而三個月後，數據卻不如預期：
沒有大量退貨、沒有炸裂式負評，只有一種更難處理的狀況——沉默。
沉默的意思是：「你做得不差，但我也不急著用。」
沉默的意思是：「你提供的價值，不足以讓我改變行為。」
後來 Leo 跟一位老客戶吃飯，忍不住問：「我們不是照你們說的做了嗎？」
對方想了想，回了一句很平淡的話：
「不是不好。只是我們現在用舊的，也過得去。」
那句話很輕，卻像重錘。
因為它指向一個殘酷的事實：
表層需求就算被滿足，也不等於行為會改變。
而商業的成敗，恰恰就躺在「行為會不會改變」這條線上。
二、你以為你在做需求，其實你在收集「客戶的說法」
我們很容易把「客戶說的」當成「客戶要的」。
但多數時候，客戶提供的是「他以為可被理解的答案」。
因為人說話有兩個本能：
- 選一個安全的版本
「我想要更快」比「我不想再被主管罵」安全。
「我在意價格」比「我怕自己買錯」安全。
「我需要功能」比「我其實很焦慮」安全。 - 用解法描述問題
客戶常常直接講解法：要一個更快的系統、更耐用的零件、更漂亮的介面。
但那未必是問題本身，只是他最容易想到的解法。
這也是為什麼你會看到一種典型的產品病：
功能越做越多、清單越排越長，市場卻越來越冷。
因為你收集到的不是需求，而是「說法」。
說法能讓你很忙，卻不一定能讓你更接近真相。
三、5 Whys：真正的洞察，是把答案一路問到「不太好聽」
那天之後，Leo 把團隊叫到小會議室，白板上只寫一句話：
「使用者說：希望更快。」
他沒有先問「怎麼做得更快」，而是先問：「為什麼你想更快？」
第一層答案通常都很順：
「因為流程慢，會浪費時間。」
那很好，像是在做簡報。
Leo 接著問第二次：「為什麼浪費時間對你這麼痛？」
答案開始更私人：
「因為我每天都被催，做不完會被罵。」
第三次：「為什麼被罵對你影響這麼大？」
對方停了一下：
「因為我覺得自己很沒用。」
第四次：「那你真正想要的，是更快，還是……？」
那句話說到一半，會議室突然靜下來。
因為大家都知道，那個「還是」後面藏著的，可能不是功能，而是情緒。
很多團隊會在第三次或第四次停下來。
不是因為沒有答案，而是因為答案開始不好看：
它會牽涉到恐懼、自尊、被評價、被淘汰、對不起家人。
但真正的需求往往就住在這裡。
5 Whys 的價值，不是「問到第五次就會出現神諭」，
而是它逼你承認：
你在解決的，可能不是工具問題，而是人的處境問題。
四、洞察真正痛的地方：它會逼你推翻自己最驕傲的版本
當白板上的字從「更快」變成「不再被催、被罵、被否定」，
團隊開始不安。
因為這意味著：
原本做的「性能提升」，可能只是表面；
真正的價值，可能在「讓他感覺掌控」——例如提示、預警、減少不確定、降低犯錯成本。
那天深夜，Leo 看著團隊做出的功能清單，突然冒出一個想法：
「我們是不是做了一個很強的工具，卻沒有讓人變得比較安心？」
他沒有立刻講出口，因為那句話很危險。
它會讓人覺得之前的努力都白費了。
但洞察就是這樣。
它不只給你方向，它還會逼你付代價：放下舊答案、承認自己可能一直在錯的方向精進。
很多團隊在這一步退回去：
他們寧願把既有產品做得更好，也不願意承認「題目可能不對」。
但市場不會因為你很努力，就給你及格。
五、同理心不是同情：是把自己丟進對方的限制條件裡
後來，團隊做了一件很反直覺的事：
他們暫停討論解法，改成「同理心體驗」。
Nina 是設計師，她平常最常說的一句話是：「我懂使用者。」
她做過訪談、看過回饋、也能把使用者抱怨背得滾瓜爛熟。
但那天 Leo 要她做的不是訪談，而是角色交換。
Nina 必須在特定的限制條件下完成任務：
時間被壓縮、環境被干擾、資訊被拆散、錯一次就要重來。
她還得同時接電話、被打斷、在一堆噪音裡做判斷。
原本在設計稿上看起來只是「多一步」的流程，
在現場卻變成「多一次崩潰」。
她在第二次重來時就忍不住皺眉，第三次開始咬牙，第四次乾脆停下來，盯著螢幕不說話。
那不是她不專業，是她第一次真正在身體裡感受到使用者的處境：
那種「我做得到，但我受不了」的疲憊。
她回到座位，翻開筆記本，寫下一句話：
「以前我以為他在抱怨功能，現在我知道，他在抱怨的是：我一直被迫犯錯。」
這就是同理心的真相：
不是「我懂你」，而是「我願意暫時活成你」。
六、MVP 的本質：不是做簡單版，而是縮短自以為正確的時間
當洞察更清楚後，下一題是：怎麼驗證？
這裡很多團隊會犯第二個大錯：
想等到「完善」再推出。
但洞察越深，越不可能一次到位。
因為你面對的是人的情緒與行為，這種東西不會照你想像運作。
Leo 於是提出一個原則：
「我們不要做完美版本，我們要做可以被否定的版本。」
他們做了一個很小的 MVP：
把最關鍵的「減少不確定、降低犯錯成本」先做出來，
讓一小群種子使用者先用，然後每週回收回饋、每週更新。
第一週回饋很刺耳：
「這個提示很煩。」
「我看不懂。」
「我會忽略它。」
第二週，他們調整。
第三週，使用者語氣開始變了：
「我現在比較不怕漏掉。」
「好像比較有掌控感。」
「我終於知道下一步要做什麼。」
你會發現，市場的回饋不一定立刻給你掌聲，
但它會給你一種更珍貴的東西：方向感。
MVP 的價值不是省成本，
而是讓你不要在錯的方向上走太遠。
七、最終結論：需求不會自己現身，你得走得夠近、問得夠深
幾週後，團隊收到一封很短的信。
沒有長篇抱怨、沒有條列功能建議，只有一句話：
「我說不清楚我需要什麼，但我現在用起來，比較安心。」
那一刻，Leo 沒有慶祝。
他只是靜靜看著那句話，心裡冒出一個很清楚的念頭：
這才是需求。
不是「更快」，不是「更耐用」，不是「更便宜」。
而是「我終於不用一直害怕自己做錯」。
你會發現，客戶其實不是不會說真話。
而是多數真話都太赤裸、太情緒化、太難開口。
所以他會用功能包裝，用規格代言，用價格當遮羞布。
而你的工作，是把那層包裝拆開：
- 用 5 Whys 把答案問到「不太好聽」
- 用同理心體驗把自己丟進對方的限制條件
- 用 MVP 縮短自以為正確的時間，讓市場替你校準
最後，你會得到一個很踏實的結論：
你聽見的，不一定是需求。
真正的需求，藏在他不敢說、也說不清的地方。
而洞察的本質，是你願不願意走到那裡，並承接答案。
附：一套可落地的「需求洞察三步驟」
Step 1｜把客戶話語改寫成「處境句」
把「要更快」改寫成「我在被催、怕做不完」。
把「要更耐用」改寫成「我不想半路出事、害我扛責」。
Step 2｜用 5 Whys 問到「恐懼／價值／身分」
每次問完都寫下「這句話背後的情緒是什麼？」
你會很快看見：需求常常是安全感的別名。
Step 3｜做一個「可被否定」的 MVP
不要做完整產品，只做最能驗證洞察的一小段。
目標不是被稱讚，而是被快速修正。
喜歡這篇文章嗎？立刻點下愛心支持！ 👉 加入會員並追蹤我，第一時間獲得最新文章、職場洞察與成長秘訣。 讓我們一起成為更清醒、更強大的自己！🚀
精選金句
- 你聽見的不是需求，是客戶最容易說出口的版本。
- 功能可以抄，洞察抄不走；洞察來自你問得有多深。
- 客戶不是不說真話，而是很多真話「說不清」。
- 第一層答案很安全，第三層答案才開始接近真相。
- 真正的洞察，常常先摧毀你原本最驕傲的答案。
- 同理心不是同情，是把自己丟進對方的限制條件。
- 產品賣不動，往往不是你做得不夠好，而是痛點不夠痛。
- MVP 不是做簡單版，是讓市場更早否定你。
- 市場不會獎勵努力，市場只回應「行為是否改變」。
- 需求不會主動現身；你要走得夠近，才配得上答案。
