有些創業念頭，不是生在白板前。
它比較像是卡在喉嚨裡的一根小刺。你不一定第一天就想創業，甚至一開始也沒打算做產品。你只是反覆碰到某個情境，反覆覺得哪裡不對，然後那個不對，怎麼想都過不去。
我後來越來越相信，多數值得做的題目，不是從「我有一個很酷的 idea」開始，而是從「這件事真的很不舒服，而且不只我一個人不舒服」開始。
這系列叫《從痛點到事業》，不是因為痛點兩個字很創業，而是因為很多人真的在第一步就走偏了。
不是沒有能力做事，而是太快往解法衝，還沒把問題看清楚。
Essence
讀這 11 篇時，可以持續抓住下面這段。 這是我多年以來的在解決問題上依靠的核心思考原則，它像是一張總地圖，幫你理解這整套內容到底在做什麼：不是零碎地談工具，而是一步一步帶你從發現問題、理解問題、分析問題，走到形成解決方案。
一、期許
我們意圖針對 ① 什麼當事人、在什麼特定情境下，提供 ② 什麼產品與服務，讓這些人得以翻轉 ③ 什麼情境下想完成事情的未滿足重大期許落差的現狀，使其完成 ④ 什麼想完成的重大事情，並在過程中發生 ⑤ 什麼潛移默化、根本改變，因而能創造出 ⑥ 對當事人什麼樣的情境與可能引伸而來的價值與意涵。
二、機會點
① 在什麼群體之下有多少比例的人，會處於什麼特定情境下（請以洞見與證據描述），意圖完成 ② 什麼想完成的重大事情（請以洞見與證據描述），然而卻遇到了 ③ 什麼重大期許落差無法滿足的狀況，雖然這些人試圖 ④ 曾經採用什麼解決方案、嘗試想要解決問題，然而總是無法如願，只好持續因期許落差沒有解決而付出什麼代價、後果。
三、解決方案
在研究了 ① 哪些證據、案例、研究、調查以後，我們認為真正的問題在於 ② 什麼施力點化解了，就可以解決問題，③ 為什麼根據你談的證據或研究，可以推出這個施力點。
因此，我們將根據 ④ 什麼化解罩門的途徑（請描述你在證據中獲得的洞見），打造 ⑤ 什麼產品與服務，讓當事人能夠在過程中 ⑥ 產生什麼根本改變（請說明有什麼可以發生，立論基礎是什麼），終至 ⑦ 重大期許滿足後達到什麼理想境界。
很多人不是沒有解法，而是太早有解法
很多創業討論，一開口就是：
- 我要做一個平台
- 我要做一個媒合系統
- 我要做一個 AI 工具
- 我要做一個社群
- 我要做一個會員機制
這些句子本身都沒錯。
但它們有一個共同問題：講的都是供給面，不是需求面。
也就是說，你已經開始描述自己打算「做什麼」，可是還沒真的說清楚：
- 到底是誰卡住了？
- 他卡在哪？
- 他原本想完成什麼事？
- 他心裡期待的結果是什麼？
- 現在為什麼一直達不到？
這幾個問題如果沒有先站穩，後面的 solution 再漂亮，常常也只是把錯的題目做得很完整。
這不是理論上的潔癖。
這是很現實的事。
因為市場不是缺產品，市場缺的是：有人真的把那個卡點看準。
先不要急著叫它痛點，先確認那是不是「有感的現象」
我比較喜歡先用一個比較土、但比較準的說法：確認有感的現象。
什麼叫有感？
不是問卷上有人勾「是」。
也不是訪談裡對方出於禮貌說「嗯，這好像有需要」。
真正的有感，通常長這樣：
- 他已經被這件事困擾一段時間
- 他有試過別的方法處理，但都不太順
- 這個問題真的影響到效率、情緒、成本、風險、面子，或生活品質
- 只要提到這件事，他會講得很具體
真正有感的問題，不太需要你一直幫它補情緒。
對方一講起來，細節會自己冒出來。
反過來說，如果一個題目需要你一直幫他補句子、幫他想情境、幫他湊痛苦，那通常就要小心。
那可能不是一個問題，只是一個概念。
接下來不是問「誰是 TA」，而是問「到底是哪個當事人卡住」
很多人一開始會把人群定得很大。
像是：年輕人、創業者、上班族、旅客、學生、獨立旅宿。
這些分類在做投影片時很方便。
但真的拿來找問題，往往太鬆。
比較有用的問法不是「我的 TA 是誰」，而是：
在這個情境裡，到底是哪個當事人，正試著完成一件事，但一直做不順？
也就是 JTBD：Job To Be Done。
JTBD 不是標籤。
它比較像一個具體任務。
不是「他是一位旅客」，而是：
- 他到陌生城市後，想快速找到可信任、價格合理、符合自己偏好的住宿
不是「她是一位內容創作者」，而是：
- 她想穩定產出內容，但又不想每天被蒐集資料、剪貼整理拖掉整個下午
不是「這是一間獨立旅宿」，而是：
- 它想在不完全依賴 OTA 的情況下，建立可以持續觸達旅客的關係
當你把「人」換成「人在某個情境裡想完成的任務」，很多事情會突然清楚。
因為你不再只是描述身分，而是開始碰到真實摩擦。
只有任務還不夠，還要問：他期待的結果是什麼
同樣是要完成一件事，不同人想要的結果可能差很多。
有些人要快。
有些人要安心。
有些人要省錢。
有些人要可控。
有些人要的是不要出錯。
還有人要的是不要讓自己看起來很蠢。
所以在 JTBD 後面，還要補一層：Outcome Expectation，也就是當事人心裡真正想要的結果。
這層很重要，因為很多產品就是死在這裡。
表面上看起來在解同一個任務，實際上卻對錯了結果。
例如有人找記帳工具，不一定是想做出最完整的財務管理。他可能只是想在月底不要再搞不清楚錢跑去哪裡。
有人找旅遊規劃工具，也不一定是想要一套很強的 AI itinerary。他可能只是想在有限時間內，不要再因為資訊太雜而一直猶豫。
獨立旅宿說想提高 direct booking，也不一定只是想要更多官網流量。它可能真正想要的是顧客關係、可控性、淡季安全感，或是不再每次都向平台買流量。
任務是表面動作。
期待結果，才比較接近他心裡真正的交付標準。
真正要抓的，是 Important Unfulfilled
到了這裡，還不能停。
因為市場上大部分問題，都不是完全沒人碰過。
真正有意思的，是那種：重要，而且目前仍未被滿足。
也就是 Important Unfulfilled。
這裡至少有兩個條件要同時成立：
- Important：這件事對他真的重要，不是可有可無。
- Unfulfilled：現有替代方案沒有把它處理好，或者代價太高。
如果只有 important，沒有 unfulfilled，那可能只是成熟市場。
如果只有 unfulfilled，但不 important，那就很容易做成小修小補。
所以可以問幾個很直接的問題：
- 他現在怎麼解？
- 他為什麼還在忍？
- 現有方案有什麼地方他不想用、懶得用、用不起，或用了還是不爽？
- 這個落差有沒有大到足以讓他改變行為？
這一層不做，後面很容易陷入一種幻覺：
看起來大家都有需求，實際上只是大家都「覺得不錯」，沒有人真的會換。
再往下挖，會碰到價值、意義與期許
有些題目如果只停在效率、成本、功能，會看得太淺。
因為人不是只想把事情做完。
很多時候，他還想把事情做得比較像自己。
這就是 價值 / 意義 / 期許（Aspiration）。
有時候一個人買的不只是工具，而是一種比較體面的自己。
有時候他要的不是更快，而是更安心。
有時候他要的不是更多功能，而是終於不必每次都靠運氣。
如果只從功能面看，會以為他要一支鑽頭。
但如果再往下問一點，會發現他要的可能是：
- 一種比較穩定的生活
- 一種比較可控的工作方式
- 一種不再一直被打斷的節奏
- 一種能讓自己更接近理想樣子的可能性
這些東西很抽象，但它們其實會決定一個人會不會真的採用你的解法。
Gap 是怎麼來的：需求面與供給面的錯位
到了這一步，才比較適合談 Gap。
我對 Gap 的理解很簡單：
Gap 就是當事人期待的結果，和現在實際拿到的結果之間，那段一直過不去的落差。
但這個落差不是憑空出現的。
它通常是需求面和供給面長期錯位的結果。
需求面常見的癥結
- 使用情境太碎，需求其實很脈絡化
- 表面說的是 A，真正困擾的是 B
- 當事人自己也不一定說得清楚需求
- 需求會隨情境、時間、角色改變
供給面常見的癥結
- 產品是從功能清單出發，不是從任務出發
- 提供的是平均解，不是針對關鍵卡點的解
- 解法太重、太複雜、太昂貴
- 產品以為自己在解主問題，實際上只解到邊角
很多 Gap，都是這兩邊一起造成的。
不是只怪使用者不懂，也不是只怪市場沒產品。
而是要把兩邊一起放上來看。
找題目時，不要只問哪裡痛，還要問瓶頸在哪
痛點很多時候是一團。
但真正能拿來做事的，通常是 Bottleneck。
也就是：
在整條流程裡，哪一個卡點最限制結果？
不是每個痛都值得先解。
有些痛只是煩。
有些痛才是節點。
例如某個服務流程裡：
- 表單很醜，這可能只是不好看
- 資訊很散，這可能只是麻煩
- 但如果真正讓人卡住的是「他無法判斷哪個選項可信」，那那個決策焦慮才可能是瓶頸
找不到 bottleneck，常見結果就是：團隊一直忙，可是結果沒有被推動。
因為大家一直在改善周邊摩擦，沒有打到真正限制系統產出的那一下。
解法不是不能想，但要放在後面，而且要舉一反三
當有感現象、當事人、JTBD、期待結果、Important Unfulfilled、Aspiration、Gap、Bottleneck 這些東西慢慢被梳理出來，這時候再進到解法，會穩很多。
這時候也不要只想一個 solution。
要刻意做「舉一反三」：
- 如果用人工服務解，怎麼解？
- 如果用軟體工具解，怎麼解？
- 如果用流程重設解，怎麼解？
- 如果只做資訊重新組織，不做重功能，能不能解一半？
- 如果根本不做產品，而是做中介、顧問、社群、內容，會怎樣？
這一步的目的，是讓自己不要太早綁死在某個 solution type。
很多人創業不是死在沒有想法，而是死在第一個想到的做法，剛好不是最適合的做法。
然後才談假設、MVP，還有 C-P-S Fit
如果前面都比較像看問題，走到這裡，就要開始看：這件事能不能被驗證、被落地。
這時候可以用 C-P-S Fit。
我把它讀成三個東西要對上：
- C｜Context / Customer situation：當事人所處的情境
- P｜Problem / Promise / expected progress：他想完成的事、期望落差、施力點
- S｜Solution：你提供的解法
換句話說，不是只有 Problem-Solution Fit。
還要看這個 problem 是不是放在對的 context 裡被理解。
因為同一個問題，一旦情境不同，解法就可能完全不同。
C-P-S Fit 的內涵
在當事人的真實情境下，重新看：
- 他要完成什麼事
- 現在卡在哪裡
- 期待的結果與現狀差多少
- 可施力的點在哪裡
- 你提出的 solution 是不是正好卡進那個缺口
C-P-S Fit 的呈現
C-P-S Fit 至少要能落到幾種表達：
- 期許：他真正想要什麼
- 價值主張：我們為什麼值得他採用
- 一句話表述：把 context、gap、solution 壓成一句可檢查的陳述
- User Story：把人、情境、動機、結果串起來
例如：
對於第一次到陌生城市、又不想花大量時間比價的自由行旅客，我們提供一種快速縮小選擇範圍的方法，讓他能在安心與效率之間取得平衡，而不是在十幾個分頁之間來回猶豫。
這種句子不一定最後要直接拿去當 slogan。
但它很適合拿來檢查：你到底在幫誰解哪個 Gap。
C-P-S Fit 的驗證
很多題目不是想不出來，而是太容易被自己說服。
所以要把假設一條一條寫下來：
| 假設 | 為什麼重要 | 要怎麼驗證 | 目前證據 | 結論 |
|---|---|---|---|---|
| 目標用戶對這個問題真的有感 | 沒有痛就不會採用 | 訪談 10 位目標用戶 | 7 人可具體描述困擾 | 初步成立 |
| 現有替代方案真的不夠好 | 否則沒有切入點 | 請受訪者描述現行做法 | 多數人用 workaround，且抱怨高 | 成立 |
| MVP 至少能減少決策時間 | 驗證核心價值 | 任務測試、前後測 | 待驗證 | 未定 |
Logbook 的價值也很大。
因為你之後回頭看，常常會發現自己不是沒做事，而是一直在同一個錯誤假設附近打轉。
MVP 不是迷你版產品，而是最小必要驗證
很多人把 MVP 理解成「先做一個功能比較少的版本」。
這常常不夠準。
更好的問法是：
要驗證目前最關鍵的假設，最小必要的東西是什麼？
有時候那是一個 landing page。
有時候是一場手動服務。
有時候是一份問卷加一輪訪談。
有時候是一個 Notion 頁面。
有時候甚至不是產品，而是一個「假裝產品存在」的流程。
如果現在最想驗證的是「這個人會不會因為這個價值而願意採取行動」，那根本不一定需要先寫系統。
MVP 是實驗，不是縮水版理想。
一個題目真正站得住之前，要能回答六個問題
到了 launch 前，這件事至少要能回答六個問題：
- 這是誰的什麼重大期許落差？
- 這個重大期許落差是怎麼形成的？
- 這個問題要解決，必須面對哪些挑戰？
- 能化解重大期許落差罩門的解決方案是什麼？
- 如何定義成功與價值？可以看到什麼具體、可檢驗的指標？
- 這個解決方案創造了什麼價值，並且可能發展出什麼意涵？
這六個問題比「我的 idea 好不好」更殘酷。
也更有用。
因為它不是在問你喜不喜歡自己的想法，而是在問：這個想法有沒有被壓成一個可以被市場檢驗的判斷。
先把問題看準，再談配方
如果把這一篇濃縮成一句話，我會這樣說：
題目不是從點子開始，題目是從某個一直被忽略、但真的有感的落差開始。
所以從痛點到事業，第一步不是創意激發。
第一步是把那個落差看清楚。
你要先確認：
- 有沒有真的有感的現象
- 當事人是誰
- 他要完成的 JTBD 是什麼
- 他期待的 Outcome 是什麼
- 哪些需求既重要又未被滿足
- 他背後真正的 Aspiration 是什麼
- 需求面與供給面為什麼會形成 Gap
- 真正的 Bottleneck 落在哪裡
- 可能有哪些解法方向
- 需要驗證的假設是什麼
- 最小必要 MVP 是什麼
- 有沒有機會形成 C-P-S Fit
做完這些，你未必立刻找到答案。
但至少比較不容易一開始就對錯題目。
下一篇會進到工具：Design Thinking、Double Diamond、Value Proposition Canvas、Empathy Map、Journey Map、Stakeholder Map、5 Whys、Assumption Map，還有 Four D Process。
它們不會替你思考。
但用得好，會讓你比較難假裝自己已經想清楚。