Хабр, привет! Мы в команде маркетинговых и UX-исследований МТС помогаем продуктовым командам проверять гипотезы и ищем ответ на вопрос: будут ли востребованы новые продукты, функции и сервисы? В том числе оцениваем актуальность технологий и возможностей, которых еще нет.
На практике нужно решить, в какие инициативы стоит инвестировать, а какие отсеять на стадии Discovery. Задача ответственная, и инструмент нужен надежный. Когда мы только начинали проверять инновационные решения, то обнаружили, что привычные инструменты приоритизации с задачей не справляются. С этим нужно было что-то делать.
В посте расскажу, почему так происходит и какой подход мы изобрели, а теперь успешно используем для решения подобных задач.
Как мы поняли, что «классика» не справляется с инновациями
Когда несколько лет назад мы впервые занялись оценкой инновационных решений, то начали с классических инструментов, которые часто используем для оценки тарифов и девайсов, — модели Кано и MaxDiff. На привычных задачах они работают стабильно, но в случае с оценкой инноваций результаты нас довольно быстро разочаровали. При этом каждая методология — по-своему.
Модель Кано
Подробнее о том, как работает и применяется модель, можно почитать в статье, а я предлагаю посмотреть на результаты нашего исследования функциональности умных очков:
На схеме видно, что возможную функциональность очков респонденты оценили как желаемую или безразличную. Что это значит? Да почти ничего. Мы можем лишь сказать: от новой технологии на старте ожидают многого и ни одна из возможностей не удивит пользователей.
Второй пример — оценка возможностей ИИ-терапевта. Две недели работы, а итоговый вывод сводится к общему «человеку нужен человек». Исследование не добавило понимания, какие именно функции стоит развивать. Модель Кано показала настроение аудитории, но не помогла приоритизировать конкретные сценарии.
Почему так происходит? Модель опирается на ретроспективный опыт. Пользователи легко ответят, какие характеристики считают обязательными, а какие вызовут у них вау-эффект, но только когда речь идет о привычных вещах — например, тарифах связи, банковских приложениях или доставке еды.
Стоит выйти в зону непривычного — ИИ-терапевт, AR-гаджет — и модель перестает работать. Когда у респондента нет опыта использования, ему сложно отделить реальную потребность от любопытства.
MaxDiff
MaxDiff работает иначе: респонденту показывают небольшие наборы из нескольких функций и в каждом из них просят выбрать самую важную и самую неважную. После серии таких выборов алгоритм рассчитывает итоговый рейтинг всех вариантов. Метод отлично ранжирует список, но есть одна загвоздка: MaxDiff измеряет относительную привлекательность функций внутри заданного списка, а респондент при этом выбирает лучшее и худшее в наборе, где все варианты ему безразличны.
В итоге модель покажет, какие из возможных функций лучшие — только дело в том, что все эти функции на самом деле пользователям могут быть не нужны.
Получается, что Кано и MaxDiff дают ложноположительные сигналы, когда речь идет о новом опыте. Привычные методы не работают в случае с инновациями, поэтому мы и решили разработать свой.
Что придумали для оценки инноваций
Столкнувшись с ограничениями существующих фреймворков, мы разработали собственный подход. Внутри команды называем его методом Колмакова — в честь автора, то есть меня (да, я сам улыбаюсь названию, но оно прижилось).
Ключевая идея в том, чтобы сменить точку отсчета. Теперь мы просим пользователей оценить не сами новые решения, которые они никогда не пробовали, а ситуации, в которых они могут пригодиться. Даже если у респондента нет опыта взаимодействия с продуктом, у него почти наверняка есть опыт переживания проблемы, которую продукт может решить. А в своих проблемах каждый — эксперт.
Методологически подход перекликается с Outcome-Driven Innovation (ODI) Энтони Ульвика и Opportunity Gap Джеймса Калбаха. Все три метода смещают фокус исследования с решений на неудовлетворенные потребности пользователя. Разница в том, что Ульвик и Калбах оценивают желаемые результаты — а чтобы их сформулировать, нужна отдельная фаза с глубинными интервью и выверенными формулировками в духе «минимизировать время на X». Мы же оцениваем проблемные случаи из жизни респондента напрямую.
Подготовка сводится к тому, что мы формулируем вопросы не про функцию, а про возможную проблему, — несколько часов работы вместо отдельной исследовательской фазы с интервью. Такой простой количественный скоринг занимает пару дней. Это делает метод пригодным для ранней стадии Discovery, когда нужно быстро проверить десятки гипотез.
Как работает Метод Колмакова
Рассмотрим на примере. Допустим, нам нужно оценить ИИ-ассистента, который может подключаться к телефонному разговору. Он умеет:
делать синхронный перевод
искать информацию в интернете
распознавать мошенников
Шаг 1. Формулируем ситуации
Описываем случаи, в которых может пригодиться наша фича: каждую функцию переносим из плоскости решений в плоскость возникающих проблем. В итоге получается вот такой комикс с вполне реальными ситуациями из жизни:
Шаг 2. Проводим опрос
Задаём респондентам три вопроса о каждой ситуации. Каждый из них отсекает свой тип продуктового риска.
1. «Сталкиваетесь ли вы с такой ситуацией?» — проверяем охват.
Варианты ответа: «да» или «нет». Этим вопросом мы отсекаем продукты-галлюцинации. Если ситуация не существует в жизни пользователя, то и решать ее не нужно.
2. «Как часто вы сталкиваетесь с такой ситуацией?» — смотрим на частоту.
Варианты ответа подбираем под тип события: для ежедневных привычек — от «несколько раз в день» до «раз в неделю и реже», для редких событий — от «несколько раз в месяц» до «раз в год и реже». Тут мы прогнозируем удержание: если проблема возникает редко, то и пользоваться фичей будут редко.
У этого вопроса есть важный дополнительный эффект — защита от социально желательных ответов. Люди склонны преувеличивать важность «правильных» вещей, например интерес к изучению иностранных языков. Вопрос о реальной частоте вскрывает разрыв между декларацией и реальным поведением. Если за последний год респондент ни разу не оказывался в ситуации, где нужен перевод, скорее всего, его интерес к новой функции так и останется просто интересом.
3. «Насколько сильно вас беспокоит/раздражает ситуация?» — сверяемся со значимостью.
Тут оценка идет по вербальной или числовой шкале. Так мы проверяем готовность платить. Если масштаб проблемы небольшой и пользователь готов терпеть, он не станет платить за решение.
Шаг 3. Визуализируем ответы
Теперь результаты вопросов наносим на карту приоритетов: оси — распространенность и значимость проблемы; размер маркера — частота столкновения с ситуацией.
Границы зон мы определяем по медианным или средним значениям выборки: все, что выше по обеим осям, — первый приоритет, ядро будущего продукта. Высокая значимость при распространенности ниже средней линии — второй приоритет, потенциально нишевый продукт: проблема болит у небольшой группы, но болит сильно, за решение будут готовы платить больше. Остальное — деприоритизация.
Размер маркера (частота) работает как дополнительный фильтр: ситуация может быть распространенной и значимой, но если она возникает раз в год, это разовая функция, а не ядро.
Такая карта помогает аргументировать, почему стоит отказаться от той или иной функции. На Discovery-этапе отсеять фичу всегда сложнее, чем ее добавить.
Нюансы реализации
Важно сказать, что опросник чувствителен к деталям. Вот нюансы, которые могут повлиять на валидность данных.
Нейтральность формулировок
Сравните: «ужасная проблема со связью» и «звонок прервался». Эмоционально окрашенные описания искусственно завышают значимость. Поэтому важно использовать нейтральные формулировки, описывать факты и не оценивать ситуацию.
Временное окно и естественная частота
Адаптивную шкалу я уже упоминал выше, но для нас важен и сам принцип выбора временного окна: оно должно быть достаточно длинным, чтобы событие успело произойти, и достаточно коротким, чтобы респондент его еще помнил, а не достраивал в памяти.
Ниже общие ориентиры:
«за последний год» — для редких событий (покупка недвижимости, смартфона);
«за последний месяц» — для периодических событий (поход к врачу, заказ такси, оплата ЖКХ);
«в последнюю неделю» или «вчера» — для ежедневных событий (прослушивание музыки, использование мессенджеров).
Финальную гранулярность лучше подбирать с учетом специфики продукта и естественной частоты события.
Что еще можно узнать в опросе
Удовлетворенность существующими способами решения
К трем базовым вопросам можно добавить: «Как вы решаете эту проблему сейчас?» и «Насколько довольны текущим решением?». Если «проблема частая и болезненная», а «текущие решения не устраивают» — это окно возможностей для запуска нового продукта. Если же удовлетворенность высокая — стоит задуматься о рисках и барьерах при переходе на новое решение.
Готовность к внедрению фичи
После анализа проблемного поля можно собрать первые реакции на предполагаемое решение — здесь хорошо работает «лобовая» диагностика MVP. Мы обычно задаем конкретные вопросы: «При каких условиях вы бы этим воспользовались?», «Готовы платить отдельно или ожидаете в базовом тарифе?». Ответы помогут чуть лучше узнать реальные намерения пользователя, а не просто симпатию или антипатию к решению.
Итог
Метод Колмакова оказался одним из самых простых и эффективных инструментов ранней приоритизации в нашей практике. Он не требует сложной аналитики, легко масштабируется на десятки фич и, главное, опирается на то, в чем респондент уверен, — его собственный жизненный опыт.
Недавний пример — исследование ИИ-ассистента для телефонных звонков. Из 17 функций методика помогла выделить флагманскую — распознавание мошенников во время разговора, где совпали все три показателя: высокая распространенность, острая значимость и регулярная частота. Несколько функций, привлекательных «на словах», но без реальной боли за ними, мы отложили. По этой же логике мы отбираем гипотезы в других проектах, включая решения в области безопасности. Если было полезно — забирайте в свою практику.
Ну и напоследок небольшая сводная таблица:
Задача | Подходящий инструмент |
Оптимизация существующего продукта, знакомого пользователям | Модель Кано |
Ранжирование списка фич — без проверки, нужны ли они пользователю | MaxDiff |
Приоритизация функций нового продукта, с которым у пользователя нет опыта | Метод Колмакова |