Як онбордити гроуз-менеджера: гайд від Sr. Growth PM у Vimeo Руслана Назаренка

Онбординг будь-якої людини — класна можливість заметчити очікування компанії та нового працівника. Очевидно, що процеси відрізняються залежно від того, перший це гроуз-менеджер чи ні. Але є кілька моментів, які будуть доволі схожими і при цьому різними в онбордингу PM, інженера чи аналітика. Куратор Growth у Projector та Sr. Growth PM у Vimeo Руслан Назаренко ділиться своїм досвідом онбордингу: від дійсно класного до кількох невдалих.

Траєкторія для онбордингу №1: люди

Оскільки growth — це про роботу з маркетологами, продуктовими менеджерами, аналітиками і ще цілою купою людей, тут практично не буває проєктів, де не було б зовнішніх стейкхолдерів. Чим більша компанія і чим вищий тайтл, тим важливіше правильно керувати відносинами з цими стейкхолдерами. Щоб розпочати цей процес, при знайомстві з кожною новою людиною варто поставити низку запитань. Ці речі дуже класно описав Маркіян у цій статті, а я б додав лише кілька, які релевантні саме для гроуз-менеджера:

• Які KPI/OKR у тебе та в твоєї команди на цей квартал/рік?
• Які найбільші челенджі у тебе є?
• Завдяки чому зростав твій продукт? Чи є у вас PMF? Як ви зрозуміли, що є?
• Які основні джерела трафіку зараз працюють? Який у вас ретеншен? Чи вийшов він на плато?
• Які твої очікування від роботи зі мною?
• Як до цього ти працював із гроуз-командою? Що було позитивним досвідом, а що можна покращити?

З боку компанії варто підготувати перелік ключових людей з їхніми посадами та буквально однією фразою, чому з цією людиною варто поспілкуватися. Ці ж запитання можна включити в онбординг-гайд — вони допоможуть зрозуміти, хто може бути чемпіоном для майбутніх проєктів, від кого очікується пушбек, а з ким варто запланувати спільний проєкт і пошерити ресурси пізніше в цьому кварталі.

Траєкторія для онбордингу №2: інфраструктура

Та сама частина, що відрізняється від інших спеціалістів. По-перше, потрібні будуть доступи до аналітики, рекламних кабінетів, CRM і, цілком імовірно, БД. Тобто, скоуп виходить приблизно як для продактів плюс аналітиків/інженерів. Але це ще не все. Святий грааль тут, звичайно, система для запуску експериментів. І неочікувано, вона має бути. Дивно про це говорити в 2022 році, але все ще є ціла купа компаній (включно з великими), де цього або немає, або воно працює якось дуже незрозуміло.

В ідеалі система запуску експериментів повинна включати три важливі елементи:

• рандомізатор — те, що розкидатиме користувачів по тестових групах;
• фічер-флагінг — те, що відповідає за те, чи показувати фічу або приховати її для користувача;
• статистичний двигун — те, що рахуватиме p-value та інші важливі метрики.

Якщо принаймні чогось одного з цього немає, треба бути готовим, що перші кілька тижнів/місяців робота гроуз-менеджера гальмуватиметься через відсутність можливості запускати ті самі експерименти.

І до хороших новин. Навіть якщо цієї системи немає, можна обійтися милицями на перший час. Для рандомізації можна використовувати CRM-ку (особливо, якщо це щось на кшталт Braze/Iterable) — для цього треба запустити тест на стороні відправника розсилки, але замість емейлів, використовувати webhook-и, які будуть надсилати користувача в control або treatment групи. Ловити їх на сервері та вмикати/вимикати фічу для цього користувача. Рішень для фічер-флагінгу на ринку вистачає, включаючи оупенсорсні, тому з цією частиною проблем бути не повинно. А рахувати p-value спочатку можна просто через SQL, без гарненьких дашбордів у Tableau (що, звичайно ж, не так швидко/приємно, але що ж).

Траєкторія для онбордингу №3: дані

Сенс роботи гроуз-менеджера можна спростити до «знайти проблему, відповісти на запитання, чому вона там, протестувати кілька рішень і розкачати переможця на всю популяцію». Тут немає жодного слова про креатив, вигадування ідей з пальця і ​​ось це все. Гроуз-менеджерам потрібні дані. Майже всі, так. Це та частина, яку доведеться пропрацювати до найму — немає сенсу намагатися щось приховати/не показати, немає сенсу воювати з CFO — всі ці дані будуть потрібні.

Окрім кількісних даних, треба опрацювати (якщо ще немає) процес збору якісних – користувацькі інтерв’ю чи опитування. З усім цим можуть виникати провтики. Чи ми збираємо дозвіл від користувачів на комунікацію? Чи можемо ми легко дістати людей, які нам потрібні? Чи робимо ми це інхаус або використовуємо платформи на кшталт userinterviews.com? Незважаючи на те, що завдання гроуза — отримати максимум з того, що є, «що є» має включати можливість безперешкодно отримувати дані, потрібні для роботи.

На жаль, часто бачу на курсі студентів, яким дали модну посаду, але не дані. На жаль, так воно не працює.

