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

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

С удовольствием провожу время с командой. Фото с тим-ланча, об этом классном ритуале я тоже расскажу в статье :)
С удовольствием провожу время с командой. Фото с тим-ланча, об этом классном ритуале я тоже расскажу в статье :)

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

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

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

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

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

Зайти на новый рынок с «ручным» MVP — это ок

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

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

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

Один из первых интерфейсов платформы Aitarget One — было 3 окна для ввода данных клиента и всё :)
Один из первых интерфейсов платформы Aitarget One — было 3 окна для ввода данных клиента и всё :)

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

Как выглядит платформа Aitarget One сейчас
Как выглядит платформа Aitarget One сейчас

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

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

Нет универсальной методологии — в любом случае нужна донастройка под команду

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

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

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

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

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

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

Мне нравится, что мы быстрые, у нас нет необходимости по 100500 раз все согласовывать и пересогласовывать.

Дима, Продакт-менеджер

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

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

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

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

Так разработчики оформляют ретро по спринтам
Так разработчики оформляют ретро по спринтам

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

Денис, Backend-разработчик

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

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

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

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

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

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

Советуемся 🧠
Советуемся 🧠

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

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

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

Инструменты

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

Получился вот такой инструментарий:

Confluence — для бизнес-документации по продукту;

Jira — таск-менеджер для разработки;

Notion — сервис для кросс-командных заметок и задач продактов;

Metabase — BI система для визуализации важных для бизнеса показателей;

Mixpanel — для продуктовой аналитики;

Miro — для брейншторма, карт коммуникации и CJM.

Разделение зон ответственности в продукте позволяет тестировать больше гипотез за раз

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

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

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

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

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

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

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

Чайзат, Продакт-менеджер и аналитик

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

Fun fact: часто гипотезы рождаются после того, как продакт почитал Telegram-канал, где какой-нибудь маркетолог жалуется на жизу

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

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

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

Саша, UX/UI-дизайнер

Наличие всех нужных hard skills у кандидата совсем не значит, что он подходит

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

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

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

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

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

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

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

У нас разработка думает о том, как сделать дешевле и быстрее, а не просто сделать.

Миша, Backend-разработчик

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

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

Команду сроднили не тимбилдинги, а наши ритуалы

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

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

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

Ещё одно фото с тим-ланча. У нас всегда весело!
Ещё одно фото с тим-ланча. У нас всегда весело!

Рефлексия + фидбэк — слагаемые командного здоровья

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

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

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

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

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

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

Мы всегда прислушиваемся к мнению новых людей

Ваня, Frontend-разработчик

Выводы за 2,5 года. Кратко:

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

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

фраза "продуктовая команда" всегда у меня ассоциируется с овощным ларьком :))

3
Ответить

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

2
Ответить

Ребята, вы красавчики! Так держать 🤟🏻🔥
Ксения, молодец, очень классные выводы. Многим юным стартаперам эта статья будет очень полезна.

1
Ответить
Комментарий удалён модератором

Не пробовали. Мы выбирали между Redash и Metabase. Оба инструмента хороши, но Metabase подкупил удобным визуальным конструктором отчётов — с ним даже менеджеры без навыков sql могут строить графики

Ответить

Секрет сильной команды прост. Надо быть нормальным руководителем! И не заниматься постоянным наймом и увольнением людей, а строить долгие отношения.

Ответить