Построить unit-экономику, вырастить ретеншн и посадить дерево метрик
У всех бывает, но не у всех проходит.
Любой продакт использовал RICE, любой пытался переписывать требования в формате Job Stories, и уж наверняка, мучал своих пользователей «проблемными» или «решенческими» интервью, иногда совмещая оба подхода сразу!
В списке продуктовых клише особняком стоит любовь к построению деревьев метрик. Дерево метрик — это стандарт. Без дерева метрик от вашего приложения будут отваливаться кнопки и сыпаться прямо на столы и в карманы пользователей, а backend перепишется с C# на 1С.
И не родился еще такой продакт, который смог бы подтвердить обратное — деревья метрик рисуют абсолютно все.
Я не планирую развенчивать концепцию дерева метрик — однако хочу показать границы, в которых эта модель работает хорошо и в которых требует более глубокого понимания своей природы.
Я предлагаю думать про дерево метрик так:
— Это иерархическая модель метрик продукта
— Это Path Model каузального взаимодействия метрик продукта
Иерархическую модель метрик не всегда просто построить, но всегда просто интерпретировать. Если вы договорились об NSM, OMTM и ключевых драйверах их роста — вы уже получили простой ответ на сложный вопрос: что для вашего продукта важно.
Однако, редко кто довольствуется формулой «Метрика 1 важнее, чем Метрика 2». Бизнесу интересно другое: «Если Метрика 2 увеличится на 5% то как увеличится Метрика 1?» или еще интереснее: «Если Метрика 6 увеличится на 5% то как увеличится Метрика 1?»
В этом случае нам пригодится концепт Path model — это статистический инструмент, который позволяет схематически изобразить независимые и зависимые переменные. Если мы построили дерево метрик, значит, мы уже знаем наши зависимые и независимые переменные, их осталось только определить. Принято говорить, что зависимые переменные «объясняются» независимыми.
Простой пример: Метрика Revenue (sic!) «объясняется», например, количеством заказов и средним чеком, а количество заказов — числом пользователей и конверсией. Revenue, количество заказов и конверсия — зависимые переменные. Число пользователей, средний чек — независимые: принять их за данность и не «объяснять» — это вопрос выбора исследователя и гранулярности модели.
✝️Зависимая переменная, не может быть исчерпывающе «объяснена». Сколько бы факторов вы не выбрали чтобы объяснить Revenue, ваши прогнозы всегда будут содержать ошибку — некоторый объем необъясненной дисперсии, в том числе из-за фактора случайности.
Следовательно, чем длиннее цепочка зависимых переменных, тем выше пропорция необъясненной дисперсии ближе к концу цепочки => выше ошибка ваших прогнозов. Если вы строите комплесный продукт и пытаетесь понять, как на NSM отразится метрика, которая находится на несколько уровней ниже — какой бы высокой или низкой ни была эта величина в реальности, модель дерева метрик даст вам не больше, чем дала бы простая догадка.
✝️Даже если вы идеально определили каузальный порядок ваших метрик, дерево метрик подразумевает линейную зависимость переменных — многие процессы в продукте нелинейны. Каждый шаг цепочки содержит ошибку, чем дальше от NSM — тем выше эта ошибка.
Rule of thumb — если хотите использовать дерево метрик, как предсказательную модель, то не уходите дальше, чем на 2-3 уровня вниз. Естественно, это очень ограничивает использование этой модели, как способа количественно оценить приоритеты продукта.
Иллюстрации в следующем посте
#product_management #it #метрики #metrics
Post #29
242
- ❤ 5