Модель Кано

Общее #

• Назначение: классификация фичей по влиянию на удовлетворённость клиента; приоритизация на основе ожиданий.
• Аудитория: PM, UX-дизайнеры, маркетологи.
• Статус: устоявшийся (Noriaki Kano, 1984).
• Не путать с: MoSCoW (приоритизация по степени необходимости), RICE (числовая приоритизация), матрицей Value×Effort (визуальное сравнение «ценность — затраты»).

Модель Кано (Kano Model) — фреймворк классификации функций продукта по характеру их влияния на удовлетворённость клиента. Каждое свойство продукта относится к одной из категорий: базовые (must-be), ожидаемые (performance), вау-свойства (attractive), безразличные (indifferent) или обратные (reverse). Категория определяет роль свойства в продукте: безусловный минимум, поле конкуренции или инструмент дифференциации.

Ключевой вопрос модели — не «насколько свойство важно», а «как его наличие или отсутствие меняет удовлетворённость клиента». Эти вещи не совпадают: самое важное свойство продукта может вообще не давать удовлетворённости — оно лишь предотвращает недовольство.

Происхождение #

Модель предложена Нориаки Кано (Noriaki Kano), профессором Tokyo University of Science, в статье Attractive Quality and Must-Be Quality (1984), написанной с соавторами (Seraku, Takahashi, Tsuji). Кано исследовал связь между качеством продукта и удовлетворённостью клиента и эмпирически показал, что эта связь нелинейна и неоднородна: разные свойства вносят принципиально разный вклад в итоговое впечатление.

Работа опиралась на двухфакторную теорию мотивации Герцберга, где факторы удовлетворённости и факторы неудовлетворённости — это разные множества: гигиенические факторы (зарплата, условия) не мотивируют, но их отсутствие демотивирует. Кано перенёс эту логику на продукт: у продукта тоже есть «гигиенические» свойства, которые не радуют, но обязаны быть.

В 1993 году Berger и коллеги адаптировали метод для западной практики, добавив стандартизированный Kano-опрос и матрицу свёртки ответов — в этом виде модель вошла в инструментарий продуктовых команд и стала одним из классических фреймворков анализа ценности.

Модель применяется на разных этапах жизни продукта: при формировании MVP (какой минимум безусловен), при планировании релизов (куда идёт ресурс между базой, конкуренцией и дифференциацией), при анализе жалоб (почему удовлетворённость не растёт) и при позиционировании (чем именно гордиться в коммуникации). Аудитория модели — PM, UX-дизайнеры и маркетологи — использует одну и ту же классификацию для разных решений.

Удовлетворённость ≠ сумма свойств #

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

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

• базовое свойство, реализованное идеально, не даёт удовлетворённости — клиент его просто не замечает;
• вау-свойство, реализованное скромно, может вызвать восторг уже самим фактом существования;
• больше — не всегда лучше: у «обратных» свойств рост реализации снижает удовлетворённость.

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

Пять категорий свойств по Кано #

Классификация Кано выделяет пять категорий (в ранних версиях — три: базовые, ожидаемые, вау; две дополнительные добавлены для полноты картины ответов).

Базовые (Must-be / Basic) #

Свойства, которые клиент считает само собой разумеющимися. Их отсутствие или плохая реализация вызывает сильное недовольство, но наличие не воспринимается как достоинство — оно ожидается по умолчанию.

Классический пример из литературы о Кано: тормоза в автомобиле. Никто не покупает машину, потому что «у неё есть тормоза», но машина без тормозов — провальный продукт. В IT-продуктах базовые свойства — это вход в аккаунт, сохранность данных, работающая оплата, отсутствие ошибок на ключевом сценарии.

Базовые свойства часто называют hygiene factors — по аналогии с гигиеническими факторами Герцберга. Их роль в продукте — не повышать удовлетворённость, а устранять недовольство. Главная идея: «базовые» свойства не приносят удовлетворения, их отсутствие — убивает продукт. Инвестиции в них не создают ценности, а снимают риск; дефицитный ресурс на них тратится безусловно, но без иллюзий насчёт «добавленной ценности».

Ожидаемые (One-dimensional / Performance) #

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

Пример: расход топлива автомобиля — чем экономичнее, тем довольнее владелец; чем прожорливее, тем сильнее раздражение. В IT: скорость загрузки страниц, размер хранилища, число доступных интеграций, время ответа поддержки.

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

Вау-свойства (Attractive / Excitement / Delighters) #

Свойства, которых клиент не ожидает и не просит: их отсутствие не вызывает недовольства, а наличие вызывает восторг и удивление — «вау». Клиент обычно не называет их в исследованиях, потому что не задумывается о такой возможности.

Пример: дизайн кузова Tesla в момент выхода — люди не «ждали» именно этого, но увиденное меняло отношение к бренду целиком. В IT: неожиданно удобная мелочь, сюрприз в онбординге, функция, закрывающая боль, к которой клиент привык как к норме.

Вау-свойства — главный драйвер дифференциации и запоминаемости продукта: они дают непропорционально много удовлетворённости на единицу реализации и формируют истории, которые клиенты рассказывают другим. Но опираться только на них нельзя: вау без базовой функциональности не спасает.

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

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

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

Обратные / Сомнительные (Reverse / Questionable) #

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

Questionable — отдельная пометка противоречивых данных, когда ответы клиента на парные вопросы не складываются в осмысленную категорию (см. раздел об опросе): это не свойство продукта, а признак проблемы в формулировке вопроса.

Сводная таблица #

График Кано #

Модель обычно изображается двумерной диаграммой. По горизонтальной оси — степень реализации свойства: от недостаточной (слева) до достаточной (справа). По вертикальной — удовлетворённость клиента: от сильного недовольства (внизу) до восторга (вверху). Каждая категория Кано описывается своей кривой на этой плоскости:

       восторг ─                                                     AAA
                │                                                 AAAAP
                │                                             AAAAP
                │                                       AAAAAAP
                │                                 AAAAAAPPP
                │                          AAAAAAA PPPP
                │               AAAAAAAAAAA    PPPP
    нейтрально ─AAAAAAAAAAAAAAA·  ·  ·  · PPPP·  ·  ·  · BBBBBBBBBBBBBBB
                │                      PPPP    BBBBBBBBBBB
                │                  PPPP BBBBBBB
                │              PPPPBBBBB
                │          PPPPBBB
                │      PPPPB
                │  PPPPB
  недовольство ─PPB
                └────────────────────────────────────────────────────────
                недостаточно                                  достаточно

Кривые: A — вау-свойства (attractive), P — ожидаемые (performance), B — базовые (must-be)
Ось X — степень реализации свойства, ось Y — удовлетворённость клиента

Геометрия кривых отражает суть категорий:

• Базовые (B) — кривая начинается в зоне сильного недовольства и с ростом реализации асимптотически выходит на нейтральный уровень, никогда не поднимаясь выше: сколько бы ресурса ни вложили, максимум — «нормально». Вложения в базовые свойства покупают не удовлетворённость, а отсутствие недовольства.
• Ожидаемые (P) — прямая линия через центр координат: удовлетворённость растёт линейно с улучшением реализации и линейно падает с ухудшением. Единственная категория, где «сколько вложили — столько получили».
• Вау (A) — зеркальна базовой: при недостаточной реализации клиент остаётся на нейтральном уровне (он этого свойства и не ждал), при полной — кривая круто уходит вверх, в зону восторга.

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

Kano-опрос #

Главный метод отнесения свойства к категории — стандартизированный Kano-опрос. Без него категории — гадание: команда склонна проецировать собственные представления («конечно, это вау!») на клиента, а реальное распределение ожиданий известно только клиенту.

Парные вопросы #

Каждое свойство проверяется парой вопросов:

• Функциональный (functional): «Если свойство X реализовано, как вы себя чувствуете?»
• Дисфункциональный (dysfunctional): «Если свойство X НЕ реализовано, как вы себя чувствуете?»

На каждый вопрос респондент выбирает один из пяти вариантов ответа:

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

Пара ответов сворачивается в категорию. Логика: базовое свойство даёт «должно быть» на функциональный вопрос и «не нравится» — на дисфункциональный; вау-свойство — «нравится» и «всё равно»; ожидаемое — «нравится» и «не нравится».

