Как в условиях кризиса дешево тестировать продуктовые гипотезы

Что делать продуктовым командам, чтобы запускать новые идеи с ограниченным бюджетом.

С 2017 года я создаю цифровые продукты и помогаю привлекать венчурное финансирование в стартапы. В рамках Art & UX мы проектируем и разрабатываем продукты для крупных цифровых компаний.

В кризисные периоды компании срезают расходы на направления, которые не являются первой необходимостью и больше фокусируются на сушке финансовых показателей. Расширять команды и защищать бюджет на что-то новое становится сложнее.

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

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

Пример клиентского проекта из геймдева. Выделили 3 сегмента: недавние пользователи, зрители, платящие пользователи.

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

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

После выявления паттернов в качественном интервью, тестируем эти вопросы на большей выборке респондентов. Получаем 500 откликов, делаем выводы.

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

Итого, за два подхода мы составили список задач, который решал выявленные проблемы в ходе интервью и был подкреплен количественным опросом.

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

Это поможет увеличить доходимость от регистрации до покупки, снизит её стоимость, повысит NPS и CTLV.

UX–прототип — монохромная версия вашего будущего продукта, собранная на коленке за пару дней. Во всяком случае, мы интерпретируем её именно так, в то время, как многие компании тратят на этот этап множество спринтов.

Во время тестирования даем фокус–группе прототип и просим пройти от пункта А до Б. Смотрим, на какие кнопки нажимают респонденты, и выявляем проблемы.

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

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

Делаем креативы, лендинг, запускаем трафик, смотрим CPC и CR. Преимущество подхода в том, что он не постановочный. Клиенты нажимают на реальную рекламу, и ожидают получить реальный продукт. И если они нажали на кнопку, которая ещё не работает, то они конечно расстроятся, но зато вы малой кровью получаете подтверждение вашей гипотезы. Итого, 100 недовольных пользователей, которые увидели ошибку, в обмен на сэкономленные миллионы рублей на проверку жизнеспособности идеи.

В нашем стартапе Arenta, когда мы запускали рекламу у нас не был готов backend продукта, и мы сделали фейковую заглушку. Когда запустили трафик, то увидели, сколько людей с какого креатива нажимают на неработающую кнопку «забронировать». Увидели все показатели трафика, и сразу отсеяли эффективные юниты, которые дальше стоит разрабатывать. Это минимальный ущерб по сравнению с тем, если бы мы сделали разработку, поняли, что решение не работает, и переделали.

Главная идея, которой мы придерживаемся на этом этапе, попробовать сделать продукт без инструментов разработки. Совсем. Пусть это будет хоть лист бумаги или таблица в Excel, главное, чтобы он подтверждал гипотезу и выполнял свою функцию. Если у этого будут пользователи, можно считать работу за успех.

Живые клиенты всегда лучше даже самых качественных исследований.

Проблема здесь в том, что большинство продуктовых команд имеет искаженное представление о создании MVP, не упрощая функционал до минимума.

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

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

Возвращаясь к примеру MVP без участия кода, когда мы начали тестировать Yook — сервис для бизнес–дейтинга, то собрали первые регистрации через Google Формы, а продукт предоставили в виде Google Таблицы с результатами. Люди грузили свои фотографии через убогую форму, но зато это работало, и за пару недель мы собрали 50 реальных клиентов, которые начали взаимодействовать с продуктом.

Мы пришли к этому не сразу, а только после того, как сделали дизайн MVP приложения (как мы тогда думали). Только посмотрев на него мы осознали, что наш продукт — это по сути справочник людей, который можно уместить в столбики Google Таблицы.

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

Менеджер. Готовит вопросы, находит респондентов, общается с ними, исследует рынок, конкурентов и несет эту информацию команде.

Дизайнер интерфейсов. Оформляет гипотезы в прототипы, а после тестов дорабатывает до итоговых решений.

#ux #product #разработка

Читайте другие наши материалы: