ProductCamp

20 февраля 2023

#Кейсы 10
#Growth PM 3

Growth команда - внутри продукта или отдельная структура? 

image

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

О спикере

userImage
Product Owner
Илья Болтнев
Райффайзен Банк

Я product owner в команде Retail Lending Райффайзен Банка:

  • 70% кредитов выдаются быстрее, чем принесут пиво в баре
  • онлайн заявка на кредит признана лучшей на рынке (Банковское обозрение)
  • продукт признан лучшим в категории «Потребительские кредиты» (Банки.ру)
  • два года подряд онлайн продажи кредитов растут кратно
  • делаем получение кредита таким же быстрым и удобным, как покупка в лучших интернет-магазинах

Мы подходим к кредиту, как процессу, по сути, аналогичному покупкам в интернет-магазине. Наша цель сделать кредитование таким же простым, как покупка в самых лучших интернет-магазинах, потому что процесс тот же самый и таким же легким, как в e-com.

О чем поговорим:

  • Есть ли разница между Growth командой и обычной продуктовой?
  • Псс! У нас есть Growth-hacking! Фабрика "грез" гипотез в разрезе.
  • Личный опыт или путешествие туда и обратно.
  • Кому все это нужно?
  • Что делать? Отдельную команду роста? За и против.
  • "Кто виноват?"

Что такое growth команда?

Growth команда - это команда, которая пытается найти способы, как быстро улучшить ключевые метрики продукта и бизнеса:

  • увеличить количество лидов, средний чек, прибыль с продажи
  • повысить активацию
  • снизить потери в воронке
  • уменьшить отток пользователей

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

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

Фреймворк команды роста

1. Сформулировать модель роста

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

Например, модель роста банка. Она состоит из трех уровней:

  • мы привлекаем людей на самый простой продукт (привлечение новых клиентов на дебетовую карту или зарплатный проект)
  • вовлекаем пользователя через daily banking, через самые частотные операции, которые формируют лояльность пользователя
  • монетизация через cross-sell на разные типы продуктов: кредитных, инвестиционных продуктов либо еще какие-нибудь.

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

2. Исследования и аналитика

Второй пререквизит, перед тем как команда роста начинает что-то делать, это аналитика. Без этого гипотезы не строятся и понятно, что мы используем все возможные источники данных для того, чтобы над ними строить какие-то предположения и гипотезы.

Многие знают про цикл HADI, который почему-то во многих местах начинается с гипотезы, потом действие, аналитика и инсайт. На мой взгляд это не совсем корректная история.

image

