Как ускорять запуск экспериментов: 4 хака от продакта и тимлида Авито
Привет! На связи Анна Гончарова — ведущий продакт-менеджер, и Егор Дудин — тимлид в Авито. За 3 года мы с командой научились проверять больше продуктовых гипотез, чем в среднем делают команды Авито.
В статье расскажем о принципах и подходах, которые помогли нам научиться проверять несколько десятков гипотез за полгода. Объясним, как развивать продуктовое мышление, делать дискавери и деливери встречи эффективными и мотивировать членов команды запускать больше экспериментов.
Материал будет полезен командам, которые уже давно работают вместе и ведут несколько проектов параллельно или тем, кто только стремится расширяться.
Введение: держите всех в курсе новых запусков
Процессы
Держите всех в курсе новых запусков и поощряйте выход из своей зоны ответственности
Когда сотрудники видят общую картину и могут мыслить за рамками своей зоны ответственности, команде проще договариваться и двигаться в одном направлении. Вот несколько советов, которые помогут настроить всех участников на общую волну:
Стимулируйте инженеров становиться фичалидами. Так мы в Авито называем разработчиков, которые берут на себя менеджерские функции и лидируют запуски продуктов.
Лидирование фич — способ роста в грейде для сотрудников, если, например, у команды не хватает сложных технических задач. Сотрудники сами будут проявлять инициативу и лидировать запуски фичи, когда увидят, что это действительно помогает им расти и при этом влияет на пользовательский опыт.
Фокусируйте разработчиков на росте метрик и запусках экспериментов, а не на создании фич. Это позволит расширить зону ответственности и сместить внимание инженеров на то, что наша цель — решить боль пользователей и повлиять на метрики.
Рассказывайте команде, как показывают себя запущенные тесты: как меняются метрики, какие проблемы появляются в аналитике. Когда цель выражена в метриках, сами инженеры начинают предлагать решения, чтобы запуститься и проверить гипотезу как можно быстрее.
Если вы тимлид, советуем проактивно сближаться с продуктом и приходить на встречи с дискавери-командой. Так тимлид лучше понимает, над чем работают коллеги, может помогать продакт-менеджеру и стимулирует остальных погружаться в процессы.
Сближайте инженеров с дискавери-командой. Например, мы анонсируем запуски экспериментов в командных чатах, пишем о результатах, а ещё приглашаем разработчиков на разборы самых интересных тестов.
Так мы приближаем инженеров к процессу дискавери, помогаем расширять их продуктовое мышление. Люди видят результаты работы — мотивация команды растёт.
Мышление: учитесь думать гипотезами — вот 3 часто встречающихся типа
Понятный эксперимент. Это тест, для которого мы заранее знаем примерный результат, потому что уже делали что-то подобное. В этом случае нам нужно подтвердить догадки на данных с A/B-теста.
Пример такого эксперимента. Недавно прайс-листы стали обязательными в объявлениях на Авито Услугах. Раньше исполнителям не нужно было указывать расценки, они могли написать среднюю стоимость и попросить уточнить детали во время общения. Мы решили постепенно ввести обязательные прайс-листы, чтобы заказчики сразу видели стоимость в объявлениях.
Нужно было проверить, не уйдут ли исполнители с площадки после того, как мы сделаем заполнение прайс-листов обязательным. Мы заранее предполагали, что, если сделаем прайс-листы обязательными — покрытие вырастет на 50%, а метрика реактивации не упадёт больше чем на 3%. На А/B-тестах всё подтвердилось.
Эксперимент на поиск потенциала. Это тест, в котором надо проверить, стоит ли вкладываться в создание и развитие нового продукта. В этом случае мы не уверены, что гипотеза выстрелит, но чувствуем, что есть потенциал.
Например, сейчас мы решаем, нужно ли развивать в Авито Услугах возможность смотреть объявления на карте — или обычных результатов поиска уже достаточно. Прежде чем вкладывать туда ресурсы разработки, мы проведём несколько экспериментов, чтобы проверить, как заказчики услуг сейчас пользуются картой, и влияет ли это на количество сделок.
Смелый эксперимент. Так мы называем большие изменения, которые могут сильно изменить продукт или пользовательский флоу.
Пример такого эксперимента. У каждого объявления на Авито есть основная цена. Пользователи указывают её при размещении объявления, и её хорошо видно в карточке:
Бывает, что сумма отличается от реальной стоимости работы исполнителя. Например, человек мог поставить в качестве основной самую низкую цену, чтобы привлечь внимание.
Наша гипотеза была в том, что если мы полностью уберём основную цену из объявлений с услугами и оставим только прайс-листы, это позволит избавиться от неточных цифр, и заказчики сразу будут видеть реальную стоимость услуг.
Такой эксперимент мы называем смелым: в результате него можем улучшить опыт заказчиков, но при этом большая их часть может уйти с площадки, потому что клиентам будет непривычно без основной цены в объявлениях.
Начать мыслить гипотезами может быть непросто: вот несколько советов от нашего тимлида, как развить такое мышление у себя.
Как начать мыслить гипотезами — советы от тимлида:
💡 Приносить продакту свои идеи для запусков. Это позволит лучше понять, как он мыслит и валидирует гипотезы. Особенно приятно, если твоя гипотеза находит отклик и идёт в разработку, или находится способ проверить ее в несколько раз быстрее.
💡 Пройти курс от GoPractice: «Симулятор управления продуктом на основе данных».
💡 Задавать продакту любые вопросы про продукт: зачем мы это делаем? Почему именно таким способом? Почему считаем, что эта метрика важна? А почему бы не сделать по-другому?
💡 Активно участвовать в разборах A/B-тестов. Задавать вопросы по метрикам, выдвигать гипотезы, если метрики ведут себя странно. Возможно, пытаться самостоятельно интерпретировать результаты перед общим разбором.
Всё это расширяет кругозор и помогает лучше понять, как коллеги запускают тесты, и что значат конкретные метрики.
Всё это расширяет кругозор и помогает лучше понять, как коллеги запускают тесты, и что значат конкретные метрики.
Мышление: всегда думайте о том, как упростить проверку гипотез
Чтобы развивать навык упрощения, всегда задавайте себе вопросы: что обязательно реализовать, чтобы проверить гипотезу, а что можно отрезать и сделать позже или не делать вообще.
Например, на первых порах проработки фичи можно провести тесты только на одной платформе, если по каким-то причинам запускать A/B на всех одновременно — слишком сложно, дорого или долго.
Можно отказаться от части функций, если они не влияют на целевую метрику.
Также можно выпустить продукт с неидеальным дизайном и доработать его позже. Если знаете по данным, что это повлияет на очень маленький процент пользователей — запускать сырую фичу уже не так страшно, потому что вы оценили риски и осознанно на них идёте.
Пример: запустили неидеальную фичу на 2 спринта быстрее и увидели рост метрик. Мы запускали фичу, которая принудительно сортирует объявления по геолокации. Фильтровать предложения по гео можно было и раньше, но люди пользовались этим редко — возможно, просто не знали.
Мы решили исправить это и сделать фильтрацию принудительной. Ожидали, что эта разработка повысит конверсию в сделку, так как заказчикам будет удобнее находить исполнителей рядом.
В интерфейсе это выглядело так:
Когда начали разработку фичи, столкнулись с некоторыми проблемами:
❌ На iOS был критичный баг, который мы не успели бы поправить до раскатки. Поэтому от запуска на iOS отказались.
❌ В мобильной версии сайта не было возможности сделать так, чтобы фильтр был включён сразу. От запуска на этой платформе тоже отказались.
❌ Кнопка «сбросить» отключала все фильтры, которые отметил пользователь, кроме нашего — сортировку по геолокации нужно было отключать вручную. Решили, что эта проблема не помешает проверить гипотезу, поэтому этот баг тоже не исправляли.
В итоге мы выкатили фичу только на Android — там было больше всего трафика, и мы смирились с некоторыми ограничениями. Если решили бы исправить все баги — запустились бы на 2 спринта позже.
Мы провели А/B-тест и увидели, что даже не финальная версия фичи растит конверсию в сделку у пользователей в больших городах. Раскатывать её на всех в таком виде мы не стали из-за перечисленных проблем, но запланировали новую итерацию в следующем квартале.
Процессы: делите работу на этапы в зависимости от количества вводных
Настройте процессы так, чтобы вы могли легко и быстро находить решения для задач с разной степенью неопределённости.
Мы выделяем 3 типа задач:
- С высоким уровнем неопределённости.
- Средним.
- Низким.
Расскажем о том, как классифицировать гипотезы на типы и как работать над такими задачами эффективно. Начнём со стадии, когда ничего не понятно.
🔴 Высокая степень неопределённости. Если на этапе проработки гипотезы у команды ещё нет вводных, ТЗ, макетов — первый груминг мы советуем проводить с ограниченным числом участников дискавери-команды. В нашем случае это продакт-менеджер, тимлид, аналитик, дизайнер и исследователь, если делаем что-то новое.
Чем меньше людей на этом этапе, тем лучше. Если участников будет слишком много — есть шанс застрять.
💡 Подключайте технического лида на ранних стадиях проработки проекта. Он может предупредить о сложностях или предложить техническое решение.
Бывает, что продакт приносит разработке красивые макеты, но в ответ слышит, что сделать такое невозможно или слишком дорого. Если тимлид подключается во время дискавери, то сможет заранее подсветить некоторые моменты и убережёт команду от бесполезной работы.
Бывает и наоборот. Участники дискавери-команды могут отвергать мысль о какой-то фиче, потому она кажется слишком дорогой. Иногда такие предположения ошибочны, и тимлид сможет аргументировано предложить варианты.
На встрече с погружением в проект можно, например, сделать доску в miro и записывать на стикерах планы и предложения участников встречи.
Отдельно стоит выписывать, каких вводных не хватает, и фиксировать идеи, которые появились в течение встречи.
🟡 Средняя степень неопределённости. На этом этапе у команды есть примерное ТЗ, готова первая версия макетов, техническое исследование, грубая оценка.
В таком случае мы проводим открытый дискавери-груминг и расширяем число участников — плюсом к основному составу дискавери-команды мы приглашаем редактора, фичаоунера и разработчиков — по желанию.
🟢 Низкая степень неопределённости. На этом шаге у нас уже есть сетап эксперимента, а макеты и согласования со стейкхолдерами завершены на 90%.
Тогда мы приносим инициативу на груминг деливери-команды, где обязательно будет фичаоунер и разработчики, которые будут задействованы в проекте.
Процессы: как мы проводим дискавери-груминги
Типы дискавери-грумингов и примеры:
Погружение в стрим. Обсуждаем, что примерно хотим сделать, зачем, и что сделать, чтобы стало понятнее, как разобраться в новой задаче.
💡 Как эффективно погружать команду в задачу — совет от продакта:
Как правило, на старте работы над проектом у команды высокий уровень неопределенности. Поэтому я заранее выписываю, что конкретно нам известно, а что ещё нужно узнать. А потом на встрече мы с дискавери командой мы проговариваем, какие шаги помогут нам разобраться в задаче лучше.
Например, аналитик собирает статистику по использованию текущих инструментов, исследователь помогает найти подтверждения проблемы в рисёрчах, а дизайнер уходит исследовать интерфейсы прямых и непрямых конкурентов.
Так мы можем за несколько итераций качественно погрузиться в новое направление, подтвердить существование проблемы и предложить решение, которое понесём в деливери-команду на реализацию.
Решение конкретной проблемы. Такой груминг мы проводим, когда есть конкретная задача, которую нужно решить. Цель — написать как можно больше идей → приоритизировать их → назначить ответственных → уйти делать.
Прорабатывать идеи также можно на доске miro с помощью стикеров или в любом другом приложении, которым вы пользуетесь.
Обычно кто-то из команды собирает вводные о проблеме и добавляет всё нужное на доску. Затем мы с командой встречаемся и начинаем совместно думать над шагами, которые помогут решить поставленную в начале встречи проблему.
Итогом такой встречи становится набор задач, распределённых между участниками.
Разбор неудачного эксперимента. Такой груминг мы проводим, если итоговый результат эксперимента отличался от того, что мы хотели получить. На этой встрече дискавери и деливери команды собираются и обсуждают, что пошло не так.
Так выглядит доска в miro после встречи:
На такие груминги советуем приглашать разработчиков, чтобы они могли найти ошибку и предложить конкретные способы решения.
После встречи участники идут работать над ошибками в своей зоне ответственности и затем перезапускают эксперимент.
Процессы: как мы проводим деливери-груминги
Мы не будем делить деливери-груминги на типы, как сделали это с дискавери-встречами, а дадим несколько советов для всех встреч деливери-команды.
Ограничивайте число участников — не зовите всех инженеров и тимлида на каждый груминг.
Например, если команда зрелая, тимлид может не контролировать весь процесс, а подключаться только для приоритизации задач. Ответственность за инициацию груминга в таком случае берёт на себя фичалид — человек со стороны разработки, который следит за реализацией фичи.
Определите правила фиксации открытых и закрытых вопросов, а также договоритесь, где будет храниться информация о задаче. Например, мы пользуемся Jira:
💡 Вопросы важно не только фиксировать, но и обсуждать детали реализации. Следующую встречу мы обычно начинаем с обсуждения открытых вопросов. А после обсуждения проговариваем и фиксируем в деталях, как и что будем делать, а ещё фиксируем критерии приёмки задачи.
Коротко: как продуктовой команде ускорять запуски тестов
Рассказывайте командам о результатах тестов и поощряйте расширение зоны ответственности.
Формируйте продуктовое мышление в команде: учитесь разделять эксперименты на типы, ищите быстрые и наименее затратные способы проверять гипотезы.
Делите работу на этапы по степени неопределённости. На ранних этапах привлекайте ограниченный список участников деливери-команды и постепенно вовлекайте всё больше коллег.
Разделяйте встречи дискавери и деливери команд. А также пишите повестку встреч, устанавливайте правила проведения и фиксируйте все незакрытые вопросы, чтобы возвращаться к ним на следующих встречах.