Фев. 10

Как провести более 200 продуктовых экспериментов за год

У меня более 8 лет продуктового опыта, за это время я работала на разных позициях: в маркетинге, аналитике, продакт-менеджменте. Последний год я продакт-лид команды Growth в компании Parimatch Tech, и за это время мы с командой провели более 200 экспериментов, тестируя новые функции, улучшая продукт и бизнес-показатели. Почему это важно? Прежде чем запускать новые функции и изменения в продукте, важно понять, сработают ли они вообще, чтобы не тратить деньги и время зря.

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

Иллюстрация Алины Самолюк

Как запускать эксперименты

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

Все ошибаются. Если не проверять свои гипотезы и не генерировать новые решения, невозможно быстро и качественно развиваться. Культура экспериментов стимулирует находить много разных проблем в продукте и огромное количество решений. А если в эксперименте что-то не сработало, стоит порефлексировать над этим и сделать выводы на будущее, не теряя при этом ресурсы. Что мешает запускать эксперименты в компаниях? Часто на это нет времени. Вторая причина — процессы в коллективе просто не предусматривают подобного рода действий.

Многие представляют себе запуск экспериментов в компании примерно так: «Слушай, у меня тут такая идея появилась, проверь, работает ли это». На самом деле все происходит не так. За экспериментами стоит четкий и налаженный процесс. Главное в нем — находить правильные цели, создавать гипотезы и проверять их, удерживая фокус на точке роста.

У каждого эксперимента есть четыре основных составляющих. Это гипотеза, действие, данные и выводы. То есть мы создаем гипотезу, проверяем ее, анализируем полученные данные и делаем выводы.

Работа в нашей команде построена так, что мы вместе генерируем идеи. Сначала определяем зону роста в продукте, собираемся на групповую сессию, пробуем поставить себя на место пользователя и проверяем, как работает та функциональность продукта, которая может повлиять на метрику, которую хотим улучшить. Дальше идем к другим командам и показываем, какие нашли проблемы и какие у нас есть предположения по их решению. Просим дополнить и брейнштормим вместе с ними. Потом приоритизируем все гипотезы по системе ICE — по критериям влияния, уверенности и простоте реализации. Последнее условие ключевое. Некоторые growth-команды даже не начинают эксперимент, если для его создания нужно больше 5 дней.

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

Как это работает на практике

Часто люди в компании не верят в тот или иной эксперимент: говорят, что и так все хорошо работает, а потом удивляются крутым результатам. Приведу яркий пример. У нас была не очень понятная валидация пароля при регистрации, не было четкой инструкции, из каких символов он должен состоять. Когда мы пытались донести это разработчикам, они говорили: «Ну а что там непонятного? В углу поля знак вопроса, можно на него нажать и все прочитать, если что-то непонятно».

Но мы все-таки решили провести эксперимент и сделать понятную структурированную валидацию пароля, которая объяснила, какие символы обязательно нужно ввести, чтобы закончить регистрацию (хотя бы одна маленькая буква, хотя бы одна большая буква, хотя бы одна цифра). Результат оказался потрясающий — за два часа мы получили +64% к коэффициенту конверсии в регистрацию.

Еще один пример — эксперимент с увеличением минимальной ставки для пользователя. В компании возмущались по поводу этого эксперимента: им казалось, что он приведет к негативу. Но мы решили рискнуть и провести его на небольшом количестве пользователей.

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

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

Почему провальные эксперименты важны

В некоторых компаниях процветает культура, которую можно описать так: «Если ты ошибся — значит, ты некомпетентный». У нас в компании такого нет, мы очень просто принимаем, что можем ошибаться, особенно в экспериментах. Совершив несколько ошибок, мы будем наверняка знать, работает наша гипотеза или нет, и получим возможность после этого показать классный результат. Это формирует культуру не предположений, а реальных результатов.

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

Мы решили взять тех, кто за последний месяц заходил на сайт меньше двух раз в неделю. Предварительно выгрузили их из базы и включили для 50% из них эксперимент. За то время, что он длился, очень мало людей зашло на сайт. То есть не стоит ожидать, что мы словим неактивных пользователей акцией на сайте. Что мы сделали? Рассказали об этом всей компании в нашем внутреннем канале. И сделали вывод, что дальше для таких аудиторий будем использовать каналы коммуникации для возврата их в продукт.

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

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

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

Лайфхаки для экспериментов

Для того чтобы эксперименты в компании стали привычной практикой и приносили результат, есть несколько правил.

Ставить четкие цели. Это самая главная составляющая. Цель — не только рост показателей, но и количество экспериментов.

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

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

Если у нас есть большая гипотеза, проверка которой займет много времени, мы максимально ее упрощаем и проводим эксперимент поэтапно. Например, чтобы проверить, заинтересует ли пользователей новые функции, мы их имитируем: для небольшого процента юзеров запускаем изменение в интерфейсе, чтобы они увидели новую фичу. Взаимодействовать с ней они могут до определенного этапа, а потом видят сообщение: «Простите, идет разработка». Таким образом мы можем понять и посчитать, как пользователи взаимодействуют с новыми фичами. Если им интересно, мы будем над этим работать дальше и подключим бэкенд, а если нет — даже не будем тратить ресурсы.

Ставить цель на улучшение метрик. Когда люди берут на себя обязательства на запуск нововведений, как правило, они выполняют это и бегут дальше, не уделяя должного внимания результатам и конкретным показателям. Например, комитятся за полгода запустить функцию А, B и C, запускают А и даже не замечают, что она не сработала. Все потому, что когда цель — новые фичи, то фокус тоже там. Но если цель — улучшение метрик и конкретных бизнес-показателей, акцент всегда на результате. Разработка продукта — это сложный и трудоемкий процесс, в нем постоянно происходит переоценка того, на чем нужно сосредоточиться в данный момент. Поэтому цель на метриках помогает держать правильный фокус.

Где искать гипотезы и почему важно сделать их рутиной

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

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

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

Выводы

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