Матрица свёртки ответов #

Комбинация ответов определяется по таблице (строки — ответ на функциональный вопрос, столбцы — на дисфункциональный):

Обозначения: M — must-be (базовое), O — one-dimensional (ожидаемое), A — attractive (вау), I — indifferent (безразличное), R — reverse (обратное), Q — questionable (противоречивый ответ: например, «нравится и когда есть, и когда нет» — данные отбраковываются).

Анализ результатов #

Опрос проводится на выборке клиентов (обычно 30–50 респондентов на сегмент). Для каждого свойства получается распределение ответов по категориям, которое анализируется двумя способами:

• Мода (mode). Итоговой категорией свойства считается самая частая в распределении. Если мода — M, свойство базовое; если I — не делать.
• Частотный анализ. Мода без контекста обманчива: «40% M, 35% A, 25% I» и «40% M, 5% A, 5% I, 50% Q» — разные ситуации. Смотрят на разброс, долю противоречивых ответов (высокий Q — сигнал о плохой формулировке вопроса) и на сегменты: распределение может складываться из двух разных аудиторий с разными ожиданиями.

Для тонкого анализа Berger предложил коэффициенты влияния:

Better = (A + O) / (A + O + M + R)      — насколько свойство повышает удовлетворённость
Worse  = (O + M) / (A + O + M + R)      — насколько его отсутствие снижает удовлетворённость

Оба коэффициента меняются от 0 до 1 (Worse традиционно записывают со знаком минус) и позволяют расположить свойства на плоскости «влияние на удовлетворённость × влияние на недовольство» — фактически на эмпирической версии графика Кано.

Типичные ошибки при проведении опроса #

Качество Kano-опроса определяется методологической гигиеной; самые частые ошибки:

• Решение вместо проблемы в формулировке. Свойство в вопросе сформулировано как реализация («панель с фильтрами слева»), а не как ценность («быстрый поиск нужного файла»). Клиенты отвечают про интерфейс, который видели, а не про потребность — категории получаются случайными.
• Наводящие формулировки. «Вам бы понравилось удобное автозаполнение?» — вопрос уже содержит оценку. Формулировки обоих вопросов пары должны быть нейтральными и отличаться только наличием свойства.
• Смешение сегментов в одной выборке. Усреднение ожиданий разных аудиторий размывает моды и маскирует реальные категории; каждый сегмент анализируется отдельно.
• Слишком длинный опрос. Десятки парных вопросов утомляют респондента, качество ответов к концу падает, растёт доля «всё равно» — артефакт усталости, который выглядит как indifferent. Рабочий максимум — 10–15 свойств в одном опросе.
• Мнимая точность моды. Мода «34% против 31%» — это не победа категории, а неразличимое распределение; такие свойства выносятся на уточняющее исследование или дополнительную выборку.

Жизненный цикл фичи по Кано #

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

вау (attractive) ──→ ожидаемая (performance) ──→ базовая (must-be)
   восторг              поле конкуренции            «должно быть»

Хрестоматийный пример — сенсорный экран в смартфонах. В 2010 году мультитач-экран был вау-свойством: им восхищались, его демонстрировали друзьям, он продавал устройство. К середине 2010-х он стал ожидаемым — экраны сравнивали по чувствительности и качеству картинки. К 2024 году сенсорный экран — базовое свойство: его отсутствие делает устройство «сломанным», но никто не выбирает телефон «потому что у него сенсорный экран».

Тот же путь проходят Wi-Fi в отелях (вау в 2000-х — базовое свойство сегодня), интернет-банкинг, автоплатежи, тёмная тема интерфейсов. Скорость деградации вау зависит от конкуренции: чем быстрее конкуренты копируют свойство, тем быстрее оно сползает влево по циклу.

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

Практические следствия жизненного цикла:

