Как построить сильную продуктовую команду? Опыт Head of product Aitarget One

Привет! Я Ксюша Михайлова, руководитель команды продукта в Aitarget One. За пару лет нам удалось превратить MVP в виде сайта с «окошком» для ввода данных — в веб-платформу с крутой автоматизацией. Хочу рассказать, как это было и какие выводы мы делали на разных этапах.

Наш продукт родился внутри Aitarget как отдельное направление для малого и среднего бизнеса, когда компания уже была партнером Facebook и работала с крупными клиентами.

Это был челлендж — создать и развить продукт в сильной компании, но вообще с нуля.

В итоге у нас есть платформа для официальной оплаты всей интернет-рекламы в одном окне, инструменты для анализа и оптимизации кампаний, самостоятельное партнерство с Facebook и Google и не только.

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

Обо всем по порядку.

Наш путь начался с реселлинга рекламы на Facebook. Мы знали об этой боли клиентов и могли ее решить – оформлять закрывающие документы на оплату рекламы.

Для тех, кто не погружен в тему: Facebook до сих пор не предоставляет закрывающие документы, из-за чего рекламодатели не могут оплачивать рекламу с расчетного счета, учитывать расходы и получать налоговый вычет. Подробнее коллеги рассказывали в материале Aitarget One на vc.ru.

1 апреля (это не шутка) 2019 года мы выпустили MVP. Создали сайт, на котором можно было только зарегистрироваться и выставить счет на оплату. Основную работу вели в переписке с клиентом. Наш менеджер (первое время — я сама) писал клиенту на почту и запрашивал нужные данные, а затем отчитывался по каждому этапу: «Сейчас мы создадим вам аккаунт», «Мы пополнили ваш кабинет», «Документы готовы» и так далее.

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

На старте в команде были я и 2 разработчика. Дизайн мы заказывали на аутсорсе.

После успешного теста MVP мы начали расширять команду. В первую очередь, наняли дизайнера. Поскольку наш продукт развивался в конкурентной среде, нам важно было сделать максимально удобный, красивый и понятный интерфейс. Без классного UI у нас просто не получилось бы состязаться с крупными компаниями, которые уже утвердились на рынке.

Путь выстраивания процессов мы прошли примерно два года назад, когда только собирали команду. Я тогда читала отраслевые СМИ и блоги и консультировалась со своими знакомыми из индустрии. Какие-то идеи мы придумывали сами и сразу тестировали: когда команда маленькая, можно просто договориться пожить пару недель «в новой реальности».

Методология разработки

Я совру, если скажу, что мы долго мешкались с выбором методологии разработки. От Waterfall мы отказались сразу же. Пытаться построить космический корабль по строгому плану без возможности отказаться от каких-то идей — это совсем не наша история. Мы за гибкость (это, кстати, одна из основных ценностей Aitarget), поэтому выбрали Agile-подход.

Работать начали с недельных спринтов по Scrum. Затем поняли, что под наши задачи такого срока не хватает, и удвоили его.

У нас есть все соответствующие Scrum атрибуты:

• мы проводим ежедневные стендапы, на которых встречаемся или созваниваемся с командой на 15 минут, чтобы понять, как у кого дела;
• есть встречи для планирования, когда мы садимся с разработкой и дизайном, чтобы разобрать задачи, которые хотим реализовать;
• в конце спринта мы собираемся на ретроспективу и обсуждаем, что удалось и не удалось сделать и почему;
• раз в две недели мы проводим демо — встречаемся с маркетингом, sales & support, руководителями, HR, финотделом и делимся апдейтами и значимыми цифрами.

Оценка продуктивности

Разработчики оценивают задачи по последовательности Фибоначчи. Цель — не подсчитать точное время на реализацию, а оценить сложность каждой задачи относительно других.

Числа Фибоначчи (1, 2, 3, 5, 8, 13…) в этом круто помогают — разрыв в 2-3 и более баллов (поинтов) более наглядный, чем разрыв в 1 балл. Очевидно, что задача с ценностью 8 поинтов значительно сложнее, чем задача на 5 поинтов. А разница между задачами на 5 и 6 поинтов была бы не такой явной.

В результате, у нас есть примерное понимание капасити команды. Перед началом спринта мы видим оценку по задачам и понимаем загрузку разработки: очень много (что-то придется выкидывать), в самый раз или ребята недогружены и можно заняться рефакторингом.

Всю нашу работу мы привязываем к бизнес-целям. Внутри команды продукта мы декомпозируем их по зонам ответственности. Для разработчиков — это скорость разработки, своевременность закрытия спринтов, количество ошибок, контрибьюшн в проекте, масштабируемость решения. Для продактов — динамика по ключевым метрикам (конверсии, churn rate, WAU, MAU) + количество проверяемых гипотез.

Формирование бэклога

Сейчас мы каждые 2 недели смотрим на бэклог задач и что-то перепридумываем, что-то выкидываем, ставим приоритеты и, в целом, супергибко подходим к планированию. Для этого у продактов есть специальная встреча — Pre-planning.

Все будущие таски должны быть описаны по структуре:

1. Указаны проблема, гипотеза и потенциал фичи.
2. Прописана цель — краткое описание того, что нужно сделать.
3. Приведён to-do лист — основные этапы работы.
4. Составлено ТЗ.
5. При необходимости приложены ссылки на внешние ресурсы.

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

Важный момент — всем задачам мы ставим приоритет. На заре бизнеса, когда продукт был совсем зеленый, было очевидно, что делать дальше. Сейчас у нас больше продукт, больше команда, больше направлений бизнеса — теперь без приоритизации совсем никак. Мы комбинируем оценку по ROI и RICE.

