在 Draper U 另一堂課裡，講者問了一個比「為什麼客戶會買」更不舒服的問題：

如果對方真的有需求、有預算，也看得懂你的價值，為什麼還是不買？

這個問題一丟出來，很多 founder 的第一反應都差不多。

是不是還沒講清楚。
是不是 timing 不對。
是不是功能不夠。
是不是 target customer 找錯了。

這些都可能成立。只是很多時候，大家答得太快了。
快到你還沒真的看見，卡住交易的根本不是價值不夠，而是切換太痛。

那堂課把這件事叫做 friction。
我自己後來比較常用的詞是：adoption cost。

因為很多產品不是敗在沒價值，而是敗在「用了你之後，我還得再吞一堆麻煩」。

你真正的競爭對手，常常不是另一個產品

這是我以前很容易看錯的一件事。

創業者腦中想的競品，通常是另一家新創。
客戶腦中真正拿來比較的，往往是：

  • 現在這個舊系統先繼續用
  • Excel 先撐一下
  • 助理手動做
  • 團隊自己 workaround
  • 乾脆先不處理

也就是說，你真正要打敗的，很多時候不是別人的 roadmap。
是別人的現狀。

這也是為什麼「我的產品明明比較好，為什麼客戶還不換」這種抱怨，幾乎每一代 SaaS founder 都會講一次。

因為客戶不是只在比功能。
他在比的是：換過去之後，我還要多痛多久。

所謂 switch value，本質上是在算一筆更完整的帳

那堂課裡有一個很粗暴但很好記的公式：

Switch value = perceived value - price - adoption cost

它當然不是財務模型，比較像一個提醒。
你不能只盯著價格，也不能只盯著自己認為的產品價值。客戶真正在算的，是另一筆比較不體面的帳：

  • 這東西是不是值得？
  • 我現在要付多少？
  • 換過去之後，我還得承擔多少不舒服？

如果第三項太大，前兩項再漂亮，交易還是會死。

這也是我後來越來越少把「降價」當成預設解法的原因。
因為很多 deal 死掉，不是 price problem。
是 adoption problem。

adoption cost 長得很像小事，累起來卻很重

最麻煩的地方在於，adoption cost 很少長得像一個大問題。它通常長得像一堆小事：

  • 要不要重學一套介面
  • 既有資料怎麼搬
  • 現在流程裡那些例外情境誰來補
  • security 要不要多看一輪
  • champion 要不要替你扛內部風險
  • 一旦導入失敗，誰背鍋

單看每一項，好像都沒有嚴重到足以毀掉交易。
合起來就很夠了。

這也是為什麼很多產品明明更便宜、更漂亮、功能更多，客戶還是會說：

Thanks, but not now.

他不一定會老實說真正原因。
很多時候連他自己都不會把那個感覺講成 adoption cost。
他只知道，切過去麻煩。

friction 不是 UX 細節，它常常就是商業問題

這是我後來最確定的一個修正。

很多團隊把 friction 當成設計 polish。
等產品成熟一點，再來改 onboarding、減欄位、優化結帳就好。

問題是，如果你的採用路徑本身就很痛，那它就不只是 UX 問題，而是產品策略和 GTM 問題。

Baymard 追蹤 cart abandonment 很多年了，現在全球平均仍大約在 70.19%。這當然不表示每一筆 abandon 都是 UX 的錯，因為很多人本來就在逛。但 Baymard 也一直指出，checkout 本身的複雜度會直接吃掉原本很接近成交的流量。他們近年的研究裡甚至還提到，平均結帳流程仍有 11.3 個表單欄位，而有相當比例的使用者曾因為流程太長或太複雜放棄購買。

電商不是 SaaS，這我知道。
但原理完全一樣：當一個人已經快買了，一點多餘摩擦都可能把他推回去。

NN/g 對 forms 的說法更直接。
Forms are mental work.
表單不是畫面元素而已，它們是在跟使用者借認知成本。你每多丟一個欄位、多一個不確定、多一個需要停下來想的地方，都在往 adoption cost 上面加碼。

把這件事放到 B2B，只會更重。

真正重的 friction，很多是政治的，不是技術的

這也是 founder 很容易低估的地方。

我們很容易把 adoption cost 想成 technical migration：資料怎麼搬、系統怎麼接、舊工具怎麼退。

