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

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

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

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

• они исследуют продукт / пользователя / рынок
• вытаскивают боли и задачи
• проверяют гипотезы решений
• улучшают и дорабатывают взаимодействие пользователя с продуктом

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

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

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

• выручка (Revenue)
• и количество платных подписчиков (Subscribers)

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

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

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

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

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

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

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

• Трафик – чем больше пользователей на входе, тем шире воронка на входе. Метрика - кол-во визитов/уников с разных источников.
• Взятие триала – чем больше пользователей возьмут триал, тем большее кол-во из них уйдет в дальнейшую платную подписку. Метрика С0 или конверсия в триал.
• Переход из триала в платную подписку – чем боле пользователей будет переходить из триала в платную подписку, тем больше выручки мы заработаем. Метрика C1 или конверсия из триала в первую платную подписку/в первое списание. Все последующие платные подписки мы называем C2 → C3 → C4 и так далее.

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

• Acquisition — привлечение
• Activation — активация
• Retention — возвращаемость
• Refferal — готовность рекомендовать
• Revenue — доход

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

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

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

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

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

Таким образом, было выделено 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.

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

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

• Установили ключевые метрики из поставленных целей для продукта.
• Определили типы команд на основе полученных метрик.
• Определили состав продуктовой команды для решения поставленных задач.
• Систематизировали процесс проведения экспериментов.

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

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

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