Продуктовые команды в онлайн-кинотеатре more.tv
Про то, как строилось направление продукта и какие этапы мы прошли. Материал подготовлен в соавторстве двух действующих продуктовых людей: Романа Баранова (Product Lead more.tv) и Алексея Арефьева (CPO more.tv, автора Telegram-канала про развитие ИТ-продуктов).
Знакомство
Привет! Я Рома Баранов, руководитель по продукту в онлайн-кинотеатре more.tv. Спустя полтора года я решил поделиться результатами создания продуктового направления и рассказать про этапы, которые мы прошли:
- Как выбрали ключевые метрики
- Как определили типы команд
- Как организовали процесс взаимодействия между командами при проведении экспериментов
Начало
Когда я пришел на позицию руководителя по продукту в more.tv, передо мной были поставлены осязаемые и понятные задачи:
- рост выручки
- и платящей базы подписчиков
Чтобы подступиться к решению, нужно было понять как работает текущая машина. Проведя небольшой аудит, мы поняли, что:
- продуктовые направления формулировались
- приоритезацию задач нужно было подкорректировать
- команды продолжить развивать и формировать новые
Были продакты, которые вели отдельные компоненты и направления, но хотелось это упорядочить и прокачать. Мы начали разворачивать систему.
Чтобы понять, что это значит для онлайн-кинотеатра давайте разберемся что такое more.tv и какие модели монетизации мы используем.
Что такое more.tv
more.tv — компания, входящая в Национальную Медиа Группу (НМГ) с собственным производством сериалов more originals. Мы создаем интересный и разнообразный контент, не боимся даже самых острых тем, включая отношения детей и родителей и жизнь современных подростков. На нашем сайте и в мобильных приложениях для Android, iOS и SmartTV доступен широкий выбор фильмов и сериалов на абсолютно любой вкус.
Модели монетизации
Существует несколько моделей монетизации видеоконтента, которые широко применяются в мире.
AVoD (Advertising Video on Demand) предлагает бесплатный доступ к контенту с рекламными вставками. more.tv вставляет рекламу в видео, чтобы получить прибыль от рекламных партнеров и обеспечить бесплатный контент для зрителей.
SVoD (Subscription Video on Demand) предлагает подписку на разнообразный контент без рекламы. Пользователи платят ежемесячную или годовую плату, чтобы иметь полный доступ к библиотеке сериалов, фильмов и шоу.
Продуктовая команда more.tv отвечает в основном за подписную базу и выручку из модели SVoD, поэтому весь фокус смещен на достижение результатов с пользователей, которые имеют платную подписку.
Кроме указанных выше моделей есть еще TVoD (Transactional Video on Demand), позволяет пользователям приобретать отдельные фильмы или сериалы на ограниченное время и EST (Electronic Sell-Through), которая предоставляет возможность приобретения электронной копии контента, но мы в more.tv не используем эти способы монетизации.
Имея эти вводные мы приступили к созданию продуктового направления.
Сборка продуктовой команды. Начало
Перед тем как мы начнем, давайте расскажу, что я понимаю под этим выражением “Продуктовая команда”, чтобы мы работали с единой терминологией
Основная цель продуктовой команды — растить продуктовые и бизнес-метрики сервиса / сайта / продукта. В отличии от проектных команд, которые формируются для реализации какой-то единичной задачи (например, запуск нового раздела «Спорт” внутри сервиса), продуктовые команды "играют в долгую":
- они исследуют продукт / пользователя / рынок
- вытаскивают боли и задачи
- проверяют гипотезы решений
- улучшают и дорабатывают взаимодействие пользователя с продуктом
Пытаясь при этом всем заработать деньги для компании. Таким образом продуктовые команды занимаются непрерывным и постоянным улучшением продукта для достижения поставленных целей.
Для операционного управления общие цели компании декомпозируются под каждую команду. Строятся метрики или показатели, которые ребята стараются качать в рамках своих направлений. Давайте про это подробнее.
Определяем ключевые метрики под команды
Как я уже писал, наши основные цели, это:
- выручка (Revenue)
- и количество платных подписчиков (Subscribers)
Каким образом достичь этих целей, имея уже существующий продукт?
Сначала мы верхнеуровнево описали воронку пользователя в нашем продукте, чтобы понять к каким ее частям нужно приложить больше усилий и получить максимум эффекта:
Мы заработаем деньги и получим платного подписчика, если сконвертируем нашего пользователя из обычного посетителя в платящего за несколько шагов.
Путь по шагам выглядит так:
Посещение онлайн-кинотеатра — Регистрация — Взятие тестового периода — Оплата первой и последующей подписки.
То есть, с одной стороны мы должны привлекать больше трафика к нам в продукт, чтобы пользователь регистрировался и подписывался. С другой - удерживать его как можно дольше, таким образом повышая ARPU (средняя выручка на пользователя). Каждый шаг воронки на старте оказывает влияние на конечный результат, к которому мы стремимся.
Исходя из это логики, получаем первые ключевые метрики:
- Трафик – чем больше пользователей на входе, тем шире воронка на входе. Метрика - кол-во визитов/уников с разных источников.
- Взятие триала – чем больше пользователей возьмут триал, тем большее кол-во из них уйдет в дальнейшую платную подписку. Метрика С0 или конверсия в триал.
- Переход из триала в платную подписку – чем боле пользователей будет переходить из триала в платную подписку, тем больше выручки мы заработаем. Метрика C1 или конверсия из триала в первую платную подписку/в первое списание. Все последующие платные подписки мы называем C2 → C3 → C4 и так далее.
Определяем типы команд
Благодаря декомпозиции цели на метрики мы определили команды. Наш подход был очень похож на фреймворк AARRR (подробнее, здесь), который представляет из себя модель воронки продаж:
- Acquisition — привлечение
- Activation — активация
- Retention — возвращаемость
- Refferal — готовность рекомендовать
- Revenue — доход
Немного адаптировав фреймворк под себя, мы получили следующие команды.
SEO & Alternative Markets. Команда, которая вместе с SEO-специалистами занимается оптимизацией SEO сайта more.tv, а также использует альтернативные способы дистрибуции нашего продукта до пользователя (публикация в магазинах RuStore, адаптация для SberBox, предустановка в телевизорах и т.д.). Короче, тащит трафик в воронку.
Например, пользователь в самом начале воронки желает посмотреть турецкие сериалы и идёт в поисковик. Там он делает запрос «Турецкие сериалы смотреть» и, благодаря SEO-оптимизации подобных запросов, получает на первых позициях ссылки на наш сайт.
Activation. Основная цель — взятие триала с привязкой карты. Команда изучает полный путь пользователя от самого начала взаимодействия с продуктом до взятия тестового периода и пытается его улучшить. Доносит ценность до пользователя, чтобы он остался у нас и использовал продукт. В общем, чтобы "прилип".
Например, тот же пользователь, перейдя на наш сайт из поисковика, переходит на какой-либо турецкий сериал и смотрит его бесплатно с рекламными вставками. В определенный момент команда активации предлагает ему посмотреть следующие серии без рекламы с подпиской и пользователь оформляет бесплатный период с привязкой карты.
Monetization. Как только пользователь взял триал, он переходит во власть следующей команды, цель которой является удержание пользователя в платной подписке как можно дольше. Тут применяются различные механики в виде офферов или скидок, которые работают с оттоком или же повышением чека клиента.
Например, возьмем нашего пользователя из предыдущих этапов. В один прекрасный момент после нескольких месяцев использования он решает отказаться от подписки. Настроив модель, оттока команда монетизации предлагает пользователю скидку на следующий месяц или предлагает использовать сервис бесплатно еще несколько недель, чтобы изменить своё мнение.
Engagement (Retention). Команда, которая работает на всех этапах воронки и улучшает пользовательский опыт при взаимодействии с продуктом таким образом, чтобы пользователь дольше и больше смотрел контент и чаще возвращался к нам на сервис.
Например, чтобы наш пользователь мог смотреть турецкие сериалы, команда Engagement вносит различные улучшения в сервис. Быстрый доступ к контенту с любого устройства в любой момент и управление своей коллекцией. Если любимый сериал заканчивается, то система рекомендаций и поиска позволяют выбрать новый проект для просмотра.
Таким образом, было выделено 4 продуктовых направления со своими отдельными командами (чуть позже детально расскажу).
Мы понимали, что командами невозможно закрыть весь спектр возникающих задач. Поэтому, создали отдельную большую команду, назвав ее CORE Team. Это важная часть команды разработки, реализующая задачи, которые не вписываются в воронку или исходят от внешнего заказчика (например, отдела маркетинга, продаж и т.д.).
Core берет такие задачи, как:
- обновление плеера
- улучшение безопасности всего сервиса
- улучшения внутренних инструментов
- крупные проекты и запуски, затрагивающие разные платформы и т.д.
В текущем состоянии CORE team также проводит различные эксперименты и оказывает огромную поддержку для направления SEO & Alternative Markets, т. к. из-за специфики задач ей не требуется полноценная автономная команда на фултайм.
Таким образом, мы используем гибрид команд:
- выделенные/продуктовые под направления, которые постоянно прокачивают воронку
- и большую Сore команду, которая закрывает огромный пласт задач, не подходящих под направления выше
После определения ключевых метрик и команд, которые за них отвечают, настало время углубиться в дальнейшую декомпозицию на примере одной продуктовой команды.
Декомпозируем ключевые метрики в каждой команде
Общая логика выглядит так.
Для примера возьмем стрим Activation, в котором ключевой метрикой является оформление триала или C0.
Как декомпозировать эту метрику? За основу можно взять CJM (Customer Journey Map). Если вдруг не знакомы, то здесь можно почитать вводную статью.
При сборке CJM для команды Activation у нас обнаружились различные нюансы и вопросы, которые позволили сформировать гипотезы для роста той самой метрики C0.
Пользователь пришел на сайт more.tv:
- Он попал на главную страницу или на карточку проекта?
- Он пришел с рекламной кампании или по запросу из поисковика?
Пользователь зарегистрировался на сайте:
- Если бы кнопка была заметнее, зарегистрировалось ли больше пользователей?
- В какой момент произошло начало регистрации?
- Есть ли различия в пользователях, которые начали процесс регистрации?
- Что будет, если мы предложим пользователю больший бесплатный период?
Как ответить на эти вопросы?
Думаю что каждый из нас лучше всех знает как должен работать сайт и что зеленая кнопка лучше, чем красная. Скажем так, все мы в своем роде продакт-менеджеры.
Вопрос в том, можем ли мы это доказать и ответить стейк-холдерам и, самое главное, самим себе, что новая фича или улучшение, которую мы принесли с горящими глазами, действительно улучшила бизнес-метрики и позволила нам увеличить регистрацию.
А что если мы сделали только хуже?
На помощь приходит AB-тестирование, которое может развеять эти сомнения. На A/B-тестировании построено все развитие продукта нашего онлайн-кинотеатра. С помощью экспериментов мы можем сравнить две версии кнопок и определить какая из них действительно лучше. Чтобы затаскивать подобные эксперименты, нам был необходим определенный состав команды, о нем и поговорим далее.
Состав продуктовой команды
Для роста метрик по каждому шагу и проверки полезности наших улучшений тем же AB-тестированием одного менеджера продукта недостаточно, поэтому мы пришли к видению, что каждая продуктовая команда должна быть автономна и самостоятельно решать поставленные задачи. В продуктовой команде мы собрали все необходимые этого навыки и экспертизу.
За последние полтора года мы прошли через разные изменения, но в конечном счете остановились на следующей конфигурации:
- Менеджер продукта — лидер команды, который отвечает за развитие своего направления: формирует дерево метрик, составляет беклог задач и управляет его приоритетами.
- Аналитик — правая рука менеджера продукта при принятии решении в развитии своего направления. Собирает необходимые данные, строит воронки и определяет успешность экспериментов.
- Дизайнер — человек, который не просто рисует кнопочки по запросу менеджера продукта, а тот, кто способен превратить идею в конкретный пользовательский опыт. Проектирование макетов интерфейса, функций, фичей.
- Системный аналитик/архитектор — систематизирует и укрепляет требования по задачам продакта до уровня, понятного разработчику.
- Разработчик — тот самый человек, который воплощает задачи и идеи в реальный продукт, которым будет пользоваться человек. В нашем случае у нас много платформ (сайты, приложения...) и в команде есть отдельный разработчик, который тащит изменения на своей платформе. Плюс, конечно же бэкенд разработчик, который собирает логику под заявленные требования.
- Тестировщик — человек, который проверяет продукт перед выпуском на пользователей. Отлавливает баги, ошибки и несоответствия в задачах. Следит за качеством того, чем будут потом пользоваться люди.
Отдельно нужно отметить роль скрам мастеров и наших менеджеров проекта, которые следили и собирали процессную часть команд. Обучение методологиям, проведение ключевых мероприятий (дейлики, ретро, планирование и т.д.) помогли поставить команды на рельсы и ускорить цепь поставки изменений.
Все эти люди являются часть продуктовой команды. Именно такой состав позволяет нам фокусироваться и развивать выбранные направления.
Под капотом подобных команд, как я писал выше, лежит большое кол-во экспериментов. Чтобы собирать базу знаний по ним в единое место, синхронизировать направления между собой и не дублироваться, мы собрали особый процесс, про который поговорим дальше.
Эксперименты
Так как эксперименты для нас являются основой, стало понятно, что процесс нужно систематизировать. На масштабе мы будем тратить большое количество времени на поддержку и управление этой историей, поэтому нужен был свой подход.
С менеджерами по продукту мы разработали и утвердили общие принципы проведения экспериментов и создали базу знаний, которую назвали “График экспериментов”.
Как это работает?
Внутри продуктовой команды участники ведут документацию по своим внутренним правилам, но "наружу”, т. е. в общую базу данных (как раз в "График экспериментов”) эксперимент заводится по общим правилам. У нас есть отдельное пространство в notion и унифицированная карточка эксперимента.
Это сделано специально, чтобы любой менеджер продукта или внешний участник мог понять, о чем идет речь в эксперименте и на какую часть продукта он влияет.
Несмотря на кажущуюся очевидность и простоту этого правила оно является если не ключевым, то одним из самых важных. Поняли мы уже после первого квартала, когда накопилось достаточное количество экспериментов и результатов по ним. Простой доступ с понятной логикой снимал кучу проблем с интерпретацией и работой с данными.
Также нам важно было копить опыт и экспертизу где-то в одном месте. При общем соблюдении правил у нас собирались знания после анализа каждого эксперимента с выводами и дальнейшими шагами. Все наработки мы складываем в notion.
Если notion не подходит, то можно выбрать и другие инструменты. Например, самый простой — Google Sheets или чуть сложнее AirTable.
Подобная схема управления экспериментами и базой знаний экономит огромную кучу времени и позволяет быстро переиспользовать собранные данные. Как-нибудь отдельной статьей я детально опишу наш подход к ведению экспериментов.
Заключение
Если резюмировать весь наш опыт построения команд , то мы прошли следующие шаги:
- Установили ключевые метрики из поставленных целей для продукта.
- Определили типы команд на основе полученных метрик.
- Определили состав продуктовой команды для решения поставленных задач.
- Систематизировали процесс проведения экспериментов.
Выполнив все это, мы получили организованный и структурированный процесс для развития нашего онлайн-кинотеатра.
Это наш опыт, который, надеюсь, позволит вам собрать свои собственные конфигурации команд и усилить фокус развития продукта.
P.S. Отдельно отмечу, что данный подход не является финальным, потому как мы стараемся нащупать следующий шаг, пробуя новые изменения. Это путь.
Какие ещё варианты формирования команд рассматривали и почему AARRR победил?
Есть еще варианты, когда команды делятся на платформы. Например, один продакт отвечает за сайт, второй за мобильные приложения. Но такой вариант не особо удобный (на наш взгляд) по следующим причинам:
- Расхождение между платформами будет большим. Пользовательский опыт будет сильно различаться при переходе с телефона на сайт или наоборот
- Расфокусировка по все воронке. Одному продакту в такой схеме придется следить за активацией, монетизацией и вовлечением одновременно
AARRR позволяет заняться определенным шагом воронки и использовать платформы как "инструмент" достижения поставленных задач.
Я бы добавил, что AARRR позволяет тебе, как продуктовому человеку, фокусироваться в первую очередь на клиентском опыте. То есть, это не просто компонент платформы, за который ты отвечаешь, это реальный человек, для которого ты создаешь продукт.
Ну, а дальше уже, чем лучше мы продуктом решаем задачу клиента, тем он счастливее, а значит и фин.результат будет выше.
Прочитал на одном дыхании, как раз сейчас нахожусь в начале пути построения команды в олд компании. Вам успехов)
Очень интересная и компактная статья получилась, ждем еще!
Спасибо, рады стараться!
Новую уже выпустим когда мяса полезного наберем. Пока текущая структура команд актуальна и приносит пользу.
Спасибо, что делитесь опытом!
Расскажите как удавалось вести эксперименты целых четырех продуктовых команд? Были ли конфликты? Как решали?
Спасибо за обратную связь :)
Да, мы пару раз сталкивались с подобным, но нам удалось решить эту проблему следующими историями:
- Обзор спринта. На общей встрече каждый продакт обозначает какие эксперименты планирует разработать / запустить. Это первый звоночек, который может дать сигнал другому продакту, что в этот момент может быть конфликт двух экспериментов разных команд
- "График экспериментов" в notion, про который я вскользь упомянул в конце статьи. С помощью него можно отслеживать актуальные на данный момент эксперименты и скорректировать график запуска
Ну и как бы странно это не звучало - общая ответственность. Все продакты понимают общую цель и задачу и следят друг за другом и поэтому на встречах, при обсуждениях могут обнаружить конфликт заранее.
как решили боль кроссплатформенных команд?
условно решили внести значимое изменение в фичу триала. для этого нужен разраб и на смарты, и на веб, все мобилки и пр + тестировщики на все устройства + супер скиловый сисан/архитектор. команда начинает лопаться от оверфункционала
У нас это решается как раз за счет продуктовой команды. Внутри у тебя есть все спецы, который способны вносить изменения на все платформы.
Ровно такая же логика и у продакта, потому как его целевая метрика не привязана к платформе и он растит ее везде. Например, когда генерит фичу, думает сразу про все платформы, чтобы выдержать единый клиентский опыт.
Есть, конечно, нюансы, связанные с необходимостью полной загрузки команды, потому как бывают фичи, которые везде не запихнешь (типа вибрации смартфона, которая только на app подходит), но стараемся точечно с этим работать.
Спасибо, продолжаем тюнить конфигурацию, но основной фундамент заложен.
То есть вы каждую фичу команды прогоняете через АБ-тест? Какой в среднем цикл от формулировки гипотезы, до ее реализации на проде, как полноценной части функционала?
Не каждую, но большинство. Средний цикл может составить от одного спринта. Сначала делаем «на коленке» и в случае успеха в же реализуем полноценное решение — это может занять ещё один спринт.
Забыл упомянуть и про цикл проведения самого теста :) Стоит учитывать, что на "открутку" эксперимента может уйти от недели и больше.
Интересный материал, спасибо, но seo-шка по приведённому запросу тур сериалов в топе ivi проигрываете, чем обусловлен мусор в метатегах и заголовках, не ужели прямое вхождение без разбавления хуже? пример "hd", "смотри", "список лучших сериалов Турции" - понятно что таких страниц очень много, что это генережка, но прям странно выглядит https://more.tv/tvseries/tr
привет! очень интересная статья, спасибо. А можете рассказать подробнее, почему команду SEO решили сделать продуктовой? А не оставить в маркетинге? Какие бенефиты от такого решения?