那些當然算。
但我後來覺得更重的，常常是這些：

  • 內部誰要主推這件事
  • 誰要說服同事改習慣
  • 誰要承受「如果這次切換出事」的責任
  • 採購、法務、資安是不是又要多一輪
  • 你到底是在賣一個工具，還是在要求整個團隊改工作方式

這些東西在 pitch 裡很少被講。
但在交易裡，它們常常比 feature list 更有殺傷力。

所以如果一個客戶不換，不代表他沒看見你的價值。
他可能只是看見了另一筆你沒算進去的痛。

這也是我後來為什麼會對 adoption cost 這件事變得特別敏感。不是因為我後來多看懂了幾份研究，而是因為自己真的在旅宿 BD 上撞過一次。那時候我解的問題其實是真的。OTA 抽成高、資料拿不回來、忠誠度做不起來，少數願意坐下來聊的旅宿業者幾乎都知道。問題從來不是「這是不是假需求」。問題是，知道，不代表會動。只要短期價值還不夠直接、導入還要改流程、風險感又偏高，再合理的方案都可能先死在採用，而不是需求本身。這段我在另一篇〈問題大家都知道，旅宿業者為什麼還是不動〉寫得比較完整。那篇其實不是 06 的延伸閱讀而已，更像是我後來真的被市場修正過一次後，才把這件事學會。

不是所有 friction 都該被消滅

話也不能講得太乾淨。

有些 friction 當然是爛 friction。
像是不必要的欄位、太早逼註冊、模糊的 next step、把你內部沒整理好的流程直接丟給客戶。

這種能砍就該砍。

但也有些 friction 是必要的。
高金額交易本來就需要確認。
Enterprise 採購本來就會慢。
金流、合規、權限控管，有時候不能為了順就全部拿掉。
某些設定流程真的需要使用者做判斷，你不能假裝它不存在。

所以成熟一點的問法，不是「怎麼把 friction 清零」。

而是：

  • 哪些 friction 是必要成本
  • 哪些 friction 只是你偷懶
  • 哪些 friction 其實是你把公司的複雜度外包給客戶

第三種最糟。
因為那通常代表，你自己都還沒把問題設計好。

早期最值得做的，常常不是多做功能，而是主動吃掉 adoption cost

這點我現在反而越來越有感。

OpenView 寫 Attio 那篇，裡面有一段我很喜歡。Attio 早期 onboarding 幾乎是 100% white-glove，團隊自己幫客戶設定帳號、搬資料、陪跑導入，之後才慢慢把這些流程產品化。

這種做法看起來很不性感。
也不 scale。
但它其實很誠實。

你先承認 adoption cost 就在那裡。
然後不是假裝它不存在，而是先把它搬回自己身上。搬久了，你才知道哪些 friction 值得產品化，哪些 friction 其實是 category 的門檻，哪些 friction 只是你原本沒把事情想清楚。

這個順序比「先把功能做完再等 adoption 發生」可靠得多。

我現在比較常用這幾題，檢查一個產品到底卡在哪

產品賣不動時，我現在不太會先問價值是不是還不夠強。
我會先問：

  • 客戶從今天的做法切到你這裡，要多做哪些事？
  • 哪一步最煩？
  • 哪一步最容易出錯？
  • 哪一步如果失敗，誰會在組織裡受傷？
  • 你有沒有把自己的複雜度偷偷轉嫁給客戶？

如果這幾題沒被回答，很多團隊就會走進一個很熟悉的循環：

產品賣不動
→ 以為是功能不夠
→ 功能越做越多
→ adoption 更難
→ 銷售更慢
→ 再加更多功能

最後把自己埋掉。

市場不會因為你比較好，就自動獎勵你

這大概是我從那堂課裡留下來最深的一個修正。

我們很容易把「我的產品比較好」當成一種應得的優勢。
好像只要產品真的更好，市場遲早會看見。

現實沒有那麼體貼。

市場獎勵的，常常不是更好的產品本身。
而是更容易被採用的更好產品。

這差幾個字，差很多。

因為客戶不是在替你完成創業夢。
他只是在算：換你值不值得。

所以如果今天交易一直推不動，與其一直強調自己比別人多厲害，我反而會先把 adoption cost 算清楚。
你不一定能全部拿掉。
但你至少要知道，痛到底藏在哪裡。