Модель Кано (Kano Model)

Для каждой функции задают функциональный и дисфункциональный вопрос: как человек относится к наличию функции и как — к её отсутствию. Комбинация ответов помогает классифицировать feature.

1. Выберите конкретный сегмент: категории могут отличаться между сегментами.
2. Проведите Kano survey или customer interviews.
3. Классифицируйте features.
4. Добавьте cost, strategic fit и evidence.
5. Используйте Kano как один input в prioritization, а не автоматический roadmap.

Attractive features со временем могут стать Performance, а затем Must-be. То, что когда-то удивляло клиента, превращается в baseline ожидание.

Модель Кано (Kano Model). Понять, какие характеристики продукта обязательны, улучшают опыт или приятно удивляют. Применяйте когда нужно согласовать предложение с ценностью для клиента и коммерческой моделью. Основные показатели: удовлетворённость; внедрение; удержание; приоритет разработки. Рабочий инструмент: Конструктор Модель Кано.

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

• приоритетный сегмент и сценарий использования;
• задача клиента и альтернативы;
• экономика предложения;
• конкурентные характеристики;
• критерий успеха изменения.

1. Отделите факт от предположения. Всё, что не подтверждено данными, пометьте как гипотезу.
2. Сравните варианты между собой. Один результат редко имеет смысл без альтернативы или baseline.
3. Найдите главный рычаг. Не пытайтесь одновременно исправлять все найденные проблемы.
4. Определите действие. У результата должен появиться владелец, срок и конкретное изменение.
5. Назначьте проверку. Заранее зафиксируйте показатель, период и условие, при котором решение пересматривается.

B2B-продукт хочет добавить AI-функцию, но исследование показывает, что клиенты сильнее раздражены нестабильной интеграцией и непрозрачными статусами. Сначала исправляются базовые свойства, затем усиливаются performance-функции и только после этого добавляются delighters.

Этот сценарий показывает важную границу: фреймворк сам по себе не создаёт результат. Его задача - сделать логику выбора прозрачной. Результат появляется после изменения предложения, процесса, распределения ресурсов, коммуникации или коммерческого действия и последующей проверки фактом.

• удовлетворённость
• внедрение
• удержание
• приоритет разработки.

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

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

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

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

• Value Proposition Canvas
• JTBD
• RICE

• Product Discovery
• Concept Test
• Willingness to Pay