Модель Кано: как понять, какие фичи радуют, а какие только ожидают

Что такое модель Кано простыми словами

Японский профессор Нориаки Кано в 1980-х заметил, что связь между качеством фичи и удовлетворённостью клиента не всегда линейна. Одни характеристики продукта клиент считает само собой разумеющимися и просто не замечает, пока они есть, зато сильно злится, если их нет. Другие — чем лучше, тем довольнее клиент, пропорционально. Третьи клиент вообще не ждёт, и их наличие вызывает искреннее удивление и восторг.

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

Пять категорий модели Кано

Прежде чем классифицировать конкретные фичи своего продукта, полезно свериться с общей картой категорий и типовыми примерами для каждой.

Важный нюанс: категория — не свойство фичи вообще, а свойство фичи для конкретного сегмента аудитории. То, что для новичка — Attractive, для опытного пользователя может быть Indifferent, а для другого сегмента — даже Reverse.

Как провести исследование Кано

Классический метод — парный опрос: на каждую фичу задают два вопроса, функциональный и дисфункциональный. Такой формат сложнее и длиннее, чем обычная анкета, поэтому его обычно проводят точечно — раз в полгода-год, а не как постоянный инструмент сбора обратной связи, и совмещают с другими способами понять клиента, например разбором его задач через JTBD.

Функциональный вопрос:
«Как вы отнесётесь, если продукт будет иметь [фича]?»

Дисфункциональный вопрос:
«Как вы отнесётесь, если продукт НЕ будет иметь [фича]?»

Варианты ответа для обоих:
Мне нравится / Это ожидаемо / Мне всё равно /
Могу смириться / Мне не нравится

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

Как считать результаты: коэффициенты удовлетворённости

CS (Satisfaction) = (Attractive + Performance) / Всего ответов
DS (Dissatisfaction) = −(Must-be + Performance) / Всего ответов

CS показывает потенциал роста удовлетворённости при добавлении фичи — чем ближе к 1, тем сильнее выигрыш. DS (обычно отрицательное число, ближе к −1 — сильнее) показывает риск недовольства при отсутствии фичи. Фичи с высоким DS по модулю — кандидаты в Must-be: их нельзя пропускать в разработке, даже если они не приносят восторга. Фичи с высоким CS и низким DS — хорошие кандидаты в Attractive, источник дифференциации от конкурентов.

Полезно наносить обе фичи на один график: по оси X — DS, по оси Y — CS. Тогда категории визуально группируются в квадранты, и команде проще на одном взгляде увидеть, где сосредоточены базовые ожидания, а где — потенциал для восторга, вместо того чтобы сравнивать десятки строк в таблице.

Пример применения для SaaS-продукта

Такая таблица сразу подсказывает, где искать баланс бэклога: закрыть Must-be без вопросов, выбрать одну-две Performance-характеристики для системного улучшения и поставить ставку на один яркий Attractive-элемент, который выделит продукт среди конкурентов. Прежде чем вкладываться в разработку Attractive-фичи, стоит быстро и дёшево проверить гипотезу на аудитории — например, через короткий HADI-цикл с прототипом или лендингом, а не сразу запускать полноценную разработку.

Ловушка времени: восторг превращается в норму

Это значит, что модель Кано нужно пересматривать регулярно, а не проводить один раз при запуске продукта. Источники восторга нужно искать постоянно — прошлогодний восторг клиента уже не удивляет и не выделяет продукт среди конкурентов. Классический пример из истории интернет-продуктов — онлайн-чат поддержки: когда-то он был почти магией и вызывал восторг, сегодня его отсутствие воспринимается как минус, а не наличие как плюс.

Как использовать модель в приоритизации бэклога

Модель Кано хорошо дополняет, но не заменяет численную приоритизацию.

• Must-be — вне очереди. Их отсутствие бьёт по базовому доверию к продукту сильнее любой другой фичи.
• Performance — оценивайте через ROI. Здесь уместна количественная приоритизация вроде ICE или RICE, чтобы выбрать, какую характеристику улучшать в первую очередь.
• Attractive — держите пайплайн идей. Не полагайтесь на одну гениальную фичу — ищите источники восторга регулярно, опираясь на реальные задачи клиента (JTBD), а не на догадки команды.
• Indifferent — вырезайте смело. Ресурсы на нейтральные фичи почти всегда лучше перенаправить в другую категорию.
• Reverse — проверяйте на реальных сегментах. Фича, которая раздражает одних, может быть важна для других — не убирайте её вслепую, сначала разберите, кто именно недоволен.

На практике модель Кано лучше всего работает в паре с количественной приоритизацией: она подсказывает, к какой категории отнести идею, а формула вроде ICE или RICE — в каком порядке её реализовать внутри этой категории.