Как протестировать спрос на продукт? Алгоритм на примере рынка страхования в Азии
Расскажем, как подготовиться к выводу нового продукта на рынок: как провести исследование рынка, определить метрики, протестировать гипотезы. Каждый шаг разбираем на примере запуска сервиса на рынке страхования одной из стран Юго-Восточной Азии объемом 4,7 млрд. USD.
Алгоритм подойдет как компаниям, которые хотят запустить новое направление, так и предпринимателям, желающим проверить бизнес-идею. А внимательные продакт-менеджеры в конце статьи смогут найти полезный метод для проверки гипотез спроса.
Задача клиента
К нам, в студию продуктовой разработки MVP Lab, обратился страховой брокер с представительствами в 11 странах.
Компания решила развивать новое направление: продавать услуги онлайн-страхования физическим лицам. Продукт планируют выводить на рынок Юго-Восточной Азии. Для этого нужна информация о пользовательских привычках, продвижении, состоянии рынка.
Какие продукты востребованы на рынке? Как пользователи покупают страховку? Какие каналы продвижения эффективны в данном регионе?
Чтобы ответить на эти вопросы, мы провели исследование рынка, проанализировали продукты конкурентов и протестировали гипотезы.Далее весь процесс разбираем по шагам.
Типичная ошибка бизнеса
По нашему опыту, при выводе продукта на новый рынок часто совершается ошибка:
Компании не проверяют наиболее рискованные бизнес-гипотезы и не проводят исследования, а сразу создают продукт.
В результате получается приложение с большим набором фич, сделанных без понимания потребностей пользователей.
При таком подходе нельзя отследить, как каждая функция в отдельности влияет на бизнес-метрики. А, значит, нельзя понять, какой функционал дает пользователю ценность, а бизнесу — деньги. Разработка делается ради разработки.
Эту ошибку совершают не по глупости, компании объясняют это несколькими причинами.
- Боятся рисковать брендом: «Тестовый продукт может быть воспринят пользователями как некачественный».
- Технически высокий порог вход: «Требуется сложная разработка и сторонние интеграции. Пользователь не получит ценность, если не реализовать весь функционал сразу».
- Высокая конкуренция: «Если мы будем выводить продукт на рынок постепенно — конкуренты могут увидеть и опередить».
Как поступать компаниям при таких обстоятельствах? Как выпустить тестовый продукт без риска для бренда и выяснить спрос до выхода на рынок? Каким должен быть тестовый продукт?
1 шаг — анализируем продукты мировых лидеров
В каждой стране свое законодательство. Как следствие, пользовательский сценарии для жителя из США будет отличаться от российского. Например, при оплате в США нужно ввести почтовый индекс, а в России — принять соглашение об обработке персональных данных.
Пользовательский сценарий (англ. User flow) — это действия, которые совершает пользователь для достижения своих целей. Конкуренты могут все что угодно писать о преимуществах на своих лендингах. Что же на самом деле из себя представляет продукт, можно понять, только пройдя самому весь сценарий.
При анализе продуктов конкурентов составляем:
- Карту основного пользовательского сценария
Сценариев использования в сервисе много, на данном этапе достаточно сформировать понимание основного. С помощью него сложится представление, как люди привыкли пользоваться продуктом. Также, он поможет проследить, какие сейчас тренды на рынке — лучшие практики конкурентов можно реализовать в своем продукте.
- Список триггеров и фич
В каждом сервисе есть функционал, который помогает довести клиента до продажи или перевести на следующий шаг в User Flow. Например, подсказки при заполнении сложной формы или предоставление скидки при немедленной покупки.
- Список блокирующих факторов при использовании продуктов
Ими могут быть непонятный прайсинг, отсутствие навигации, долгая загрузка изображений. В своем продукте необходимо избегать подобного: даже просто отсутствие в сервисе таких проблем, может стать конкурентным преимуществом.
2 шаг — изучаем региональный рынок
После анализа мировых практик, переходим к изучению регионального рынка.
Если первый шаг нужен больше для получения инсайтов о проектировании сервисов, то на этом этапе нужно понять, с какими продуктами придется конкурировать.
Наш клиент планировал выходить на рынок одной из стран Юго-Восточной Азии. Но мы анализировали компании со всего региона, так как они также являлись потенциальными конкурентами.
Анализируем следующие моменты.
User Flow и дизайн
На этом шаге не ограничиваемся анализом основного сценария, а составляем все вариации использования сервиса, обращаем внимание на UX и UI дизайн. Например, интернет в Азии развивался не так как в Европе. Если у европейцев интернет сначала появился на компьютере, то в большинстве стран Юго-Восточной Азии он получил распространение в Post-PC era, когда уже были смартфоны. Поэтому UX азиатского сайта будет отличаться от европейского.
Продуктовая линейка
Анализ продуктовой линейки конкурентов нужен для того, чтобы понять, в каких направлениях экономика «сходится» и в дальнейшем выбрать, с какими продуктами выходить на рынок.
Когда начинаешь работать на новом рынке, есть риск воспринимать его также как и те, где уже есть опыт.
Потребности и пользовательские привычки могут казаться очевидными: что востребовано в одной стране, будет также пользоваться популярностью и в другой. Но это не так.
На данном этапе нужно выяснить, какие потребности есть у пользователей конкретно из того региона, где планируется вывод продукта.
- Без какого продукта житель не может обойтись?
- Какие есть требования со стороны законодательства? Например, есть обязательные виды страхования, а есть — по желанию граждан.
- Какие проблемы есть у жителей?
- Как эти проблемы решают конкуренты?
Также, изучая продуктовые линейки компаний, нужно понять, какие продукты приносят основную прибыль.
- Какие продукты — трипваеры?
- Какие закрывают главную потребность клиента?
- Какие — для апсейла?
Ценообразование
В зависимости от отрасли стоимость продукта складывается по-разному. Где-то это просто сумма затрат на производство, маркетинг и желаемая выручка, где-то схема посложнее и зависит от множества факторов, которые вне зоны вашего контроля, которые тем не менее нужно знать.
В нашем примере цены диктуют страховые компании, страховые агрегаторы на них не могут подействовать. Но могут влиять на сумму комиссии с каждого клиента.
Как конкретно в вашем случае строится ценообразование, можно понять при изучение рынка и всегда будет полезно привлечь человека из отрасли в качестве эксперта.
Например, формулы расчета суммы страховых премий — это информация, которую мы смогли получить благодаря эксперту с регионального рынка.
3 шаг — формулируем гипотезы
На основе знаний, полученных из анализа рынка, составляем гипотезы о продукте.
Гипотезы — это предположения, которые необходимо проверить. Без проверки наиболее рискованных гипотез, сразу создавая продукт, есть риск потратить бюджет впустую.
Запрос наших клиентов: «Будет ли продукт пользоваться спросом на новом рынке?» — это уже верхнеуровневая гипотеза.
Шаблон формулирования гипотезы выглядит так:
Я верю, что если (описание действия), то будет (описание результата). Чтобы проверить мы (описание эксперимента) и измерим (метрики). Эксперимент удачен, если (значение метрики).
Пример
Я верю, что реклама в Facebook способна продвигать продажу страхования онлайн. Чтобы проверить гипотезу, мы запустим трафик на сайт с онлайн-продажей страховок и измерим сustomer acquisition cost. Эксперимент удачен, если CAC меньше N.
Причем в случае с исследованием нового рынка «удачным» можно считать любой результат. Так как в данной стадии проекта нужно не найти как изменить показатели, а просто измерить, получить данные о рынке. Результат — это знания о поведении и потребностях пользователей.
4 шаг — выбираем метрики
Как понять, с каким продуктом выходить на рынок? Какую ставить цену? Решение можно принять интуитивно, а можно — на основе информации, фактах о рынке, используя Data-driven подход.
Чтобы решить, с каким продуктом выходить, нужно выбрать метрики, характеризующие рынок и получить их значение. Метрика — это качественный или количественный показатель. Все метрики не нужны. Выбираем только те, которые нужны для принятия решения.
Существует 2 типа метрик, нужных для вывода продукта на рынок: маркетинговые и продуктовые.
Продуктовые метрики показывают, как работает и используется продукт.
Маркетинговые — это те метрики, которые показывают, как продукт продвигается на рынке.
Во время исследования для нашего клиента мы выбрали следующие метрики:
- CAC (Customer Acquisition Cost) — стоимость платящего пользователя. Рынок новый, у нас не было даже приблизительного понимания во сколько может обойтись 1 клиент. Эта метрика помогает оценить рентабельность проекта.
- CR (Conversion Rate) — конверсия в покупателя. Она показывает, насколько рынок готов к нашему продукту, покупке страховки онлайн, и насколько верно мы спроектировали продукт. Безусловно, конверсия зависит от каналов привлечения и рекламных предложений, поэтому мы постарались сделать прямую коммуникацию без сложного креатива.
- AOV (Average Order Value) — средняя стоимость заказа. Сможем оценить, сколько в среднем пользователь тратит на приобретение страхового продукта каждого вида с учетом всех дополнительных опций.
Пример
В стране N есть два вида страхования: A и B. Предположим, что A в среднем стоит 500, а B — 400. Комиссия агента в обоих случаях равна 10%.
Что лучше продавать? Для того, чтобы ответить на этот вопрос нам необходимо определить стоимость привлечения одного клиента (CAC) в каждом рекламном канале и убедиться, что она ниже, чем получаемая комиссия.
Но как получить значение этой метрики?
Нужно создать MVP-версию сервиса по продаже страховок и запустить рекламную кампанию: «Я верю, что страховка А будет продаваться. Чтобы это проверить, мы сделаем MVP, запустим трафик и измерим CAC». Аналогично для страховки B.
По итогу тестирования гипотезы, мы получим данные о том, сколько стоит привлечение одного клиента для каждого вида страхования.
Подробнее о проектировании MVP поговорим в следующем пункте статьи.
5 шаг — делаем MVP
На прошлых этапах мы сформулировали гипотезы, которые хотим проверить и выбрали метрики, значение которых хотим узнать. Теперь, чтобы провести тестирование и получить первые данные, нам нужно сделать MVP.
Как измерить стоимость платящего пользователя, если мы не можем им ничего продать?
Мы эту проблему решили следующим образом:
- Сделали MVP страхового агрегатора. Бренд клиента не использовали, а сделали вымышленное название — Go Insurance.
- Выбрали три варианта продуктов страхования: «Автогражданская ответственность», «Каско», «Здоровье» и сосредоточились на них.
- В MVP сделали полную имитацию сервиса, чтобы пользователь поверил в реальность продукта: с рейтингами, данными по моделям автомобилей, множеством предложений страховых. Но без реальных интеграций — это сэкономило время и деньги, но тестированию гипотез не помешало.
- Пользовательский сценарий для каждого из продуктов сделали максимально приближенными к реальности.
Например, для «автогражданки», user flow состоит из:
- Выбор страховки: «Автогражданская ответственность», «Каско» или «Здоровье».
- Выбор типа автомобиля. От этого зависит расчет стоимости страховок.
- Выбор опций. В дополнение к автогражданской ответственности можно купить другие страховки, например, для пассажиров.
- Сравнение тарифов. На основе критериев агрегатор выдает подходящие предложения страховых компаний. Пользователь сравнивает стоимость, рейтинги и «ваучеры» — на рынке Юго-Восточной Азии при покупке продукта компании часто предлагают в подарок сертификаты в другие магазины.
- Заполнение данных. Пользователь вводит все данные для оформления страховки и переходит к оплате.
- Оплата. Пользователь выбирает подходящий ему способ и оплачивает страховку.
А теперь самое интересное :)
В MVP мы реализовали весь пользовательский сценарий, включая переход к оплате. Причем пользователю нужно было выбрать платёжную систему.
В момент, когда пользователь выбрал способ и готов оплатить, мы сообщаем о недоступности сервиса и обещаем направить скидку, как только все заработает (и это правда).
Таким образом мы получаем данные не о потенциальных клиентах, а о реально готовых платить!
Да, это все равно косвенная метрика, но она позволяет протестировать базовый спрос. Поэтому нужно обязательно пообщаться с тем, кто добрался до этой стадии — это позволит корректно интерпретировать полученные данные.
Еще в сервисе мы установили Livechat и форму обратной связи для сбора обращений от пользователей с проблемами. Кто-то не мог понять, к какому типу относится его машина, кто-то запутался в предложениях страховых. На основе обратной связи, мы сформировали набор гипотез по улучшению пользовательского опыта.
6 шаг — Собираем данные
Для сбора данных достаточно настроить Google.Analytics. Если вы решили запустить тест на большом объеме трафика, то можно сделать дашборд в Google Data Studio. Так как кроме маркетинговых показателей интересно поведение пользователей в сервисе, создаем цели на прохождение каждого шага по user flow и строим из них воронку.
Итог исследования рынка страхования
С помощью MVP мы получили значения CR, CAC, AOV. Для этого мы привлекли тысячи пользователей в сервис и сделали достаточно «продаж», чтобы полученным значениям метрик можно было доверять.
Увидели потенциальную сходимость экономики в разных каналах и для разных видов страхования, нашли узкие места в воронке, определили платящую целевую аудиторию.
Полученные данные помогли принять решение о видах страховых продуктов, с которыми стоит работать в первую очередь.
После всех тестов, исполнив свое предназначение, MVP был выключен и началась подготовка к следующим этапам, но уже совсем другая история.
Вывод
Для того чтобы вывести продукт на новый рынок, нужно сперва провести исследование.
- Проанализировать мировых лидеров и тренды рынка.
- Изучить региональный рынок, конкурентов.
- На основе собранной информации составить гипотезы, приоритизировать их.
- Понять, какие метрики будут характеризовать успешность гипотезы.
- Протестировать гипотезы с помощью MVP.
- Собрать аналитику.
Итогом исследования могут стать как данные о том, как лучше выводить продукт на рынок, так и решение, что проект не стоит запускать. И то и другое мы, в MVP Lab, считаем отличным результатом.
Не совсем понятно, на что вы опирались, когда выбирали типы страховок. Тупо что другие продают, то и вы?
Да, опирались на статистику о том, какие виды страховок наиболее популярны. Плюс у нас был консультант, который работает на рынке страхования той страны, который помог нам более точно понять ситуацию на рынке.
Ребят, сколько стоит такую шутку сделать? Ну и по срокам примерно
На данном проекте работало 3 специалиста: продакт-менеджер, дизайнер и разработчик.
В среднем час работы специалиста ~ 2500 р. Этот проект был реализован за 1,5 месяца
Обидно пройти все шаги в сервисе и получить уведомление о недоступности)) Сомнительно, будут ли потенциальные пользователи ждать запуска реального продукта, даже с тем фактом, что есть промокод на скидку
Цель была проверить спрос. Конечно, пользователи могут уйти к другой компании. Но в любом случае, мы можем с ними связаться, когда будет готов сервис к работе.
Ну так это же классика. Сайт который как бы работает но по факту только регистрирует.
Кстати не факт что это легально во всех странах. Как минимум смахивает на предоставление заведомо ложных сведений и продукте и введение пользователя в заблуждение