На мой взгляд корректный цикл такой: мы сначала делаем исследования (свои воронки, рынки, конкуренты и что угодно), потом из этих данных у нас возникают инсайты, на основе этих инсайтов  мы строим гипотезы (как мы можем что-то улучшить, увеличить или наоборот убрать проблемы, дальше тестируем и на основе этого у нас появляется анализ и какие-то выводы  

image

И что дальше?

Что получается на выходе, какой growth процесс?

  • получается много гипотез, мы конечно хотим, чтобы они были быстрые в запуске, но это не всегда так получается
  • жесткий критерий про успешность, потому что, зачастую мы стараемся делать тесты, которые сразу не очень запустились и придали какое-то маленькое изменение, мы еще хотим почему-то довести просто до того, чтобы он добрался до стат-значимости, а время это самый главный ресурс у нас, поэтому если гипотеза не дает сильный результат, смысла дотягивать до стат-значимости нет. 
  • покер-приоритезация, очень редко, когда ты можешь сказать в гипотезе, какой она даст реальный value, пока ты ее не протестировал, ты не знаешь какая будет дельта в метриках, и поэтому это естественно покер-приоритезация на уровне экспертизы продактов, которые этим занимаются 
  • куча фейлов, естественно, конверсия успешных гипотез хорошо, если 1 из 10.
  • намытые крупицы "золота" успешных идей, которые наконец-то пополняют бэклог команды на масштабирование.

Какие здесь подводные камни?

  • Постоянно растущий бэклог продуктовой команды на масштабирование успешных гипотез
  • Растущие затраты на проведение тестов гипотез - низко висящие яблоки быстро съедаются.
  • Возникновение зависимостей на бэклог продуктовой команды. Или необходимость инвестировать в развитие/дублирование архитектуры.

Что у нас было?

Чтобы не быть философом-теоретиком, я хотел бы поделиться нашим кейсом, как это произошло. 

Дано: В начале у нас была команда потребительских кредитов

  • основные KPI - счастье пользователя в виде NPS, счастье банка в виде прибыли и показатель роста в виде объема выдачи
  • привлечение клиентов на командах маркетинга (ТВ+outdoor) и digital маркетинга
  • возврат существующих клиентов на команде CRM
  • продажи через контакт-центр и отделения. В какой-то момент стратегия банка фокусируется на концепции digital банк. Команда продолжает выполнять планы продаж, но digital канал продаж развивается очень медленно
  • рост сфокусирован на том, где уже есть экспертиза – CRM, контакт-центр и отделения

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

Создали команду Digital кредитования

По сути - Growth команда, сфокусированная на кратном росте привлечения новых клиентов из онлайна.

Состав: 2 продакта, 2 бэкенд-разработчика, фронтенд-разработчик, тестировщик, системный аналитик, девопс, скрам-мастер. Работаем в Scrum, 2-недельные спринты. Фокус на первый период - конверсия из визита в заявку.

Для тех кто не знает как выглядит процесс кредитования, у нас он выглядит так. Не легкий процесс. И наш фокус был здесь - заполнение заявки на кредит занимает много времени. Была очень тяжелая заявка 5%, где-то интернет-магазины могут позавидовать такой конверсии, но банки нет.

image

Прошло полгода

  • Тестируем варианты лэндингов и форм заявок. Плохо умеем в fake тесты – ограничения по legal и теряются продажи
  • Проблемы: ограничения со стороны архитектуры кредитного конвейера, зависимость на бэклог основной команды продукта.
  • Решение: строим свой велосипед для digital процесса. Команда разрастается до 2 feature команд, переходим в LeSS.

Скорость тестирования 1-2 гипотезы за спринт.

Прошел год

  • В команду приходят два маркетолога. Увеличиваем тесты вариантов лэндингов, форм заявок и каналов привлечения.
  • Создаем платформу для большего кол-ва вариантов а/b тестов.

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

Скорость тестирования увеличивается 2-3 гипотезы за спринт.

Проходит еще полгода

  • В KPI команды помимо цели на привлечение новых клиентов добавляют NPS и прибыль.
  • В команду приходят affiliate маркетолог, full-stack аналитик (веб+продукт).
  • К концу первого полугодия растем в лидах х5 год к году и … захлебывается нижняя часть воронки.

Скорость тестирования 2-3 гипотезы за спринт.

Очевидная проблема сверху стало много, а внизу не масштабировались и все захлебнулось. Получается, что процент конверсии от заявки на сайте до выдачи 0,5%. Среднее время получения кредита новым клиентом - 10 дней. Курьеры ездят медленно, звонки происходят тоже медленно. 

Прошел еще год

  • Переносим фокус на рост конверсии от одобрения до выдачи.
  • В тестах начинаем упираться в объемы выборок.
  • Релизим новый digital кредитный конвейер, получаем полную свободу тестирования любых гипотез.

За год вырастаем х3. Доводим долю продаж канала до 20% от общей, по сути, перестаем быть Growth командой, трансформируясь в кросс-функциональную продуктовую команду, со своей архитектурой, которая научилась делать гипотезы, тестировать их и внедрять..

Скорость тестирования увеличивается до 3-5 гипотез за спринт. 

Что в итоге?

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

Следующие шаги

  • Обе команды потребительских кредитов + команда ипотеки объединяются в одну команду розничного кредитования (LeSS Huge: 9 feature teams)
  • Определение продукта расширяется
  • Продуктовые практики и опыт работы с гипотезами наследуются из команды роста
  • Быстрее делаем приоритетные вещи, уменьшаются дублирование и зависимости.
  • Фокус роста фиксируется на квартал.

На выходе получилась большая полно-функциональная команда, в моменте 70 человек. Это не очень гибко кажется со стороны, мы работаем в фреймворке LeSS Huge, то есть у нас есть один бэклог, две продуктовые области требований для потребов и ипотеки, мы можем перекидывать команды "фичи тимы" между продуктами.

Всем ли продуктам полезна Growth команда?

На мой взгляд ключевой вопрос, "а вам нужен рост?". Рост нужен практически любому продукту.

Есть ли смысл делать отдельную Growth команду?

С отдельной командой вопрос, есть "за" и "против".

ЗА:
- хочется придать ускорения сразу нескольким продуктам или процессным командам
- нет возможности в продуктовую команду взять необходимые экспертизы
- продукты и их команды разрознены и обмен знаниями и опытом затруднен
- бэклог продукта до отказа забит приоритетными задачами и времени на генерацию гипотез не остается

ПРОТИВ:
- время на погружение в специфику отдельного продукта, его ценность и целевой аудитории
- зависимость от продукта на проведение тестов
- стоимость переключения между продуктами
- дублирование архитектуры или функций с продуктом
- непонимание у людей если появляется команда роста, то чем занимается команда продукта?

ИМХО. Мое личное мнение.

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

Смотреть доклад в видео формате 

Присоединяйся к чату комьюнити

Будь в курсе всех новостей, обращайся за помощью к коллегам и находи единомышленников!

Заходи в чат