• Дифференциация — не состояние, а процесс. Вчерашнее конкурентное преимущество сегодня — гигиена; продукт обязан постоянно генерировать новые вау-свойства, иначе дифференциация истощается.
• Roadmap обязан учитывать дрейф категорий. Свойство, текущая категория которого — вау, через год потребует ресурса уже как ожидаемое; это надо закладывать в план, а не «сделать и забыть».
• База растёт автоматически. Сумма обязательств продукта только увеличивается: каждое сползшее в must-be свойство добавляется к безусловному минимуму, который нужно поддерживать всегда.

Применение в продуктовом управлении #

Приоритизация по категориям #

Модель Кано не даёт числового ранга, но задаёт разные логики решения для разных категорий:

• Базовые — безусловный минимум. Не обсуждаются и не конкурируют с фичами: их дефицит — риск для всего продукта. Вопрос не «делать ли», а «насколько полно к следующему релизу».
• Ожидаемые — поле конкуренции. Инвестиции пропорциональны конкурентному ландшафту: решение о глубине реализации принимается относительно того, что дают альтернативы (подробнее — конкурентный анализ). Перегнать всех по всем осям невозможно — выбираются оси.
• Вау — дифференциация. Инвестируются избирательно и стратегически: вау-свойство — носитель позиционирования, оно должно соответствовать тому, за что клиент выбирает продукт, а не просто «приятно удивить».
• Безразличные — не делать. Прямое назначение модели: остановить инвестиции до того, как они сделаны.
• Обратные — убрать. Свойство, которое раздражает клиента своим наличием, — кандидат на удаление или на переосмысление.

Пример: категоризация бэклога трекера задач #

Условная команда трекера задач прогнала через Kano-опрос шесть свойств-кандидатов и получила расклад:

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

Кано в маркетинге и позиционировании #

Для маркетинга категоризация Кано — это карта того, чем можно и нельзя гордиться в коммуникации:

• Базовые свойства нельзя продавать как достоинство. «У наших автомобилей есть тормоза» — слабое позиционирование: клиент и так считает это нормой, а выделение базового в рекламу размывает сообщение.
• Ожидаемые свойства — язык сравнения. Здесь работают цифры, рейтинги и «лучше, чем у X»: клиент сам сравнивает продукты по этим осям.
• Вау-свойства — ядро сообщения. Восторг — то, что клиент пересказывает другим; вау-свойство даёт историю для кампании и для «сарафанного радио».

Игнорирование этой логики порождает типовую ошибку коммуникации: продукт хвалится базовыми свойствами («у нас есть приложение!»), а дифференцирующие вау остаются за кадром.

Связь с Discovery, CustDev и JTBD #

Категории Кано не выводятся логически и не назначаются экспертно — они измеряются. Место модели — на этапе Discovery: Kano-опрос — один из инструментов UX-исследований наряду с глубинными интервью, а глубинные интервью по методике Customer Development (статья готовится) дают фактуру для выбора свойств, которые стоит прогнать через опрос. JTBD (статья готовится) отвечает на смежный вопрос «какую работу клиент нанимает продукт выполнить» — Кано дополняет его вопросом «как свойства этой работы влияют на удовлетворённость».

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

Кано и другие методы приоритизации #

Модель Кано отвечает на вопрос «что важно клиенту и почему», а RICE — «за что браться сначала с учётом затрат». Они не конкурируют, а дополняют друг друга: категория Кано у инициативы уточняет природу её ценности и делает оценку Impact в RICE обоснованнее; связка «Кано → RICE» — типовая цепочка от понимания ценности к ранжированию. Аналогично MoSCoW: must-be-свойства естественно становятся Must have в релизе, но MoSCoW работает с любой степенью обязательности, а Кано объясняет, откуда обязательность берётся.

Важно не дублировать моделью Кано матрицу Value×Effort (/docs/product-managment/value-effort-matrix/): это разные инструменты. Кано не учитывает затраты вообще — в этом её ключевое отличие: она классифицирует свойства по ожиданиям клиента, а не по экономике «ценность против усилий». Вау-свойство может быть бесценным для дифференциации и при этом неподъёмно в реализации — Кано этого не увидит, поэтому после категоризации необходим отдельный Effort-анализ (как в RICE или ICE / WSJF).

Типовое место модели в процессе: категоризация Кано → оценка Effort → приоритизация (RICE/MoSCoW) → roadmap.

