Kano-модель: как использовать в продукте

Зачем нужна Kano-модель

Базовая боль продакта: команда хочет делать классные «вау-фичи», а пользователи разочарованы тем, что у вас нет элементарного поиска. Kano-модель ровно про это — не все фичи равны, и одна и та же штука может вызвать эйфорию у одного и пустоту у другого.

Модель придумал японец Норияки Кано в 1980-х, изначально для производства. Идея простая: нанесите фичи продукта на оси «насколько фича реализована» × «удовлетворённость пользователя» — и увидите, что разные фичи ведут себя по-разному.

Какие-то фичи нельзя игнорировать (без них продукт ломается), какие-то скучные, но повышают NPS, а какие-то — вау-эффект из ничего. Kano помогает не путать эти три категории.

Пять категорий фич

Must-be (обязательные)

Без них продукт не работает. Их наличие никого не радует, но отсутствие бесит. Поиск в каталоге, кнопка «выйти из аккаунта», работающая оплата.

Performance (одномерные)

Чем больше — тем лучше. Скорость загрузки, объём контента, точность поиска. Удовлетворённость растёт линейно с уровнем фичи.

Attractive (восторгающие)

Их отсутствие никого не расстраивает (никто их не ждал), но наличие вызывает «вау». Пасхалки, неожиданные жесты, классная анимация. Со временем превращаются в performance, а потом в must-be — пользователь привыкает.

Indifferent (безразличные)

Пользователю всё равно. Часто туда падают фичи, которые делает команда «по приколу» или потому что «у конкурентов есть».

Reverse (обратные)

Чем больше — тем хуже. Слишком много нотификаций, навязчивая геймификация, реклама везде. Команда добавляет — пользователь злится.

Kano-опрос: как устроен

Чтобы понять, в какую категорию попадает фича, проводят Kano-опрос. На каждую фичу пользователю задают два вопроса — функциональный и дисфункциональный.

• Функциональный: «Как вы себя почувствуете, если в продукте появится X?»
• Дисфункциональный: «Как вы себя почувствуете, если X в продукте не будет?»

Варианты ответа стандартные (5 пунктов):

1. Мне это понравится.
2. Я ожидаю, что так и должно быть.
3. Мне всё равно.
4. Я могу с этим жить.
5. Мне это не понравится.

Сочетание ответов попадает в матрицу Kano и даёт категорию. Например: «понравится» на функциональный + «не понравится» на дисфункциональный = performance. «Понравится» + «всё равно» = attractive.

Минимум 30 ответов на сегмент, иначе случайный шум. Лучше 100+.

Пример классификации

Прогнали 5 потенциальных фич Telegram-приложения через Kano-опрос на 120 пользователях:

Фича	Категория	Что делать
Push-напоминания о тренировке	Performance	Делать и калибровать частоту
Тёмная тема	Must-be	Делать срочно, на это жалуются
Личный AI-ментор с разбором ошибок	Attractive	Хороший потенциал на «вау», но рискованно по эффорту
Лиги с рейтингом игроков	Indifferent	Не приоритет, аудитории всё равно
Принудительная серия из 30 дней без пропусков	Reverse	Не делать, бесит пользователей

Kano-модель не говорит, какую фичу делать первой. Она говорит, какие точно нельзя игнорировать (must-be), какие принесут «вау» (attractive) и от каких лучше отказаться (reverse, indifferent).

Как использовать результат

• Must-be делайте раньше всего. Это гигиена. Их отсутствие убивает retention.
• Performance — основной двигатель. Сюда вкладывайте основное время, но осознанно: что именно из performance улучшает ключевую метрику.
• Attractive — раз в квартал. Маленькие приятные фичи раз в 1–2 месяца поддерживают «вау-фактор» и помогают сарафану.
• Indifferent — выкинуть из бэклога. Звучит обидно, но если пользователям всё равно — зачем тратить ресурс?
• Reverse — повод глубже копнуть. Возможно, фича нужна не всем, а конкретному сегменту, и её надо прятать.

Kano хорошо комбинируется с RICE: сначала отсеивайте reverse и indifferent, потом считайте RICE для оставшихся.

Частые ошибки

• Опрос на маленькой выборке. С 10–15 ответами получите статистический шум, а не категорию.
• Без сегментации. Для одной аудитории фича — must-be, для другой — indifferent. Если смешать в одну кучу, увидите усреднённую кашу.
• Категория навсегда. Attractive со временем становится performance, а performance — must-be. Опрос актуален 6–12 месяцев, не дольше.
• Игнор reverse-фич. Если фича попала в reverse — не «давайте уговорим пользователей», а «как минимум сделайте опциональной».
• Только Kano. Модель показывает восприятие, но не охват. Без аналитики и Reach получите красивые категории, которые не помогут с приоритизацией бюджета.

Связанные темы

• JTBD framework: как применять
• RICE приоритизация
• HEART framework Google
• MoSCoW приоритизация

FAQ

Сколько фич можно прогнать через один Kano-опрос?

Обычно 5–10. Больше — устаёт респондент, ответы становятся шумом.

Какую выборку нужно набрать?

Минимум 30 на сегмент, лучше 100+. На крупных продуктах делают по 200–300 на ключевые фичи.

Можно ли использовать Kano для B2B?

Можно, но опросы там длиннее и требуют интервью с лицами, принимающими решения. На малых выборках Kano в B2B особенно шумный.

Чем Kano отличается от RICE?

Kano про восприятие фичи пользователем, RICE про охват и затраты. Kano помогает решить «делать ли», RICE — «когда делать».

Как часто пересматривать категории?

Раз в 6–12 месяцев или после крупного релиза. Восприятие быстро смещается: вчерашняя attractive завтра становится must-be.

Что делать с фичей, которая попала в indifferent?

Либо переформулировать гипотезу (возможно, для конкретного сегмента она важна), либо отказаться. Indifferent — самый честный аргумент против фичи.

---

Тренируйте продуктовое мышление и фреймворки — откройте Карьерник с 1500+ вопросами для собесов на продакта и аналитика.