OKR-система: как измерять прогресс развития продукта с помощью индикаторов leading и lagging

Привет, это Оля, руководитель SEO-проектов и ведущий SEO-специалист HighTime.agency  Продвигаем IT/Tech-проекты в России и зарубежом 😎

Вы читаете перевод статьи Leading and Lagging Indicators: How to Measure the Progress of Product OKRs от Тима Хербига, тренера по управлению продуктами в Herbig.co. Тим более 10 лет работал в качестве менеджера и руководителя по продукту.

Идеально, когда Objectives and Key Results (OKRs) помогают выразить то, чего вы хотите достичь (метрики результата), а не просто перечисляют, что вы планируете сделать (метрики действий).

Тим Хербиг — тренер по управлению продуктами в Herbig.co, более 10 лет работающий в качестве менеджера и руководителя по продукту

Использование системы управления OKR в продуктовом менеджменте означает, что цели продукта вытекают из стратегических решений и служат связующим звеном, которое направляет действия на этапах Product Discovery и Delivery. Большинство команд фокусируются на метриках, которые отражают итоговый успех в ключевых стратегических направлениях, таких как монетизация, вовлеченность пользователей, рост, удовлетворенность или качество процессов.

Однако суть постановки целей OKR не должна сводиться только к измерению успеха в конце цикла или финансового года (что часто можно наблюдать в так называемом «OKR-театре»). Главная польза заключается в регулярной проверке прогресса и своевременной корректировке действий на основе этих данных.

Переход к циклу Learn-Measure-Build Cycle of Product Goals

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

Использование leading и lagging индикаторов в продуктовом менеджменте

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

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

Leading индикаторы позволяют предсказывать будущее. Их трудно создать, но они стоят того.

Если кратко, ключевые различия между leading и lagging индикаторами можно описать так:

Разница между leading и lagging индикаторами

Эти различия становятся более очевидными в следующих примерах OKR. Но помните, что это всего лишь примеры. То, как выглядят leading и lagging индикаторы для вас, сильно зависит от ваших команд, компании и продуктов. Даже такие метрики, как NPS (индекс лояльности) или Churn (отток), которые кажутся исключительно запаздывающими, могут иметь разное значение на разных уровнях компании. Ниже показан общий тип взаимосвязи между этими двумя видами метрик, а не конкретные показатели.

Примеры метрик продукта для leading и lagging показателей

Как и во многих аспектах продуктового менеджмента, в этом, казалось бы, черно-белом взгляде на индикаторы существует множество оттенков серого. Однако четкое разделение этих показателей может стать важным элементом методологи OKR.

Разделение leading и lagging индикаторов через контекст

Более точная категоризация метрики как leading или lagging зависит от контекста. Хотя существуют общие шаблоны, определяющие, какие OKR чаще являются leading или lagging, нет простого способа определить это без глубокого понимания того, как они используются в конкретной ситуации. Это означает, что одна и та же метрика может быть leading в одном сценарии и lagging в другом. Рассмотрим упрощенный пример:

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

Для этого может быть поставлен OKR, например, «Средний доход от обновления на клиента за квартал — $250». В этом случае увеличение ARR (годового регулярного дохода) среди активных пользователей будет lagging показателем (конечной целью), который можно измерить только постфактум. А средний квартальный доход от обновления позволяет прогнозировать вероятность достижения этой цели.

Ежеквартальный показатель «Доход от обновления» является leading индикатором на уровне OKR компании, но с точки зрения продуктовой команды он является lagging индикатором.

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

Поэтому, чтобы найти свой ведущий показатель OKR, этой продуктовой команде нужно ответить на вопрос: на какие действия можно напрямую влиять и отслеживать их часто. Сосредоточьте усилия на исследованиях (Discovery), на поведении и проблемах пользователей с низким MRR (месячным регулярным доходом). Они могут выявить более ведущие результаты (Outcomes), которые помогут улучшить «Средний квартальный доход от обновлений». Например:

• «Использование большего количества функций маркетинговых инструментов без переключения между приложениями» можно измерить через такой OKR, как «Количество активно используемых интеграций на одного пользователя».
• «Время, затраченное на процедуры установки интеграций».

Но это всего лишь два аспекта контекста вокруг lagging и leading показателей. А как насчет внутренних или платформенных команд? Представьте точку зрения команды, которая отвечает за инфраструктуру партнерств в Postgorilla. Для этих команд «Количество активно используемых интеграций на одного пользователя» — это lagging показатель.

Как leading показатели одной команды становятся lagging показателями другой

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

• «Количество интеграций, готовых к использованию по умолчанию (SSO)».
• «Количество дней без приоритетных сбоев API интеграций».

Это помогает им сформулировать leading OKR, на которые они могут напрямую влиять.

Избегайте обобщенных определений, пытаясь определить leading показатели для программы OKR. Вместо этого учитывайте контекст метрики: можете ли вы напрямую влиять на нее и непрерывно отслеживать ее изменения? Если да, то, скорее всего, это ценный ведущий показатель для вас. Если нет, проведите обратный инжиниринг lagging показателя, чтобы определить, внедрение какой OKR помогут вам двигаться в правильном направлении. Использование подхода “Работа от обратного”, о котором мы поговорим позже, может стать хорошей отправной точкой.

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