К нынешней структуре работы с бэклогом мы пришли не сразу. Вот что тестировали:

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

• Проводили груминги еженедельно. Груминг — это командная встреча для обсуждения («причесывания») бэклога и выяснения деталей по задачам. Нередко такие встречи превращались в дискуссии без конкретных решений. Теперь мы проводим груминги по потребности, а не потому, что в календаре стоит встреча.

Инструменты

Мы постепенно составляли свою комбинацию из инструментов для команды продукта. Что-то уже давно используется в рынке (например, Jira), что-то мы нашли и протестировали сами.

1,5 года назад мы поняли, что пора расширять команду продакт-менеджеров и делить зоны ответственности.

Причина 1. Мы хотели расти ещё быстрее и нам нужны были дополнительные ресурсы, чтобы тестировать больше гипотез, доносить их до разработки и выпускать в продакшн.

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

Летом 2021-ого нас, продактов, в команде стало трое:

• я руковожу продуктом и отвечаю за бизнес-процессы, стратегические проекты, разработку новых инструментов;
• один продакт-менеджер отвечает за retention — делает все, чтобы продукт приносил максимум ценности и клиенты оставались с нами как можно дольше;
• другой продакт отвечает за acquisition — то есть за все, что происходит с пользователем до того, как он нам заплатил.

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

Каждый продакт отвечает за определенную метрику и в рамках своей рутины смотрит на данные, проводит кастдевы, читает Telegram-каналы или Facebook-группы, где сидит наша целевая аудитория, и оттуда выцепляет инсайты.

1,5 года назад мы перепридумали процессы и начали вести бизнес-документацию по продукту в Confluence. Не замыкать знания на одном продакт-менеджере — это архиважно! Иначе проблемы копятся в снежный ком — продакт увольняется, а другие члены команды, как слепые котята, тыкаются в интерфейсе сами или дергают разработчиков, чтобы понять, как работает фича и какой эксперимент сейчас идет.

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

Нам скоро будет 2,5 года и мы ежегодно растем х6 в деньгах и количестве клиентов. Такой рост был бы невозможен без классных людей!

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

Мы ввели 3 практики, которые решили проблему с наймом:

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

• Мы обязательно даём тестовые задания. Когда-то мы нанимали ребят без предварительного тестирования и укололись. По общению можно понять, что человек в теме, а тестовое задание показывает то, как он выполняет реальные задачи, как мыслит, на что обращает внимание. Сейчас мы даём ТЗ для всех позиций: разработчикам — написать функционал (или, как минимум, показать свой код на github); дизайнерам — нарисовать новую фичу; продактам — решить кейс.
• Мы проводим персональные ротации новенького с каждым нашим сотрудником, чтобы рассказать, кто чем занимается в команде. С одной стороны, это позволяет пообщаться лично, получше узнать друг друга, а с другой — помогает узнать про разные стороны продукта изнутри. Такие персональные ротации мы проводим с конца 2020 года, когда начали активно расширяться, «старичков» становилось все меньше и нужно было сделать так, чтобы новый сотрудник быстрее встроился в процесс.

Сейчас над развитием Aitarget One трудится большая классная команда. В продуктовом отделе три продакта, несколько разработчиков и дизайнер, у нас целый отдел маркетологов (всё серьёзно: есть перфоманс- и контент-маркетологи и даже собственный event-менеджер) и отдел клиентского сервиса (это наши sales и аккаунты). А ещё у нас есть HR-менеджер, который находит классных людей, и бухгалтеры, которые делают красивые и юридически грамотные документы.

У нас общие цели по деньгам и клиентам на три отдела (маркетинг, продажи и продукт) — это позволяет нам двигаться в одном направлении и не конфликтовать, ведь у всех одинаковый критерий успеха.

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

Верю, что скоро нас станет больше. Прямо сейчас мы ищем Frontend-разработчика и аналитика.

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

И второй классный ритуал — мы стараемся всей нашей продуктовой командой собираться на ланч. Говорят, совместный прием пищи сближает. У нас это 100% работает.

Мы получаем большое удовольствие от совместного прихода в офис (делаем это 2-3 раза в неделю) — вот настолько нам круто! Хотя многие из нас интроверты или любят работать удаленно.

Два совета. Один как от продакта, а второй как от менеджера:

1. Задавать себе каждый день вопрос «А не фигню ли я делаю?»

9/10 идей продакта оказываются дичью — sad but true. Главное — вовремя осознать это, отказываться от лишнего и чутко скорить то, чем занимается команда сейчас.

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

Обратная связь для нас особенно важна. У нас в коллективе и во всей компании очень комфортная и нетоксичная среда. Это спасает от ситуаций, когда проблемы и претензии просто замалчиваются.

Все новички Aitarget проходят тренинги по фидбеку. Также на испытательном сроке у нас есть встречи через месяц и через 2,5 месяца, которые мы проводим совместно с HR. Мы спрашиваем, что получается и не получается у нового сотрудника, как он чувствует себя в команде, какая помощь ему нужна, и даем комментарии по работе.

• Гибкие методологии — must-have для быстро растущей компании с большим потенциалом, не стоит загонять себя в жёсткие рамки.
• Встречи, которые скатываются в долгую дискуссию, — пустая трата времени.
  
• Фокус команды должен быть на текущем спринте, не нужно лезть раньше времени в бэклог.
  
• Нужно приоритизировать задачи по ROI/RICE, чтобы не сливать ресурс на мелочи.
  
• Тестовое задание, знакомство с командой в неформальной обстановке и персональные ротации — классные практики при отборе кандидатов в команду.
  

• Отраслевые каналы и блоги — кладезь инсайтов.

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