文章類型

專業方法文 / 問題定義文

這篇想先講的一句話

很多 PM 聽完幾場訪談之後，很容易帶著一個過度樂觀的錯覺離開：

  • 使用者有抱怨
  • 這個抱怨聽起來合理
  • 團隊也想得到一些對應功能
  • 所以這應該就是下一個值得解的問題

但研究現場真的不是這樣運作的。

因為：

  • 有抱怨，不代表那是高權重問題
  • 有摩擦，不代表那摩擦真的推動了行為改變
  • 有需求描述，不代表你已經抓到 job
  • 有意見，不代表你知道他是在什麼情境下說的
  • 有 solution request，更不代表你應該照單全收

所以這篇真正想講的是：

痛點不是一句抱怨，JTBD 也不是把需求重寫得比較高級。
它們都需要回到真實脈絡裡，重新確認：

  • 這個人原本想完成什麼進展
  • 什麼事件讓他開始覺得原本做法不夠了
  • 他當時怎麼衡量風險、替代方案和切換成本
  • 這個痛到底痛到什麼程度
  • 它是否真的有能力推動 search、switch、delay、abandon 或 workaround

先把一件事講清楚：JTBD 不是 persona 重寫，也不是 feature request 收集法

JTBD 很容易被講得很神，也很容易被講得很空。

我自己比較喜歡一個務實的理解：
它不是在問「使用者喜歡什麼功能」，而是在問：

當這個人雇用某個產品、服務或 workaround 時，他到底想推動自己在生活或工作裡往前跨哪一步？

這裡的重點不是產品本身，而是「進展」。

所以如果一場訪談最後只得到這種句子：

  • 我希望可以更方便
  • 我想要更多篩選功能
  • 我希望比較好比較
  • 我想要更清楚的資訊

這些都還太表面。
它們可能是真的，但還沒有碰到 job。

因為 job 比較像這些：

  • 在高風險預訂前，先把不確定性壓到自己可接受的程度
  • 在有限時間內，快速縮小選項，不想把晚上都耗在比較上
  • 在團隊流程裡留下可交代的紀錄，不想被追問「你怎麼決定的」
  • 在開始付費前先證明這工具真的能讓我進入工作狀態

你會發現，這些句子比較不像功能 wishlist，反而比較像「我正在努力往哪裡移動」。

為什麼我會說：抱怨不等於痛點？

因為很多抱怨只是表面噪音，還沒有到會改變行為的程度。

舉例來說，使用者可能會抱怨：

  • 選項太多
  • 搜尋結果不夠準
  • 首頁有點亂
  • 比較麻煩
  • 付款前資訊不夠完整

這些當然都值得注意。
但 PM 真正要分辨的是：

  • 這只是 annoyance，還是會導致 abandon？
  • 這只是 preference，還是會導致 switch？
  • 這只是嘴上嫌煩，還是已經出現 workaround？
  • 這只是低成本不爽，還是高成本摩擦？

所以對我來說，痛點比較像一種能夠推動行為改變的阻力。
不是只因為它負面，而是因為它有重量。

我怎麼判斷一個問題有沒有重量？我通常看四件事

1. 頻率

這不是只發生一次的意外，還是反覆出現？

如果某個問題只出現在很少數、很偶然的情境，它當然仍可能重要，但不能因為故事很強就直接放大。

2. 嚴重度

它只是讓人慢一點、煩一點，還是會讓人真的卡住、放棄、退回去找別的方法？

3. Workaround 成本

人已經怎麼補這個洞？

  • 需要靠筆記、截圖、Excel、同事提醒
  • 需要花更多時間比較
  • 需要切到其他工具
  • 需要先做額外確認

如果 workaround 已經穩定存在，而且成本不低，通常表示這個痛不是空氣。

4. 行為後果

它有沒有真的改變後續行為？

  • 延後決策
  • 放棄流程
  • 轉去競品
  • 要求人工協助
  • 降低使用頻率
  • 根本不開始

很多研究做到這裡就會突然清楚：
不是每個負面感受都會長成值得優先處理的產品問題。

Switching moment 很值得看，因為它把「想法」和「行動」中間那段挖出來

我很喜歡把 switching moment 單獨拉出來看。
因為很多 PM 知道使用者最後換了工具、換了做法、開始找替代方案，但不知道那中間到底發生了什麼。

這一段如果不挖清楚，很容易產生一種錯覺：

  • 以為大家是因為某一個 feature 不夠而切換
  • 以為大家是看到競品很吸引人就切換
  • 以為 search 行為一開始就很積極

但很多真實決策其實不是這麼俐落。
它更像是一段累積：

  • 先有第一個不對勁的念頭
  • 然後被別的事打斷
  • 接著幾次小摩擦慢慢累積
  • 某一天有個 trigger event 發生
  • 才真的開始 search
  • search 之後也不是立刻切，而是比較、拖延、來回拉扯
  • 最後在某個 moment 才做決定

