CÔNG CỤ
Kano Model
Dùng khi: quyết định đầu tư vào tính năng nào — theo cách khách hàng cảm nhận, không phải theo cách team muốn build; đặc biệt hữu ích khi tranh cãi "làm đẹp thêm X hay thêm mới Y".
Cốt lõi: tính năng không bình đẳng — 5 loại theo quan hệ giữa mức đầu tư và độ hài lòng:
- Must-be (bắt buộc): có = đương nhiên, thiếu = tức giận. (App ngân hàng: bảo mật, không sập.) Đầu tư đến "đủ", thêm nữa không ai khen.
- One-dimensional (hiệu suất): càng nhiều càng hài lòng, tuyến tính. (Tốc độ, dung lượng, giá.) Đây là mặt trận cạnh tranh trực diện.
- Attractive (hấp dẫn): không có chẳng ai đòi, có thì "wow". Nguồn khác biệt hóa và truyền miệng.
- Indifferent (thờ ơ): có hay không khách chẳng quan tâm — dừng đầu tư.
- Reverse (ngược): thêm vào làm một nhóm khách khó chịu (quá nhiều tùy chọn, tính năng "thông minh" tự ý).
Quy luật trôi: attractive hôm nay → one-dimensional ngày mai → must-be năm sau (camera điện thoại, giao hàng nhanh). Phải đo lại định kỳ.
Cách dùng nhanh
- Với mỗi tính năng, hỏi khách 2 câu: "Cảm thấy thế nào nếu CÓ?" và "...nếu KHÔNG có?" (thang: thích / đương nhiên / trung lập / chịu được / khó chịu).
- Tra bảng phân loại Kano từ cặp trả lời → gắn nhãn tính năng.
- Chiến lược đầu tư: đủ 100% must-be → cạnh tranh có chọn lọc ở one-dimensional → chọn 1–2 attractive làm điểm nhấn → cắt indifferent/reverse.
Bẫy thường gặp
- Hỏi nội bộ thay vì hỏi khách — team luôn nghĩ tính năng mình làm là attractive.
- Dồn hết lực làm attractive khi must-be còn thủng (app hay ho nhưng crash → mọi điểm wow vô nghĩa).
- Phân loại một lần dùng mãi — quên quy luật trôi.
- Quên rằng các phân khúc khác nhau phân loại khác nhau: power user coi X là must-be, người mới coi là indifferent.
Nguồn: Module 7 (Kano trong bộ ưu tiên), Module 2 (Olsen dùng Kano xác định underserved needs). Liên quan: RICE - ICE - MoSCoW · Phân khúc khách hàng · MVP