Продуктовые метрики в работе Product manager: как их собрать?
Мой взгляд на построение продуктовой метрики проекта, IT-продукта в работе Product manager или Project manager
В каждом общении с владельцами бизнеса и их представителями, которые отчаянно ищут того самого продакта словно иголку в стоге сена и вечно пытаются понять на входе, понимает ли он - соискатель на роль Product manager - те самые волшебные продуктовые метрики. Зачастую, на той стороне сами толком не знают все эффективные показатели продуктовых метрик и как под копирку хотят услышать. Это легко понять по паре вопросов и размытым абстрактным ответам на той стороне.
Многим любопытным скажу одно:
Продуктовые метрики разрабатываются отдельно под продукт или услугу. Разделяют базовые, финансовые и уникальные.
Базовые метрики используют на старте отработки гипотез.
Финансовые метрики. Сначала используют урезанный состав, затем, по мере, развития продукта, просчитывают все больше разных более узких финансовых показателей с целью отслеживания динамики колебаний эффективности проекта/канала.
Уникальные метрики разрабатываются после обкатки и вывода нового предложения или функционала в рамках продукта.
Уникальные метрики всегда пишутся под пользовательский сценарий и модели поведения в IT-продукте (CRM, мобильное приложение, IT-сервис, маркетплейс, личный кабинет и т.д.). Если вы хотите при первом знакомстве засыпать Product manager вопросами на знание аббревиатур продуктовых метрик, то я вас тут разочарую. Наизусть их знать не обязательно. Знать надо, что несут эти метрики и как необходимо поступить на основе анализа данных по показателям, уметь эффективно применять необходимые метрики в свое время работы над продуктом.
В основе лежит общая UNIT-экономика проекта, состоящая из отдельных UNIT-экономик по каналам, гипотезам. Пример UNIT-экономики на базе просчета сметы расходов и плановых доходов при повторном запросе клиента на повторный запуск продвижения аудиторских услуг.
На старте достаточно отслеживать базовые метрики проекта, воронки продаж, но, когда нам необходимо увидеть узкие места, понять какие действия необходимо оптимизировать, увидеть мелкие и очень важные изменения, влияющие на результат, вот именно в этот момент каждый Product manager начинает задавать уникальные метрики под свой проект.
Конечно, в интернете очень много клише по тому, как называются эти метрики, по каким формулам они рассчитываются. Вам же, продакт-менеджеру или проджект-менеджеру, стоит уметь правильно их применять, понимать смысл и последствия, строить прогнозы.
БАЗОВЫЕ ПРОДУКТОВЫЕ МЕТРИКИ
Рассмотрим в связке «канал трафика – сайт». Здесь мы рассматриваем все возможные показатели отслеживания действий пользователей в зависимости от типа воронки продаж и самого клиентского пути.
Показы в канале привлечения
- Рекламный трафик
- СЕО-трафик
- Контентный трафик
Переход на сайт
Таргетинг-действие
- Оценка поста в Блоге
- Комментарий к посту, товару, видео
- Добавление товара или статьи в Избранное
- Репост
- Подписка на Блог, рассылки и уведомления
- Переход в соцсеть
- Переход в мессенджер
- Наведение курсора мыши на номер телефона или Email
- Переход на страницу Контакты, Товары или любую другую по модели поведения
- Скачивание файлов (презентация о продукте, прайс и т.д.)
- Просмотр видео
- Реакция на всплывающие окна
- Расчет сметы или калькулятора на сайте
- Поиск внутри сайта
- Использование фильтров в модуле отображения товаров на сайте
Лид-действие
- Отбор товаров в Корзину
- Возврат товаров из Корзины
- Брошенная Корзина на одном из этапов до момента проведения платежа
- Переход общения в Чате на сайте
- Заполнение анкеты, опросника на сайте
- Звонок по номеру телефона
- Запрос на Email, указанный на сайте
- Заполнение формы заявки
- Загрузка подписанного договора или иных документов
Apruve-действие
- Покупка (транзакция) через Корзину на сайте
- Покупка (транзакция) через чат-бота
- Покупка (транзакция) по платежной ссылке
Лояльность-действие
- NPS – индекс удовлетворенности
- CSAT – индекс размера удовлетворенности в конверсии
- MAU – кол-во активных пользователей за период (месяц, неделю, день или любой произвольный период)
Что влияет на отслеживание таких метрик? Конверсия или процент (%). На примере UNIT-экономики выше вы можете посмотреть метрики и конверсии. Именно через размеры конверсий проще всего понимать эффективность прогона пользователя по пути движения на сайте. На основе базовых метрик создаются уже индивидуальные, позволяющие задать более глубинное отслеживание пользовательских действий и запуска маркетинговых или системных сценариев, позволяющих дожать или вернуть пользователя.
Отслеживание конверсий хорошо помогает, когда у вас в месяц от 100 лидов и выше. Если же у вас только старт и обкатка 1-2 каналов, то не ждите лавину лидов. Ведь все зависит и от самого продукта. Если хромает визуал и юзабилити, то сколько бы метрик вы не настроили на отслеживание, в итоге они будут останавливаться только на этапе таргетинг-действий и лишь единицы дойдут до Лид-действий и Apruve. Поэтому на старте обкатки продукта достаточно использовать базовые метрики, которые я описала выше.
Рассмотрим другую связку «project – разработка». Чем масштабнее разработка и внедрение IT-проекта, тем более обширный роадмап выстраивает Project. Все задачи разбиваются по направлениям, командам или отделам. Далее идет организация и построение правил работы исполнителей в планировщике задач. В последнее время я использую либо Jira, либо YouGile (см. рисунок ниже).
PROJECT-МЕТРИКИ
- План/факт начала и завершения задачи
- Разница сдвига между планом и фактом завершения задачи
- Конверсия закрытых задач за период
- Конверсия сроков закрытия задач
- Конверсия задач на этапах: назначено, согласование, в работе, завершено, отмена и с любыми другими этапами прохождения задачи
- Количество багов за период
- Количество открытых/закрытых спринтов
- Количество переносов срока завершения задачи на 1 исполнителя
- Количество возвратов на доработку
- Качество отработки задачи в конверсии (командная оценка работы исполнителя)
- Объем поступающих задач за период: день, неделю
- Конверсия скорости закрытия задач
- Жизненный цикл задачи по типу запроса
- Конверсия загруженности по решению задач на 1 исполнителя
- Конверсия сгорания
- Частота срывов срока закрытия задач
- Риски: план/факт
- Конверсия по приоритетам закрытия задач за период
Не все из этих метрик можно отследить в том же YouGile, т.к. этот сервис не заточен под такое целевое отслеживание, заложены только базовые метрики. Обычно данные отгружают в более приспособленный для этого сервис аналитики. Пример такой связки: Jira – Database – PostgreSQL – Google Data Studio ИЛИ Jira – Power BI.
Благодаря таким связкам можно построить свои дашборды и сформировать свои тренды отслеживания в динамике.
Когда нет возможности подключить такие сложные сервисы обработки данных, я обычно использую выгрузки данных в excel и уже после выстраиваю сводные таблицы, диаграммы по показателям в рамках отслеживания изменений.
Такие project-метрики позволяют гармонично перераспределять ресурсы и загруженность исполнителей в рамках нескольких проектов, вовремя реагировать на ошибки и сбои, выравнивать сроки сдачи работ без задержек и бесконечных переносов. Эффективный Project помогает команде работать в фокусе, оценивать индекс слаженности работы в команде, предугадывать возможные регулярные риски, оценить прогресс работы.
Описанные выше Project-метрики – идеал в управлении проектом IT-разработки. На деле я часто вижу халатное отношение к работе в Jira среди стартапов. Только единицы с серьезным финансированием запускают эффективное project‑управление с детальными показателями, т.к. несут более серьезный отчет за каждую копейку на IT-разработку, особенно при найме удаленного подряда на определенные блоки разработки.
ФИНАНСОВЫЕ ПРОДУКТОВЫЕ МЕТРИКИ
- Выручка
- Количество покупок (транзакций)
- Средний чек
- Маржа (Чистая доходность или разница между доходами и расходами на канал)
- Рентабельность
- Стоимость перехода на сайт через внешний ресурс
- Стоимость таргетинг-действия
- Стоимость 1 лида
- Стоимость 1 покупки
- Стоимость 1 клиента
- Окупаемость канала привлечения
- Окупаемость ресурса (сайт, приложение, товар, услуга)
- Окупаемость проекта
- Жизненный цикл покупки
- Частота покупок за период
- LTV или прибыль с клиента за весь период оказания услуги/нахождения на сервисе
- Доля отказов
- Доля потерянной выручки отказов
- Доля потенциала
- Доля потерянной выручки потенциала
В зависимости от модели монетизации, типа продукта, этапов продаж в каждой UNIT-экономике присутствуют все эти финансовые показатели, позволяющие оценить экономическую выгоду и просчитать оптимизацию затрат по бизнес-модели (профит или капитализация) при отработке гипотез, пилота по бизнес-идеи.
Особо не расписываю этот раздел метрик, т.к. о нем очень много разного рода статей с разной интерпретацией. Базовые финансовые показатели приведены также в моем примере UNIT‑экономики выше. В любом случае, вы, Product manager, используете самые оптимальные решения в проработке и сборе продуктовых метрик. Какой это будет путь связки продуктовых показателей, выбор стоит всегда за вами.
Что хочу сказать Владельцу бизнеса:
Не грузите Product manager на входе на знание продуктовых метрик. Если я вижу, что на вашей стороне ваш представитель просит перечислить продуктовые метрики, я точно понимаю, что передо мной дилетант, который не способен построить продуктовый диалог по своему продукту, обсудить боли и выслушать возможное предложение от product-соискателя в рабочем диалоге. Обычно ссылаются на конфиденциальность в предоставлении данных и, таким образом, просто сводят на нет диалог по экспертизе. Происходит слив. Почему? Потому что представитель на вашей стороне не готов вести продуктовый диалог, не опытен в проведении таких интервью и просто находится на уровне между джуном и мидл.
За 12 лет работы в области построение продуктовой среды уже привыкла к общению с таким представителями. Печально видеть таких представителей при разработке очень масштабных проектов, т.к. они привносят колоссальные ошибки в разработку продукта, часто замедляют развитие и ведут продукт в другую сторону, приводят к регулярным косякам в работе при формировании пула задач и на этапе исполнения, и, как следствие, эти бедолаги провоцируют еще больший хаос в разработке продукта. Результат обычно я слышу, как боль Владельца бизнеса из разряда «Мы стартап и у нас есть небольшой хаос». А по факту они кричат «HELP!» Тот, кто умеет читать между строк, все поймет.
Благодарю за внимание!
Источник: