Модель Kano для продакт-менеджера
Содержание:
Что такое модель Kano
Модель Kano — фреймворк классификации фичей по тому, как они влияют на удовлетворённость пользователей. Разработана Noriaki Kano в 1980-х. Главная идея — не все фичи дают одинаковый прирост к satisfaction.
На собесе PM Kano встречается реже, чем RICE и ICE, но senior-PM должен уметь объяснить разницу между must-be и delighter фичами.
5 категорий фичей
1. Must-be (Базовые)
Без них продукт неприемлем. Их наличие воспринимается как должное.
Пример: пароль работает корректно. Когда работает — никто не радуется. Когда не работает — все возмущены.
2. Performance (Линейные)
Чем больше — тем лучше. Удовлетворённость растёт пропорционально качеству.
Пример: скорость загрузки страницы. 200ms лучше, чем 500ms. 50ms ещё лучше.
3. Delighter (Восхищающие)
Фичи, которых пользователь не ожидал. Их отсутствие не разочаровывает, но наличие радует.
Пример: бесплатная сладость с заказом еды. Если её нет — никто не жалуется. Если есть — приятный сюрприз.
4. Indifferent (Безразличные)
Фичи, которые пользователь не замечает. Тратить на них ресурсы — впустую.
Пример: скрытое улучшение производительности кода, которое не отражается на скорости приложения.
5. Reverse (Обратные)
Фичи, которые ухудшают опыт для части пользователей. Чем больше — тем хуже.
Пример: всплывающие push-уведомления для пользователей, ценящих минимализм.
Опросник Kano
Для классификации фичи через данные используют двойной вопрос (functional + dysfunctional):
Functional: «Как вы отнесётесь, если фича X будет в продукте?» Dysfunctional: «Как вы отнесётесь, если фичи X не будет в продукте?»
Варианты ответа:
- Мне нравится
- Я ожидаю этого
- Мне всё равно
- Я могу с этим жить
- Мне это не нравится
Сочетание ответов даёт категорию фичи.
Анализ результатов
Матрица Kano:
| Functional ↓ / Dysfunctional → | Like | Expect | Neutral | Live | Dislike |
|---|---|---|---|---|---|
| Like | Q | A | A | A | O |
| Expect | R | I | I | I | M |
| Neutral | R | I | I | I | M |
| Live | R | I | I | I | M |
| Dislike | R | R | R | R | Q |
Где: M = Must-be, O = Performance, A = Attractive (Delighter), I = Indifferent, R = Reverse, Q = Questionable.
Самые ценные ячейки — A (delighter, growth) и M (must-be, retention).
Пример: маркетплейс
Команда маркетплейса хочет приоритезировать 4 фичи. Опрос 200 покупателей даёт:
- Подтверждение заказа на email — Must-be (90%)
- Отслеживание заказа в реальном времени — Performance (linear satisfaction)
- Подарок к заказу при первой покупке — Delighter
- Анимированные emoji в подтверждении — Indifferent
Решение: must-be закрыть первыми (если ещё нет). Performance улучшить. Delighter добавить, если ресурсы. Indifferent не трогать.
Когда использовать
- Большой бэклог с разнотипными фичами
- Фокус на customer satisfaction
- Решение «что делать первым» не очевидно по другим фреймворкам
- Анализ конкурента (что у них Must-be, что Delighter)
Kano не заменяет RICE. Используется параллельно.
Частые ошибки
Считать всё Delighter'ами. «Эта фича обрадует пользователей!» — обычно нет. Реально delighter — редкость.
Опрашивать без сегментации. Junior юзер и power-юзер ценят разное. Делайте опрос внутри одного сегмента.
Игнорировать со временем меняющуюся категорию. То, что было delighter (бесплатная доставка), со временем стало Must-be. Kano-категории должны переобследоваться раз в год.
Опрос с маленькой выборкой. Меньше 100 ответов на сегмент — ненадёжно.
FAQ
Сколько фичей сразу классифицировать в одном опросе?
5-10 максимум. Больше — респонденты устают, качество падает.
Это официальная информация?
Нет. Статья основана на работах Noriaki Kano и индустриальных практиках.