Метрики, которые успокаивают команду, но ничего не говорят о бизнесе

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

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

Почему удобная цифра может вести не туда

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

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

Три метрики, которые особенно часто успокаивают команду

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

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

Среднее время в сервисе. Долгое время может означать вовлечённость, а может — поиск нужной кнопки и ручные перепроверки. Без контекста это как измерять время в очереди и считать его признаком интереса к магазину.

Сначала — обещание продукта, потом — метрика

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

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

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

Как связать метрику с решением

У каждой цифры должен быть владелец вопроса, а не владелец отчёта. Не «рост активации на 8%», а «пользователь не понимает, с чего начать после регистрации; проверяем новый первый шаг». Такая формулировка заставляет перед изменением назвать гипотезу и после — посмотреть не только на рост графика, но и на побочный эффект.

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

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

Не подменяйте понимание отчётностью

Числа хорошо отвечают на вопрос «что изменилось». Они хуже отвечают на вопрос «почему». Если после релиза показатель прыгнул, полезно снова посмотреть на реальные действия: запись сессии, обращение в поддержку, разговор с пользователем, путь заявки, ошибку в данных. Не для того, чтобы найти виноватого, а чтобы не объяснять сложную работу одной удобной причиной.

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

Небольшой ритуал перед встречей по метрикам

1. Назовите решение, которое вы собираетесь принять по итогам обсуждения.
2. Выберите один показатель, связанный с обещанием продукта.
3. Добавьте один защитный показатель, который покажет возможный ущерб.
4. Сравните цифры с реальным пользовательским случаем.
5. В конце зафиксируйте не вывод «стало лучше», а следующую проверяемую гипотезу.

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

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

Нормальная метрика переживает неудобный вопрос

На встрече полезно спросить: «Если этот показатель вырастет вдвое, мы точно будем рады?» Если ответ неочевиден, метрика требует контекста. Удвоение обращений в поддержку может означать, что клиенты стали активнее. А может — что релиз сломал привычный путь. Удвоение созданных проектов может говорить о спросе или о том, что пользователи не понимают, как завершить старый проект и начинают новый.

Второй полезный вопрос: «Какое решение мы бы приняли, если бы этой цифры не было?» Он помогает не строить отчёт ради отчёта. Если метрика не меняет ни приоритета, ни гипотезы, ни проверки, возможно, её стоит убрать из главного экрана и перестать требовать её на каждой встрече.

Не путайте метрики продукта и метрики занятости

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

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

Я бы держал эти два набора рядом, но не смешивал. Операционные показатели отвечают: «как мы работаем?» Продуктовые — «зачем эта работа пользователю и бизнесу?» Для руководителя важны оба ответа.

Как не потерять редкий, но важный сценарий

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

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

Что делать, если данных ещё мало

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

Пока данных мало, особенно важно заранее записать ожидание. «Мы считаем, что новый первый шаг поможет пользователю быстрее настроить рабочее пространство». Потом можно сравнить фактический путь с этой фразой. Без ожидания почти любой график можно объяснить задним числом, а это успокаивает ещё сильнее, чем красивая диаграмма.

Смысл метрик не в том, чтобы заменить разговор с клиентом числом. Они нужны, чтобы разговор стал точнее, а решения — менее случайными.