Команда отчитывается: за квартал выпущено двенадцать функций. Звучит как успех. Но единственный честный вопрос — стало ли пользователю лучше: ушла ли боль, ради которой всё затевалось. Часто ответа нет, потому что его никто не мерил. Мерили другое — сколько сделали, а не что изменилось.
Здесь проходит граница между выпуском и исходом. Выпуск — это то, что ты отгрузил: фичи, экраны, строки кода. Исход — это то, что изменилось у пользователя: задача стала решаться, шаг исчез, ошибка перестала случаться. Продукт-мышление мерит исход. Выпуск — лишь средство, и спутать средство с целью — самый частый способ быстро бежать не туда.
Выпуск измеряет тебя, исход — пользователя
Выпуск удобно считать, потому что он целиком под твоим контролем и виден сразу: фича либо в проде, либо нет. Поэтому к нему так тянет — он даёт ощущение прогресса. Но он описывает твою активность, а не пользу. Можно отгрузить десять функций и не сдвинуть ни одной пользовательской задачи.
Исход неудобен ровно противоположным: он про пользователя, проявляется не сразу и зависит не только от тебя. Зато только он отвечает на вопрос, зачем всё это. «Продавец заводит каталог за вечер вместо недели», «доля брошенных корзин упала», «в поддержку перестали писать про этот шаг» — это исходы. Они описывают мир после того, как проблема была решена, а не объём проделанной работы.
Как выбрать метрику исхода
Метрика исхода выводится прямо из названной проблемы. Если проблема — «новый продавец не может быстро поднять каталог и не стартует к сезону», то метрика — доля новых продавцов, заведших каталог за разумный срок, или время от регистрации до первой продажи. Не «сделан импорт», а «продавцы стартуют».
Хорошая метрика проходит три проверки. Привязана к пользователю — описывает его поведение или его результат, а не твой выпуск. Двигается в обозримый срок — иначе по ней нельзя рулить. И её трудно накрутить, не решив проблему по-настоящему: если метрику можно «улучшить» хитростью, не помогая пользователю, она плохая.
Часто полезно держать одну метрику исхода как главную и пару страховочных рядом, чтобы не оптимизировать одно за счёт другого. Время до первой продажи можно «улучшить», впуская мусорный каталог, — поэтому рядом смотрят на качество карточек или возвраты. Главная метрика задаёт направление, страховочные не дают срезать угол.
Ловушки измерения
Первая — метрики тщеславия: числа, которые приятно показать и которые всегда растут, но ничего не говорят о решённой проблеме. Суммарное число регистраций, количество функций, общие просмотры. Они создают иллюзию движения. Тест простой: если метрика выросла, а ты не можешь сказать, кому стало лучше, — это тщеславие.
Вторая — мерить то, что удобно для отчёта, а не то, что важно. Выпуск попадает в эту ловушку первым: его легко посчитать, поэтому им и отчитываются. Удобство измерения не должно решать, что измерять.
Третья — оптимизация не туда. Любая метрика, став целью, начинает деформировать поведение: команда честно тянет именно её, и если она выбрана неверно, ты получишь ровно то, что просил, и не то, что хотел. Поэтому метрику выбирают осторожно и пересматривают, если она начала жить отдельно от пользы.
Держать исход в фокусе одному
Когда весь путь ведёт один человек, метрика исхода — это его руль и его совесть. Некому со стороны спросить «а стало ли лучше?» — спрашивать должен он сам, и до выпуска, и после. До — чтобы решить, стоит ли вообще делать: какой исход мы ждём и как поймём, что он наступил. После — чтобы замкнуть петлю: посмотреть, сдвинулась ли метрика, и если нет — не праздновать отгруженную фичу.
Это же спасает от перегруза. Когда ясно, какой исход важен, видно, что многие задачи его не двигают, — и их можно не делать. Метрика исхода превращает бесконечный список «хорошо бы сделать» в короткий список «это сдвинет то, что важно». Без неё продукт-инженер меряет себя выпуском и устаёт, не понимая, помог ли кому-нибудь.