這就是為什麼 switch interview 很有價值。
它逼你不要只問「你為什麼換」，而是把整段時間線挖出來。

比起問「你想要什麼」，更有用的是把時間線和事件挖出來

這也是我覺得 JTBD / switching research 最容易寫壞的地方。

一旦你一直問：

  • 你想要什麼？
  • 你最在意什麼功能？
  • 你理想中希望怎麼做？

很快就會得到一堆抽象、假設性、偏 solution 的回答。

比較有用的問法通常會更貼近事件：

  • 你第一次覺得原本做法不夠用，是什麼時候？
  • 當時發生了什麼？
  • 那一天你在做什麼？誰也牽涉在裡面？
  • 你後來怎麼開始找替代方案？
  • 你有沒有拖延？為什麼？
  • 最後讓你真正下定決心的是哪一刻？
  • 你原本繼續不換也不是不行，那為什麼最後還是換了？

你會發現，這些問題不是在蒐集看法，而是在還原進展如何被阻擋，與改變如何被推動。

四種力量很有用，但不要把它們用成海報口號

很多人提到 JTBD，會很快講到 push、pull、habit、anxiety。
這套框架確實有幫助，因為它提醒你：

  • 有什麼力量把人從原本做法推出來
  • 有什麼吸引力把人拉向新選項
  • 有什麼慣性讓他留在原地
  • 有什麼焦慮讓他不敢換

但這套東西一旦用得太快，就會變成很像 workshop 海報的語言。
真正有用的做法，反而是先把故事挖清楚，再回頭用這四類力量整理。

不然你很容易在 evidence 還不夠時，就先把 participant 的世界壓成四格分類。

痛苦指數不是情緒強度而已，而是「這個問題有沒有改變現實」

你特別提到想寫痛苦指數，我覺得很值得，但要小心不要把它寫成很鬆的痛感量表。

如果只看語氣，你很容易被誤導。

有些人語氣很平，但其實 workaround 已經很重。
有些人抱怨很大聲，但實際上還是每天照做，沒有任何 switch 或 abandon。

所以我自己比較不會只問「你有多痛」。
我會把 pain intensity 拆成幾個更實的面向：

  • 這件事發生多常
  • 每次成本有多高
  • 是否影響任務成功
  • 是否影響信心或風險感
  • 是否已經迫使他建立 workaround
  • 是否已經推動 search / switch / abandon / delay

如果這些都沒有，很多時候那比較像 irritation，不一定是高優先級 pain。

什麼時候要停住，不要太早跳進解法？

這點對 PM 最難，也最重要。

因為一旦你開始懂他的脈絡，很自然就會想：

  • 那我們是不是該加一個比較功能
  • 那是不是要補一個模板
  • 那是不是要加一個提醒
  • 那 paywall 時機是不是要往後延

這些想法不是不能想。
但如果你在還沒把 job、switch trigger、pain weight 釘穩前就開始解題，很容易發生兩件事：

第一，你其實在解 symptom，不是在解 progress barrier。
第二，你太快把 participant 說的 workaround 翻成 feature 了。

所以這篇的邊界很清楚：
我們停在問題定義夠不夠硬。
還不進 solution ideation。

一個比較穩的 JTBD / pain research 輸出，應該長什麼樣？

如果我希望這種研究最後能拿來做產品判斷，我通常會希望輸出至少包含這些：

  • 這個 target user 想推動的 progress 是什麼
  • 現在用什麼做法勉強完成
  • 哪些事件開始讓原本做法不夠用
  • switching timeline 長什麼樣
  • push / pull / habit / anxiety 各自的證據
  • pain 的頻率、嚴重度、workaround 成本、行為後果
  • 哪些只是抱怨，哪些真的有決策重量
  • 接下來還需要補哪一類研究或數據驗證

這樣輸出，你後面不管是進問題解決、設計思考，還是優先級決策，都會比較穩。

結語：真正值得解的，不是大家都在抱怨的，而是那些能改變進展的阻力

我越來越覺得，PM 做研究最難的，不是收不到問題。
而是問題太多，抱怨太多，想法太多，很容易每個都覺得有道理。

但產品決策不是抱怨管理。
它最後還是要回到一個更硬的問題：

這個阻力到底有沒有重量，足不足以阻擋使用者往前推進？

JTBD 值得用，不是因為它名字很流行。
而是它逼你把注意力從功能願望清單，拉回人真正想完成的進展。
痛苦指數值得寫，也不是因為它聽起來比較科學。
而是它提醒你：不是每個不滿都值得最高優先級。

這個系列寫到這裡，主線其實已經完整了。
我們從數據盲點開始，走到方法選型、招募、訪綱、主持、分析，最後回到問題定義。

而你後面要寫的問題解決與設計思考篇章，最適合從這裡接手。
因為現在，我們終於比較有資格往解法走了。