Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Если кратко, то команды мы создали, чтобы:
Только за прошлый год протестировать 230 гипотез в Альфа-Мобайл и ещё сотни вне приложения.
Получить из них 40 успешных и найти точки роста с общим эффектом в несколько миллионов долларов в год.
Сэкономить ещё пару (десятков) миллионов рублей на разработках, которые не пришлось делать, потому что гипотезы показали, что в них нет ценности.
Меня зовут Илья Кузнецов, я — CPO Digital Innovations в Альфа-Банк. Пару лет назад я начал создавать команды роста. Сейчас у нас их несколько. В среднем, параллельно, они тестируют гипотезы 6 различных проектов, запуская ежедневно по 1 гипотезе в день на команду. В статье я кратко расскажу про наши команды Growth Hacking в Альфа-Банке с примерами наших кейсов, цифрами, результатами и «неудачными» гипотезами. Возможно, наш опыт поможет, если вы задумывались о Growth Hacking и о том, зачем он вам нужен.
Когда мы «продавали» команды роста в банки и в Альфа-Групп, нам всегда задавали одни и те же вопросы:
— «Зачем создавать команду роста? Ведь тестирование гипотез — это обязанность каждого продакта? Да и что там делать целой команде? Размер шрифтов и кнопочек большого ума протестировать не нужно»
Но Growth Hacking, это не про шрифты и кнопочки, а про принятие решений совершенно другого уровня.
Одна из целей Growth Hacking и интенсивного тестирования гипотез в том, чтобы ошибаться не в бизнесе, а в «песочнице».
Команда Growth Hacking (GH) в Альфа-Банке именно этим и занимается: тестирует много, тестирует быстро, собирает все ошибки, находит что-то полезное, и констатирует результат, который помогает заказчику принимать быстрые решения, экономить ресурсы и зарабатывать больше. Самая важная фишка искусства Growth Hacking команды в редуцировании идеи тестирования так, чтобы запрограммировать и запустить гипотезу за 1 день.
Теперь к примерам, которые это покажут и объяснят. Начнём с «неудачных гипотез».
Нет неудач — есть только результаты
Однажды у команды платежей и переводов родилась идея: «А давайте на главном экране сделаем какую-нибудь продвинутую плашку для популярных платежей? Наверное, пользователи тогда будут ими чаще пользоваться?»
Оказалось — нет.
Команда GH запустила гипотезу, в которой по-быстрому (в течение одного рабочего дня) «скопипастила» на главный экран текущую плашку платежей из вкладки платежей и переводов. Мы сделали её доступной для ограниченной выборки пользователей в 90 000 человек и накопили статистически достоверный отклик.
Как оказалось, никакой статистически достоверной разницы в платежах в контрольной группе и тестовой не произошло — гипотеза не подтвердилась. Казалось бы, неудача? Но нет.
Два дня тестирования гипотезы, которая не подтвердилась, — это экономия месяцев работы команды разработки.
Увидев результаты команда разработки не стала тратить ресурсы и время на разработку, внедрение, поддержку этой функциональности, которая не принесла бы бизнесу никакого результата.
Подобная история случилась с одной идеей в другом проекте — сервисе «Зарплата каждый день». Клиенты, которые получают зарплату на карту Альфа-Банк, могут получать её частями через сервис, ежедневно. При подключении к сервису клиент проходит обучение — онбординг: это просто текст на экране, который объясняет как всё работает
Команда проекта «Зарплата каждый день» сомневалась в эффективности онбординга в виде обычного текста и захотела его поменять. Они предложили несколько продвинутых вариантов с классным дизайном, например, с календарем выплат и цен или полем для ввода суммы.
Один из таких вариантов на картинке слева.
Мы протестировали эти продвинутые варианты, опять же на узкой аудитории, и, опять же, сконструировав гипотезы за 1 день.
Оказалось, что изначальный простой текст конвертирует лучше.
Что бы было, если бы команда проекта сделала новый онбординг, внедрила, и через 1-2 месяца увидела, что никакой разницы нет и усилия потрачены зря? Были бы потерянные ресурсы и рабочее время, которые стоят намного больше, чем незначительные усилия, которые мы потратили на гипотезы.
Именно для этого и нужна команда роста: мы показали результаты команде и от идеи отказались в пользу более полезных задач.
Зачем нужна выделенная Growth Team на примере проекта сбора Face ID
Может быть вы слышали про смарт-отделения Альфа-Банка, их ещё называют Phydgital? Вот так они выглядят внутри.
Одна из фишек таких офисов — там нет привычных очередей и не нужно следить за номером своей очереди на табло. Пока клиент открывает дверь отделения, заходя в него, камеры ещё на входе уже распознают его лицо. Клиент не успевает дотянуться до терминала, как тот его приветствует по имени, ставит в очередь в автоматически и отправляет пуш-уведомление прямо в приложение: «Просто присаживайтесь, наш менеджер сам подойдет к вам».
Как это выглядит вживую.
Первый такой офис мы открыли в 2020 году и хотели вызвать вау-эффект. Но со сбором биометрии возникли проблемы — клиенты не спешили соглашаться на использование своих биометрических данных. А если клиентов мало, то вау-эффекта не получится: система никого не «узнает».
Тогда команда Growth Hacking предложила свою помощь. Мы запустили 11 гипотез за 1 неделю и увеличили количество клиентов, которые сдают биометрию, больше чем в 2 раза.
Как? Просто быстро перебрали 11 вариантов гипотез ценностей сдачи согласий. Отдельный вариант в виде баннера с различными текстами при входе в приложение показывали группе в 30 000 клиентов (статистически достоверному подмножеству). Победитель на картинке.
Выглядит слишком просто, чтобы об этом и рассуждать? Да, но есть нюансы.
Проект Face ID был очень значимым для продвижения инновационного бренда Альфа-банка. За успехом проекта в 2020 году следили и акционеры, и пресса. Но при этом за 3 месяца работы над проектом продуктовая команда смогла поднять конверсию в сдачу биометрии лишь на 40%.
Это ни в коем случае не упрёк команде. У них много работы: написать функционал, согласовать, обеспечить интеграцию, обеспечить масштабирование, баги зафиксить. Какие там гипотезы, не выгореть бы, и то хорошо.
И вот поэтому «занудную» работу по тщательному перебору множества гипотез, аналитике и подсчету данных и берёт на себя команда GH, тестируя их, не поднимая головы. Команда GH сосредоточена только на тестировании гипотез, и банально быстро их перебрав, нашла самую эффективную.
Так и подняла конверсию не на 40%, а больше чем в 2 раз, и не за 3 месяца, а за 7 дней.
Как достигается скорость запуска гипотез с технической стороны? Гипотезы запускаются в виджетах, которые определяются на уровне конфигурации приложения, а не кода. Поэтому нам не нужно ждать релизного цикла в сторах.
Более сложные интерфейсные «поделки», например, виджеты онбординга — это WebView. Мы программируем их на простом конструкторе сайтов (no-code) и вставляем в приложение. При этом пользователям кажется, что это часть приложения.
Если в UI требуются какие-то алгоритмические действия, то их разнообразие мы сводим к минимуму за счет специфических узких выборок (когорт) пользователей.
Мы не тестируем полноту алгоритмов — только предлагаемые ценности небольших MVP.
Почему скорость важна? В прошлом году мы запустили 230 гипотез в Альфа-Мобайл. В этом мы провели ретроспективу и увидели интересную статистику.
Только 2 гипотезы из 10 приводят к значимому результату. Под значимым результатом мы подразумеваем рост целевых показателей от 30% до 300%.
Получается, что если одна команда роста запускает 5 гипотез в неделю, то статистически одна из них даёт результат и к концу каждой недели команда приходит с маленькой победой. Такая частотность небольших (а иногда больших побед) весьма мотивирует и продуктовые команды и менеджмент.
Но что если гипотезы запускает только продуктовая команда? По нашим наблюдениям, под давлением сроков и необходимости сдачи качественного продукта, продуктовая команда может позволить себе запустить 1-2, ну самые отчаянные, бывает, стреляют и по 4 гипотезы в месяц.
Получается, что значимые точки роста находятся только раз в 1-2 месяца. А на таком промежутке менеджмент начинает весьма расстраиваться. Как это и было с Face ID: вроде все работают, а результат маленький.
Именно поэтому нужна выделенная команда на гипотезы, чтобы просто быстро их перебирать.
Тестирование гипотез позволяет принимать решение о продуктах и определять их сценарии
В прошлом году телефонные мошенники похитили у людей 45 млрд рублей. При этом половина из пострадавших добровольно сообщили все свои данные карт, коды, пароли. Если бы они не получили звонок, то, скорее всего, не потеряли бы деньги.
Поэтому в банке родилась идея интегрировать продукт WhoCalls от Лаборатории Касперского в приложение банка. Он позволяет отсекать значимое количество звонков мошенников, спамеров и прочих личностей, от которых вам не нужны звонки.
Разгорелись жаркие дискуссии «менеджмента»: «А будут ли включать пользователи эту опцию, а много ли их будет, а окупится ли эта интеграция?»
Если есть вопросы окупится или нет — давайте это проверим? Что мы сделали? Ещё до начала разработки мы за день запустили всего одну гипотезу — предложили пользователям включить определитель номера в приложении. Пример на картинке.
Результат удивил. Готовность пользователей к подключению составила 12%. Это один из лучших показателей конверсии среди всех наших гипотез.
Мы использовали эту цифру конверсии, данные о среднем размере мошенничества, эффективность WhoCalls и посчитали сколько денег клиентов может сохранить этот продукт. Когда мы показали цифры менеджменту, то ответ был — да, конечно, внедряем!
Примечание. Реальная конверсия после внедрения соответствовала полученной в ходе запуска теста.
Если идти ещё дальше, то с помощью гипотез можно принимать решение не только о внедрении приложения или фичи, но и находить ключевые сценарии продукта, который ещё и «посадить» некуда.
Попробую объяснить. Посмотрите на картинку.
Здесь показаны 3 гипотезы из 50, которые мы запускали, чтобы понять, какие из множества сценариев нового продукта «Моментальное бюджетирование» важнее для пользователя. На картинке вы видите рекламные баннеры, которые мы запустили на рекламной площадке без упоминания бренда и приложения. Никакого продукта нет, есть только идея.
Результаты тестов помогли нам сформулировать цель MVP простым перебором самых конвертируемых ценностей и контекстов использования. И поэтому, вместо того, чтобы делать все 3-4 сценария нового продукта, проверять их, мы выбрали только один — самый важный для большинства будущих пользователей. В данном случае — это комфортно снижать спонтанные расходы. Его мы реализовали уже в сложном, работающем MVP, который уже и окончательно доказал значимый рост вовлеченности пользователей MVP в мобильное приложение банка.
Growth Team: «не верь, не бойся, не проси»
Наверно для таких результатов нужна большая команда? Нет. Но команда нужна отчаянная. Вот портрет нашей первой команды роста.
Команда компактная — всего 3 человека. Но самодостаточная. Её главный лозунг — «не верь, не бойся, не проси».
«Не верь» — проверяй всё на тестах. Мнения, даже свои, игнорируй.
«Не проси» — делай всё сам. Не жди разработчиков из продуктовой команды — придумывай воркэраунды. Не жди дизайнеров — нарисуй как нибудь сам. Не жди прекрасных данных от BI — ищи альтернативы.
И теперь — про «не бойся».
Бешеные хакеры. Однажды мы хотели понять насколько важно пользователям получать уведомления о том, что им пришла квитанция ЖКУ, чтобы приоретизировать (или деприоретизировать) эту затратную задачу. Мы запустили на выборку в 30 000 клиентов оповещение: «Вам пришла квитанция ЖКУ» (хотя квитанции на самом деле не было).
Рост переходов на выбор поставщика вырос в 65 раз! Клиенты даже на 33% больше заплатили, чем контрольная группа. Такого всплеска мы больше нигде не встречали.
С помощью этой гипотезы мы узнали, что самые сумасшедшие гипотезы не перегружают колл-центры.
У колл-центра было 30 (!) звонков на второй уровень поддержки из-за этой гипотезы. При выборке в 30 000 человек — это ничто, колл-центр даже не поморщился. Конечно, мы предупредили, как отвечать клиентам в случае звонков. И, конечно, у нас был «стоп-кран», чтобы откатить гипотезу, если звонков будет неадекватно много.
Но ничего страшного не произошло. И это сделало смелее не только нас, но и ещё усилило культуру экспериментирования и толерантности к ошибкам в Альфа-Банке.
К команде Growth Hacking стоят в очереди. Когда мы научились быстро запускать гипотезы и выдавать частые «маленькие победы», популярность и запрос на Growth Hacking в банке возрос. Не хвастаемся, но к нам буквально стали становиться в очередь. Вот статистика нашей загрузки. Красное — активные проекты. Белые — в очереди.
То же самое ждёт и вас, если вы сделаете ваши команды роста — они всегда будут загружены. Либо вы будете всегда загружены, если вы сами хотите работать в команде роста.
Причина такого успеха проста — всем больше нравятся частные, пусть и небольшие победы, чем большие обещания, которые может никогда и не произойдут.
Итог: так зачем нужна команда Growth Hacking?
Эффект. Всего 3 человека команды роста могут приносить прибыль в несколько сотен тысяч долларов в год от отдельного проекта, над которым они работают 3-4 месяца.
Экономия. В среднем — от 1 до 3 командо-месяцев за счет того, что команды, приносящие неясные по эффективности идеи на тестирование не делают лишнего.
Скорость. 20 гипотез в месяц на 1 команду роста — это 4 удачных гипотезы. Как говорят в народе: «лучше сорок раз по разу, чем ни разу сорок раз».
Наш опыт можно применить как в корпорациях, так и стартапах.
Ну и конечно, хочется поблагодарить Юрия Дрогана и его Growth Academy, которые научили нас этому подходу и давала нам поддержку в самые трудные времена.
Статья создана на основе моего доклада на Growth Hacking Meetup. Если вам удобнее смотреть, чем читать — прикладываю видеозапись (там есть ещё другие интересные доклады).
Если интересны наши проекты — приходите к нам работать, вакансии выкладываем на странице вакансий. Например, сейчас в разные команды нам требуются ведущий системный аналитик, СХ/UX-исследователь или дизайнер цифровых продуктов.
Статьи, которые будут интересны:
Альф, переведи мне на телефон миллион рублей, Или нюансы тестирования (и разработки) голосового помощника в банковском приложении.
Как мы управляем техническим долгом аналитики.