Траєкторія для онбордингу №4: цілі

Так само як для компанії може бути важливим бачити якісь відчутні результати якнайшвидше, так і для нових членів команди важливо розуміти, чи впоралися вони з навантаженням. Як і в будь-яких відносинах, проблему можна вирішити через комунікацію. З одного боку, співробітнику треба підготувати план на 7/30/60/90/360 днів, з іншого — робити регулярні 1-on-1 дзвінки з менеджером. При цьому, почати можна з дзвінків щодня/через день і через кілька тижнів зменшити до одного-двох на тиждень.

Ось тут виявляється ще одна різниця гроуз-менеджера від найму інших людей. Коли ви наймаєте продуктового менеджера, швидше за все, у вас є ідея нового продукту або фічі, які треба будувати. З гроуз-менеджером постановка мети зазвичай зводиться до «ну, нам треба якось рости» (очевидно, що ситуація змінюється кардинально, якщо це не перша людина в команді гроузу). Перш ніж гроуз-менеджер посидить із даними і поговорить із користувачами — можна не чекати проривних ідей. Звичайно, з досвідом можна побачити якісь видимі можливості, прийшовши на новий проєкт, але це радше виняток, ніж правило.

Найкращий онбординг, який у мене був, включав запуск перших тестів ще в перший тиждень. Звучить досить дивно (і так воно й є), якщо дивитися на це з точки зору «ну на який апліфт можна чекати від таких тестів». Але ідея тут у тому, що можна дуже довго копирсатися в даних та прокрастинувати. Для цього існує навіть визначення.

Також, особливо у великій компанії, можна загрузнути у знайомстві з цілою купою людей, які колись можуть стати в пригоді (або ні). Коли ви озвучуєте очікування про запуск тесту в короткий термін, ви буквально змушуєте нового менеджера під час інтро-дзвінків збирати відсутні ввідні від інших команд/людей, досить оперативно знайомитися з платформою для запуску експериментів і швидко опрацьовувати великий обсяг даних. Це суттєво прискорює сам онбординг. Але, важливо пам’ятати, що у новачка може виникнути додатковий стрес, тож ставте таку мету на 7-14-30 днів.

Якщо компанія велика, реально очікувати, що за перший місяць менеджер познайомиться з основними стейкхолдерами, розбереться з інфраструктурою і запустить перші кілька тестів. Це дасть хороший плацдарм, щоб вибрати вектор руху на перші 3-6 місяців, чи то залучення користувачів, чи то робота з їхнім поверненням. Залежно від тайтлу, ціль на рік може звучати як максимально абстрактно — вийти на 20% зростання MoM/вийти на $25M MRR, так і конкретніше — отримувати 20% трафіку з реферальної системи.

Перший раз для компанії: як бути

Якщо це перший досвід компанії з наймом гроуз-менеджера, є кілька речей, до яких варто бути готовими.

• Інженери — для запуску експериментів, потрібні events/users’ properties (для тригерів та сегментації) або створення нового функціоналу. У будь-якому разі інженерні ресурси будуть необхідні. Без можливості їх виділяти для гроуза краще таку людину поки не наймайте. Крім того, інженерам варто прокомунікувати, що велика частина фіч, створених під експеримент, буде безжально знищена відразу після. Тож не варто витрачати місяць, щоб написати залізобетонну конструкцію, яка витримає мільйони користувачів, коли є велика ймовірність, що її випилять після тесту на кілька тисяч людей.

• Продуктові менеджери — чи буде гроуз частиною продуктової команди чи окремою функцією в компанії? Треба заздалегідь прокомунікувати очікування та процеси з продуктовими менеджерами. Іноді можна зіткнутися з проблемою, що РМ не виділяє ресурси або пріоритезує завдання гроуз-менеджера. Звичайно, це може сигналізувати про цілу купу проблем, тож варто переконатися, що це не особистий егоїзм окремого РМа. Що трапляється частіше, ніж напад егоїзму, — розбіжність поглядів продуктового та гроуз-менеджера на UX. Це саме та частина, яку можна розмежувати досить сильно. За будь-яку комунікацію через емейли/пуші/інапи відповідає гроуз-менеджера і доти, поки це не сильно погіршує основні метрики продукту, РМ може виступати в ролі консультанта, але навряд чи має право накласти вето на експеримент від гроуз-команди.

• Стадія розвитку продукту — гроуз-менеджер не допоможе знайти product market fit. Ця посада про мультиплікатор. Якщо ваше зростання 0%, то навіть помноживши його на 100, й далі буде нуль. Якщо у продукту немає ретеншну або зростання, варто подумати про маркетологів або РМів, які допоможуть півотнути продукт у потрібний ринок для початку, і тільки потім будувати функцію росту. Сюди ж трафік. Якщо продукт ще маленький і на будь-який експеримент нам треба чекати результати два місяці, більшу частину часу гроуз-менеджер буде просиджувати і це не має сенсу.

Автор: Руслан Назаренко, Sr. Growth PM у Vimeo та куратор Growth у Projector