Плюсы #

Сильные стороны модели следуют из её центральной идеи — смотреть на продукт глазами клиента, а не команды.

Фокус на клиенте, а не на мнении команды #

Категория свойства определяется не спором на планировании, а ответами клиентов. Это сдвигает дискуссию из области вкусов («мне кажется, это вау») в область данных, аналогично тому, как RICE сдвигает спор о важности в область проверяемых оценок.

Категоризация как основа решений #

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

Показывает, что не делать #

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

Объясняет парадокс «сделали много, а недовольны» #

Модель даёт язык для типовой болезненной ситуации: команда закрыла кучу пунктов, а satisfaction (например, NPS или CSAT) не растёт. Ответ Кано: закрывались базовые свойства — они и не должны поднимать удовлетворённость; для её роста нужны ожидаемые и вау. Обратный парадокс — «продукт скромный, но все в восторге» — объясняется наличием вау при достаточной базе.

Минусы и риски #

Ограничения модели известны и в большинстве управляемы процессом; часть из них — фундаментальные.

Статичная модель про динамичный объект #

Категория свойства фиксирует ожидания сегмента на момент опроса, а ожидания меняются (жизненный цикл фичи). Результат Kano-опроса устаревает быстрее, чем кажется: «вау» конкурента мгновенно сдвигает планку. Лечится регулярностью — опрос повторяется циклично, а не проводится один раз.

Трудоёмкость опроса #

Корректная категоризация требует парных вопросов на каждое свойство и выборки от нескольких десятков респондентов на сегмент. Для длинного списка кандидатов опрос получается дорогим, а его качество напрямую зависит от формулировок (высокая доля Q-ответов — брак исследования). На практике Кано применяют к короткому списку свойств, отобранному на предыдущих этапах Discovery.

Категории зависят от сегмента #

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

Не учитывает затраты #

Кано намеренно игнорирует effort: модель ничего не говорит о цене реализации свойства. Дорогая базовая фича и дешёвая базовая фича получают одинаковое «безусловно делать», хотя решения очевидно разные. Поэтому Кано не заменяет приоритизацию, а лишь готовит для неё вход: после категоризации обязателен анализ затрат теми же RICE, ICE/WSJF или матрицей Value×Effort.

«Вау» вырождается в «базовое» #

Главный драйвер дифференциации — самый недолговечный актив: каждое вау-свойство со временем сползает в must-be и превращается в вечное обязательство поддержки. Дифференциация требует постоянной генерации новых вау — это не разовая инвестиция, а непрерывный процесс, у которого нет «точки, где можно остановиться».

Связанные материалы #

• Метод MoSCoW — категориальная приоритизация по степени обязательности; фиксирует объём релиза после категоризации Кано.
• RICE — числовая приоритизация с учётом трудозатрат; типовая пара к Кано на шаге ранжирования.
• Discovery-процесс — этап, на котором проводится Kano-опрос и отбираются свойства для категоризации.
• UX-исследования — методологический контекст Kano-опроса.
• NPS и CSAT — метрики удовлетворённости, динамику которых объясняет категоризация по Кано.
• Roadmap — куда встраиваются решения по категориям с учётом жизненного цикла фичей.
• Матрица Value×Effort, ICE / WSJF, Customer Development, JTBD — альтернативные и дополняющие методы приоритизации и исследований.

Первоисточники #

• Kano N., Seraku N., Takahashi F., Tsuji S. (1984). Attractive Quality and Must-Be Quality. Journal of the Japanese Society for Quality Control. — оригинальная статья: классификация свойств и нелинейная связь качества и удовлетворённости.
• Berger C. et al. (1993). Kano’s Method for Measuring Customer Satisfaction. Center for Quality Management Journal. — западная адаптация: парный опрос, матрица свёртки, better/worse-коэффициенты.
• Miklos I. (2015). A Modern Kano Approach. — современная практическая интерпретация метода: сценарии применения и анализ данных опроса.
• Cagan M. (2017). Inspired: How to Create Tech Products Customers Love. — место модели Кано в продуктовом арсенале и связь с продуктовой стратегией.