Продуктовые команды в онлайн-кинотеатре more.tv

Про то, как строилось направление продукта и какие этапы мы прошли. Материал подготовлен в соавторстве двух действующих продуктовых людей: Романа Баранова (Product Lead more.tv) и Алексея Арефьева (CPO more.tv, автора Telegram-канала про развитие ИТ-продуктов).

Привет! Я Рома Баранов, руководитель по продукту в онлайн-кинотеатре 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, поэтому весь фокус смещен на достижение результатов с пользователей, которые имеют платную подписку.

Имея эти вводные мы приступили к созданию продуктового направления.

Перед тем как мы начнем, давайте расскажу, что я понимаю под этим выражением “Продуктовая команда”, чтобы мы работали с единой терминологией

Основная цель продуктовой команды — растить продуктовые и бизнес-метрики сервиса / сайта / продукта. В отличии от проектных команд, которые формируются для реализации какой-то единичной задачи (например, запуск нового раздела «Спорт” внутри сервиса), продуктовые команды "играют в долгую":

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

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

Как я уже писал, наши основные цели, это:

Каким образом достичь этих целей, имея уже существующий продукт?

Сначала мы верхнеуровнево описали воронку пользователя в нашем продукте, чтобы понять к каким ее частям нужно приложить больше усилий и получить максимум эффекта:

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

Путь по шагам выглядит так:

Посещение онлайн-кинотеатра — Регистрация — Взятие тестового периода — Оплата первой и последующей подписки.

То есть, с одной стороны мы должны привлекать больше трафика к нам в продукт, чтобы пользователь регистрировался и подписывался. С другой - удерживать его как можно дольше, таким образом повышая ARPU (средняя выручка на пользователя). Каждый шаг воронки на старте оказывает влияние на конечный результат, к которому мы стремимся.

Исходя из это логики, получаем первые ключевые метрики:

Благодаря декомпозиции цели на метрики мы определили команды. Наш подход был очень похож на фреймворк AARRR (подробнее, здесь), который представляет из себя модель воронки продаж:

Немного адаптировав фреймворк под себя, мы получили следующие команды.

SEO & Alternative Markets. Команда, которая вместе с SEO-специалистами занимается оптимизацией SEO сайта more.tv, а также использует альтернативные способы дистрибуции нашего продукта до пользователя (публикация в магазинах RuStore, адаптация для SberBox, предустановка в телевизорах и т.д.). Короче, тащит трафик в воронку.

Activation. Основная цель — взятие триала с привязкой карты. Команда изучает полный путь пользователя от самого начала взаимодействия с продуктом до взятия тестового периода и пытается его улучшить. Доносит ценность до пользователя, чтобы он остался у нас и использовал продукт. В общем, чтобы "прилип".

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

Engagement (Retention). Команда, которая работает на всех этапах воронки и улучшает пользовательский опыт при взаимодействии с продуктом таким образом, чтобы пользователь дольше и больше смотрел контент и чаще возвращался к нам на сервис.

Таким образом, было выделено 4 продуктовых направления со своими отдельными командами (чуть позже детально расскажу).

Мы понимали, что командами невозможно закрыть весь спектр возникающих задач. Поэтому, создали отдельную большую команду, назвав ее CORE Team. Это важная часть команды разработки, реализующая задачи, которые не вписываются в воронку или исходят от внешнего заказчика (например, отдела маркетинга, продаж и т.д.).

Core берет такие задачи, как:

В текущем состоянии CORE team также проводит различные эксперименты и оказывает огромную поддержку для направления SEO & Alternative Markets, т. к. из-за специфики задач ей не требуется полноценная автономная команда на фултайм.

Таким образом, мы используем гибрид команд:

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

Общая логика выглядит так.

Для примера возьмем стрим Activation, в котором ключевой метрикой является оформление триала или C0.

Как декомпозировать эту метрику? За основу можно взять CJM (Customer Journey Map). Если вдруг не знакомы, то здесь можно почитать вводную статью.

При сборке CJM для команды Activation у нас обнаружились различные нюансы и вопросы, которые позволили сформировать гипотезы для роста той самой метрики C0.

Пользователь пришел на сайт more.tv:

Пользователь зарегистрировался на сайте:

Как ответить на эти вопросы?

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

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

А что если мы сделали только хуже?

На помощь приходит AB-тестирование, которое может развеять эти сомнения. На A/B-тестировании построено все развитие продукта нашего онлайн-кинотеатра. С помощью экспериментов мы можем сравнить две версии кнопок и определить какая из них действительно лучше. Чтобы затаскивать подобные эксперименты, нам был необходим определенный состав команды, о нем и поговорим далее.

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

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

Все эти люди являются часть продуктовой команды. Именно такой состав позволяет нам фокусироваться и развивать выбранные направления.

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

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

С менеджерами по продукту мы разработали и утвердили общие принципы проведения экспериментов и создали базу знаний, которую назвали “График экспериментов”.

Как это работает?

Внутри продуктовой команды участники ведут документацию по своим внутренним правилам, но "наружу”, т. е. в общую базу данных (как раз в "График экспериментов”) эксперимент заводится по общим правилам. У нас есть отдельное пространство в notion и унифицированная карточка эксперимента.

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

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

Также нам важно было копить опыт и экспертизу где-то в одном месте. При общем соблюдении правил у нас собирались знания после анализа каждого эксперимента с выводами и дальнейшими шагами. Все наработки мы складываем в notion.

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

Если резюмировать весь наш опыт построения команд , то мы прошли следующие шаги:

Выполнив все это, мы получили организованный и структурированный процесс для развития нашего онлайн-кинотеатра.

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

P.S. Отдельно отмечу, что данный подход не является финальным, потому как мы стараемся нащупать следующий шаг, пробуя новые изменения. Это путь.