Как определить, какие функции действительно нужны клиентам: практический гайд по MaxDiff-анализу
Пошаговый план анализа клиентских предпочтений с расчетами и примерами, который помогает отделить критически важные функции продукта от бесполезных.
Я уже писал недавно, что одна из наиболее частых ошибок монетизации продукта - лишние функции.
Во многом это связано со стремлением продуктовых команд сделать "всем хорошо и побольше". Но на выходе такой подход скорее усложняет продажи, удержание и масштабирование, чем приближает тебя к списку Forbes.
Сегодня на упрощенном примере хочу показать способ приоритизации функций продукта, который помогает верифицировать ценность каждой из них для целевого сегмента.
Наша цель - понять, как выделить из всего бэклога (или готовой архитектуры продукта) самые ценные функции для клиентов, убрав те, которые по факту нравятся только тебе и твоей маме.
В реальной практике это помогает разложить все наработки команды на конфигурации по принципу "лидеры-филлеры-киллеры", переупаковать офферы и тарифы так, чтобы повысить ARPU и LTV, а также снизить стоимость привлечения и сократить цикл сделки.
Идея понятна. Стартуем.
Жребий пал на модуль аналитики. С него и начнем оптимизацию.
Подготовка списка
Первое, что нужно сделать - собрать в кучку все, что накодили или хотим накодить. Можно просто собрать список в Google Sheets или Excel. Иногда я использовал Trello. Кто-то сидит в Notion или Miro.
(это неважно - к чему привыкли, с тем и работаем)
В условном модуле аналитики у меня получилось 7 фич:
Если функций получилось сильно много (например, больше 15), то надо бы как-то на старте подсократить или разделить. Потому что, чем больше функций за раз ты хочешь проверить, тем больше респондентов тебе придется для этого привлекать (речь может идти о сотнях или тысячах человек). А это уже сильно сложнее организовать и сохранить репрезентативность выборки.
Поэтому рекомендовал бы "тестировать" не более 7-9 функций за раз.
Например, в первую очередь начинать с тех фич, которые уже работают и используется клиентами. А далее планомерно оценивать функции из бэклога.
Дизайн опроса
Итак собрали список из 7 функций. Что дальше?
Ты делишь эти 7 функций на наборы (сеты) по 3 фичи в каждом:
В совершенстве владея двумя кнопками онлайн-калькулятора комбинаций, ты знаешь, что всего таких наборов у тебя будет 35.
Зачем эти наборы нужны?
Мы будем один за одним (по очереди) показывать их нашим действующим или потенциальным клиентам. При этом для каждого набора каждый раз просить их сделать 2 вещи:
В целом все просто.
Совет из практики: задавай каждому респонденту не более 6-8 вопросов.
Иначе дальше устанут и начнут отвечать в формате "побыстрее, лишь бы отстали".
При этом для надежного анализа каждой функции, она должна быть показана респондентам в сумме (по всей выборке) не менее 500 раз (оптимально - 1000 раз).
Эта цифра важна! Она дает понимание того, какое количество респондентов тебе нужно будет опросить и как задизайнить показы наборов так, чтобы получить минимально объективно картинку приоритизации функционала продукта.
Математика такая:
- 7 функций х 500 показов = 3500 показов надо сделать всего;
- 3 функции в наборе х 7 наборов на респондента = 21 показ на 1 человека;
- 3500 / 21 = 167 человек нужно опросить
Из личного опыта - если на старте собрать такую аудиторию для тебя сложно, то можно опросить 30-50 человек.
Это допустимый минимум для приоритизирования внутри узкой группы экспертов или ключевых клиентов, который в первом приближении позволит выделить более ценные фичи. Однако статистическая мощность теста будет ощутимо ниже, поэтому, скорее всего, потребуются дополнительные способы ранжирования.
Анализ и результаты
После сбора ответов ты приступаешь к их анализу.
Сразу скажу, что есть разные методики такого анализа - от очень простых до математически сложных. Существуют даже целые компании и IT-продукты, которые занимаются подобными вещами (правда, на очень больших массивах данных).
Так как моя цель - познакомить тебя с подходом, то я здесь приведу самый простой (но менее точный) способ.
Он называется "подсчет баллов" (Counting Analysis). Суть в следующем:
На выходе вы получите ранжированный список функций. В нашем условном примере - он получился такой:
Мы видим, что RFM и Когортный анализ имеют самый высокий чистый балл. Это базовые ценности модуля. Они должны быть реализованы в первую очередь.
А вот дашборды и алерты по итогам опросов находятся в нулях, имея много голосов и "за", и "против". Это указывает на поляризацию мнений - функции очень важны для одного сегмента и безразличны другому. Возможно, их стоит развивать как отдельные плюшки для конкретных групп пользователей.
Среди аутсайдеров - карточка клиента, которая имеет глубоко отрицательный баланс, что говорит о ее низкой относительной важности. Если это бэклог - то функцию можно отложить или реализовывать по остаточному принципу.
В заключении
Поздравляю! Экспресс-погружение в методологию анализа клиентских предпочтений МахDiff завершено.
Она поможет тебе определить тех самых лидеров-филлеров-киллеров в продукте. Нюансов много. Про них буду рассказывать в новых постах. Сейчас хочу отметить лишь 2 вещи:
- Осторожно с формулировками
Если в опроснике одну фичу назовешь "AI, который спасет от оттока", а другую "экспорт в CSV" - можешь на выходе измерить силу копирайтинга, а не ценность функционала - Учитывай сегменты при формировании выборки
Понимай, кого опрашиваешь. Результаты оценивай с учетом того, кто отвечал (индустрия, роль, размер бизнеса, опыт в продукте и тп).
Как-то так. Успешных опросов!
Ставь реакции, если полезно. Пиши в комментах, как ты приоритизируешь функции своего продукта.
На простом языке о ценообразовании и монетизации в IT в моем telegram-канале
- что продавать (ценности vs фичи)
- за что брать деньги (модели + метрики)
- как снижать скидки, повышать цены и сохранять маржу
Кейсы, цифры, практика и польза.
Если ценишь полезный человеческий контент по теме роста прибыли в IT - подпишись, буду рад 🚀