Как измеряется метрика: теоретически, NPS может быть более ведущим показателем, чем доход, исходя из пользовательского пути. Но если NPS измеряется только один или два раза в год, он становится скорее lagging из-за почти полного отсутствия возможности оперативно отслеживать изменения.

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

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

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

Причинно-следственная связь и корреляция в lagging и leading показателях

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

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

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

Leading и lagging показатели, последовательность и различие результатов и итогов

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

Но как прийти к такому подходу?

Определение правильных leading показателей для вашего продукта

Замена более определенных leading показателей на более сложные в измерении, но более отзывчивые leading показатели — ключ к созданию эффективного цикла разработки.

В нашем примере с командой интеграций Postgorilla представьте, что компания сосредоточена на доходе от подписок в текущем цикле целей. Есть три фактора изменения дохода:

• привлечение новых клиентов
• апселлы (upsells)
• снижение оттока (churn reduction)

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

В работе над функциями интеграций в одном отделе Postgorilla сталкивается с двумя основными проблемами:

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

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

Это ключевая дилемма при определении ведущих показателей: баланс между определенностью на уровне компании и оперативностью на уровне командных действий.

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

Вопросы для определения leading и lagging показателей

Ключевой сдвиг в мышлении — выйти за рамки изменений, направленных исключительно на пользователей. Особенно если вы работаете над продуктом с недостаточным количеством данных, рассмотрение действий и поведения стейкхолдеров или членов команды может быстрее привести к идеям для leading показателей. Полезным инструментом для расширения перспективы может стать Impact Mapping и его категория «Смежные актеры» (Adjacent Actors).

Использование инсайтов для работы от обратного

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

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

Теперь команда интеграций Postgorilla может использовать наводящие вопросы, чтобы определить ветви leading показателей, которые соответствуют критериям:

1. Прямо связаны с действиями команды.
2. Предсказывают будущий успех (например, использование интеграций или апселл клиента).
3. Значительно изменяются в течение цикла целей.

Определение leading показателей через работу от обратного

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

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

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

Определение leading показателей в продуктовом менеджменте через вопрос «ЧТО?»

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

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

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

Адаптация ведущих показателей к Outcome OKRs

Использование методики OKR уже представляет множество вызовов для продуктовых команд, особенно при управлении стратегией и процессами исследований. Но самая распространенная проблема — выбор Key Results, которые балансируют между задачами или артефактами (Output OKRs) и изменениями в поведении, которые создают результаты (Outcome OKRs).

Примеры Output и Outcome OKRs

Может быть сложно разделить Output и Outcome OKRs, если вы привыкли рассматривать OKRs как единый направляющий показатель. Однако понимание различий между ними может стать ключевым способом для вашей команды принимать решения о том, что делать дальше (Output) и как анализировать прогресс (Outcome).

Матрица leading и lagging показателей

Часто используемое упражнение для превращения Output Key Results в более Outcome-ориентированные — задавать вопрос «Почему?»

«Провести анализ конкурентов!»

Почему?

«Создать больше идей для приложения.»

Почему?

«Повысить вовлеченность мобильных пользователей.»

…и так далее.

Но при попытке определить Key Results, которые более ведущие, чем запаздывающие, важно добавить второе измерение. Оно помогает понять, насколько leading или lagging является ваш Output или Outcome Key Result.

Применение направляющих вопросов для определения leading метрик

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

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

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

Переход от lagging к leading метрикам в продуктовой команде

Как видно, команда Postgorilla начала с набора ключевых результатов OKR, ориентированных на Output (результаты действий). Чтобы выйти на уровень Outcome (результаты изменений), они использовали вопрос: «Почему это важно?»

Например, метрика «2,8 активных интеграций на клиента» технически была определена как Outcome, но её измерение было бы возможно только по завершении цикла. Тогда команда задала следующий вопрос: «Какие действия должны чаще выполнять наши клиенты, чтобы мы достигли успеха?» Это позволило сформулировать более опережающие, но всё ещё ориентированные на Outcome ключевые результаты.

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

Двигаемся дальше: не только формальные Outcome OKRs

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

Однако сами по себе Outcome OKRs не гарантируют успеха. Можно сформулировать ключевые результаты, описывающие изменение поведения, но если они не поддаются измерению в рамках одного цикла, их ценность снижается.

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

Решение о фокусе на leading или lagging метриках, а также баланс между Output и Outcome должно основываться не только на теоретических матрицах, но и на реальной системе OKR в вашей компании. OKRs должны быть инструментом для измерения и управления продуктовой стратегией в вашем контексте.

Вывод: фокус на leading метриках для оперативного принятия решений

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

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

С вами была руководитель SEO-проектов и ведущий SEO-специалист HighTime.agency Ольга Горская ❤️. Сохраняйте эту статью — она станет вашим надежным инструментом при постановке и достижении целей вашего отдела или всей компании!

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

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

И главное: работа с OKRs и метриками — это всегда эксперимент. Вы должны быть готовы тестировать гипотезы, анализировать данные и адаптироваться к изменениям. Как показано в статье, успех приходит к тем, кто умеет балансировать между определенностью и оперативностью.

Сохраняйте этот материал, применяйте его в своей работе, и пусть ваши продукты достигают новых высот! 🚀