Kano Model vs Jobs to be Done
Kano 模型 vs JTBD 任務理論
兩個都是產品思維工具，但回答的問題不同。JTBD 問「使用者雇用這個產品來完成什麼任務」——找的是需求的根源與定位；Kano 問「一個已知的功能會如何影響滿意度」——把功能分成必備、線性、興奮等類別。JTBD 在前找對方向，Kano 在後排對功能。
框架
Kano 模型
Kano Model
搞清楚產品功能對客戶滿意度的真實影響——不是所有功能都「越多越好」
讀詳細頁 →
框架
JTBD 任務理論
Jobs to be Done
搞清楚使用者真正「雇用」你的產品或服務來完成什麼任務——不是看人口屬性，是看任務情境
讀詳細頁 →
關鍵差別
什麼時候用 Kano 模型
已經有一批候選功能，要判斷哪些是「沒有會被罵」的必備、哪些是「有了驚艷」的差異化、哪些是浪費資源的無關功能時。
什麼時候用 JTBD 任務理論
在更前期——你還在問「使用者到底為什麼用我們、真正想完成什麼」，需要找對產品方向與定位，而不是排功能時。
結論
順序上先 JTBD 再 Kano：先用 JTBD 確定你在幫使用者完成什麼任務（方向），再用 Kano 把為這個任務服務的功能分類排序（執行）。方向錯了，功能分類得再準也沒用。
常見問題
它們會衝突嗎？
不會，是上下游的關係。JTBD 告訴你「該往哪個任務做」，Kano 告訴你「為這個任務做的功能裡，哪些必備、哪些能驚艷」。用 JTBD 選戰場，用 Kano 配武器。
只用 Kano 不用 JTBD 會怎樣？
容易把功能分類做得很精緻，卻服務了錯的任務——你很認真地優化了一批根本不是使用者真正想完成的事。Kano 確保你把功能做對，JTBD 確保你做的是對的功能。
興奮功能會過期，這跟 JTBD 有關嗎？
有。今天的興奮功能變成明天的必備（指紋解鎖、免運），背後其實是「同一個 job 的完成標準被抬高了」。用 JTBD 持續追蹤使用者想完成的任務如何演化，你才知道下一個興奮功能該往哪裡長。