Несколько лет назад я познакомился с работой Ицхака Адизеса где он рассуждал об эффективности работы руководителя. В это момент мне стало интересно, как оценивать эффективность работы меня как CPO, как оценивать работы всех команд, как понять что все команды приносят пользу? Вопрос кажется очень простым, но на поверку он намного сложнее. Команды работают не в одиночку. Обычно их несколько. Часто есть команды Core, команды CRM или биллинга… Как понять что весь продукт и его управление работает как надо? Давайте разбираться.

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

Можно измерить эффективность команды, которая отвечает за рост или работу с пользователями, но тогда все остальные команды работают неэффективно? Что делать, если год крутили 1000 зеленые  А/В тесты, а доходность бизнеса не выросла или упала? Как узнать, что мы делаем то, что надо? 

Основной вопрос на который надо ответить – как понять, что инвестиции в продукт приносят в результат? 

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

ROPI как показатель эффективности продукта

ROPI является аналогом ROMI, но применяется по отношению к продукту в целом. Это означает, что при расчёте индекса возврата инвестиций от продукта, учитываются все команды и все затраты, связанные с людьми, которые участвуют в доставке ценности клиенту (создании продукта).

Этот индекс возврата инвестиций, очень универсален, так как подходит для сфер B2B и B2C. Его можно рассчитывать как для всего продуктового портфеля в целом, так и индивидуально для отдельных элементов ассортимента, продуктовой матрицы или вертикалей.

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

Формула ROPI:

ROPI = (Доход от продукта компании − расходы на создание продукта) / расходы на создание продукта × 100%

Где:

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

Расходы на создание продукта — все затраты, связанные с разработкой, производством и выводом продукта на рынок.

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

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

Первая – это то, что индекс – запаздывающий, и нам требуется не простой расчет показателя эффективности, а динамика сравнения – ROPI(adj).

ROPIadj = ΔВыручки/ Инвестиции = Выручка текущего периода−Выручка предыдущего периода / Расходы текущего периода.

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

Важно помнить что задача продукта создавать выручку и доходность бизнеса, если ваш продукт про бизнес. С позиции директора по продукту, самое важное – это рост выручки и доходности, а зеленые тесты и все прочие тесты это уже детали. По сути мы продукт (ценность) меняем на деньги. Нет потока денег, или он падает – значит с продуктом что-то не то, и следует вникать в детали/ изучать детали для поиска причин.

Еще раз, ROPi – показатель эффективности всего продукта, всех команд, а не отдельной команды, не отдельного продакт менеджера. Это градусник. Задача CPO – мерить температуру бизнеса, и вовремя увидеть, что продукт “заболел”.

Для расчета ROPi, следует договориться, какие блоки учитываются в продукте (расходная часть).  Как  правило, это Фонд оплаты труда (ФОТ) и затраты на оборудование и сервера. Расходы на ФОТ включают расходы по оплате труда разработчиков (инженеров) и всех продуктовых команд, а, зачастую, и команд поддержки. Мы учитывали все расходы продуктового и IT блока.

Что такое выручка – как правило, понятно. Это учет от продаж или денежного потока от группы продуктов в целом. Для В2В это, по сути, продажи в текущем месяце – MMR.

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

Опережающие показатели

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

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

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

Обычно опережающими показателями могут выступать:

Вовлеченность пользователей:

• Количество регистраций или покупок новых пользователей. 

• Количество просмотров страниц или контента. 

• Среднее время в приложении или на сайте.

Активация и использование:

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

• Использование определенных функций, которые ведут к большей ценности.

И так далее.

Но для бизнеса или CEO опережающие показатели требует вовлечения и глубокого погружения в детали продукта. Для C-levrla надо оперировать единой метрикой. Для упрощения понимания того, что происходит, это может быть ROPI или NSM  (метрика Полярной звезды), если она принята на уровне компании, либо опережающий показатель продукта.

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

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

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

ROPi – это градусник, показывающий “болеет” продукт, или все в пределах нормы.

Проблемы оценки работы CORE  команд.

ROPi учитывает затраты в том числе на Core команды, команды поддержки и прочие технические команды, включая DevOps, помимо продуктовых команд и команд инженеров. 

Возникает справедливый вопрос: у нас DevOps трудился, трудился, а ваш ROPi падает…. Это не правильно….Как такое может быть? 

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

При применении ROPi мы обнаружили, что очень помогает учитывать сколько каких задач по типам было сделано в оцениваемый период (месяц). Мы выделили количество продуктовых задач, количество задач на баги по продуктовым задачам после релизов, количество задач технического долга, отдельно количество задач техподдержки и прочие. Логика была простая: увидеть, сколько задач в абсолюте делается для продукта всеми командами, сколько для поддержки и стабильной работы, сколько правок после релизов.

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

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

Если вы учитываете в сложности или размерности (поинты, попугаи, изяны и пр.), то тут такая же логика: вы увидите количество изъянов на средний эпик в месяц и стоимость этого пресловутого изяна.

Выводы

• ROPi – это градусник, показывающий “болеет” ли продукт, или все в пределах нормы. Аналог – ROMI, но только исключительно для продукта.

• ROPI = (Доход от продукта компании − расходы на создание продукта) / расходы на создание продукта × 100%

• ROPIadj = ΔВыручки/ Инвестиции = Выручка текущего периода−Выручка предыдущего периода / Расходы текущего периода. Отражает динамику эффективности продукта и индекс изменения месяц к месяцу. Самый важный показатель на мой взгляд.

• ROPi – запаздывающий показатель отражающий вклад прошлых продуктовых релизов (разработки) к выручке этого месяца.

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

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

Пробуйте!

Больше интересного тут - https://t.me/dao_producta