Kano 模型 Kano Model

什麼時候該用它？

當你的 Backlog 裡躺著 50 個需求，業務主管喊著「這個客戶一定要」，工程師說「那個底層要重構」，而老闆只問你「下個版本亮點在哪？」的時候。Kano 模型能幫你跳出「誰大聲就聽誰」的泥沼，用使用者的真實滿意度來決定什麼該做、什麼該砍。

• Backlog 爆炸：功能需求堆積如山，需要結構化的分類方式
• 版本規劃：決定下一個 release 要放什麼功能進去
• 資源搶奪戰：各部門都覺得自己的需求最重要
• 產品成熟期：基本功能都有了，要找出能拉開差距的魅力功能

框架結構

Kano 將產品功能對應到「滿意度」與「具備程度」兩個維度，拆解出五種品質特性：

五種屬性

1. 必備屬性（Must-be）：沒做會被罵爆，做了滿意度也不會提升。例如：打車 App 不會亂扣款
2. 期望屬性（Performance）：越多越好，一分錢一分貨。例如：外送 App 的送達速度
3. 魅力屬性（Attractive）：沒做大家無感，做了會讓使用者驚呼「太酷了吧」。例如：買網購收到手寫感謝卡
4. 無差異屬性（Indifferent）：做不做使用者都不在意，通常是 PM 的自嗨功能
5. 反向屬性（Reverse）：做了反而惹人厭。例如：滿滿的蓋版廣告

關鍵動態

魅力屬性會隨時間「退化」— 昨天的魅力變成今天的期望、明天的必備。iPhone 第一代的觸控螢幕曾是魅力屬性，如今是必備。這意味著你需要持續尋找新的魅力點。

來源與歷史

• 1959：Frederick Herzberg 提出「雙因素理論」（保健因子 vs 激勵因子），成為 Kano 的理論基礎
• 1984：東京理科大學教授狩野紀昭正式發表 Kano 模型，將品管領域的滿意度研究帶入產品設計
• 2000s：隨著 SaaS 和行動 App 興起，Kano 成為產品經理標配工具
• 2013：Dan Olsen 在《The Lean Product Playbook》中將 Kano 整合進精益產品流程，推動更廣泛採用

真實案例：線上清潔服務的 GPS 大翻車

一個主打「線上預約清潔服務」的新創團隊，原本打算花 2 個月開發「清潔員即時 GPS 追蹤功能」，以為這會是魅力屬性。後來他們跑了一次 Kano 問卷（150 位活躍使用者），發現：

• 必備屬性：清潔員準時到達、不亂加價、打掃品質穩定
• 無差異屬性：GPS 追蹤 — 多數使用者預約後就去上班了，根本不想一直盯著 App
• 魅力屬性：打掃完後，App 收到一張「打掃前後對比照」加上一個「清潔完成報告」

團隊立刻砍掉 GPS 開發，改為要求清潔員拍照上傳。開發成本從 2 個月降到 3 天，但當月 App Store 的 5 星好評率飆升了 35%。

使用步驟

Step 1：挑選待評估功能

從 Backlog 中抓出 10-15 個有爭議或待評估的功能。太多會讓問卷太長，受訪者放棄。

Step 2：設計正反向問卷

每個功能問兩題：

• 正向題：「如果有這功能，你覺得如何？」
• 反向題：「如果沒有這功能，你覺得如何？」

選項固定五個：很喜歡 / 理所當然 / 無所謂 / 勉強接受 / 很不喜歡

Step 3：發送與回收

找至少 50-100 位真實目標受眾填寫。樣本數太少會被極端值帶偏。

Step 4：交叉比對歸類

根據正反向答案的交叉點，把每個功能歸類到五種屬性。可以用 Kano 評估表（正向 × 反向的 5×5 矩陣）自動對應。

Step 5：排定優先級

永遠先做「必備」→ 接著投資「期望」→ 最後挑 1-2 個「魅力」作為行銷亮點。無差異和反向直接從路線圖中移除。

這樣做 vs 避免這些

這樣做

• 定期重新評估 — 屬性會隨時間變化，至少每半年做一次
• 搭配量化數據 — Kano 告訴你「做不做」，搭配 RICE 告訴你「先做哪個」
• 將結果視覺化 — 做成一張大圖讓全團隊看到，比 Excel 表更有溝通力
• 問卷設計要口語化 — 使用者看不懂產品術語

避免這些

• 不要把 Kano 問卷當唯一真理 — 受訪者想像不出不存在的創新體驗（汽車 vs 更快的馬）
• 不要把功能描述得太抽象 — 「更好的體驗」沒人知道你在問什麼
• 不要只做一次就當成定論 — 市場和使用者期望會變
• 不要用內部員工當受訪者 — 他們的認知跟真實使用者不同