Заметки на полях Ошибка продуктовых компаний: они часто измеряют то, что растёт, а не то, что объясняет экономику продукта Например, онлайн-кинотеатр измеряет часы просмотра и рапортует, что они выросли на 2%, примерно до X млн. часов. Но если аудитория при этом выросла быстрее, то watch hours per subscriber могли снизиться. То есть агрегированная метрика позволяет рассказать историю «engagement растёт», даже если средний пользователь смотрит меньше. Это универсальная ловушка: для растущих платформ абсолютные метрики почти всегда выглядят лучше когортных. Поехали дальше. Но возможно, watch hours per subscriber вообще не главная метрика онлайн-кинотеатра. Пользователь платит не за каждый просмотренный час. Он платит за опциональность: «Когда мне захочется что-нибудь посмотреть, у сервиса будет что предложить». Ценность продукта не обязана быть пропорциональна интенсивности использования. Поэтому человек, который посмотрел онлайн-кинотеатр 8 часов, необязательно менее ценен или менее удовлетворён, чем человек, посмотревший 25. Для бизнеса гораздо важнее: есть ли у пользователя достаточно причин не отменять подписку? Поэтому engagement надо связывать не с количеством часов, а с вероятностью продления подписки. Интересная продуктовая метрика могла бы выглядеть скорее так: контент → просмотр → ценность → retention → revenue. И тогда может оказаться, что дополнительные 10 часов просмотра почти ничего не дают retention.А один сериал, который человек действительно ждал, даёт очень много. То есть не все часы одинаковы. Более того: разные типы просмотра имеют разную экономическую ценность. Час прямой трансляции ЧМ по футболу и час сериала одинаково попадут в метрику watch hours. Но бизнес-эффект может быть совершенно разным. Сами понимаете, почему.

Интересное про ChatGPT как продукт. Если кто не знал, вся AI индустрия держится на двух китах - OpenAI и Anthropic, на которые по разным оценкам (Wells Fargo, Barclays и др.) приходится 85-90% всего мирового спроса на AI компьют! И 70%+ AI выручки гиперскейлеров - тоже от них. А не от собственных AI продуктов, у которых есть фантастические возможности дистрибьюции (как у Майкрософта например). ChatGPT - главный consumer продукт всей индустрии, поэтому по его трендам можно делать какие-то выводы обо всем мировом genAI. 1️⃣ Многие заметили, что с недавних пор Револют на своих тарифах бесплатно предлагает подписку ChatGPT Go вместо Perplexity. Нередко компании делают так, чтобы в отчетности увеличить число юзеров платных тарифов. Например Perplexity их считал как платных, но на бумаге была строка Discounts and Refunds с большим убытком, почти в половину выручки! (в этом посте есть картинка с примером отчетности). 2️⃣ Но самое интересное, что в начале года OpenAI планировало падение числа $20/m подписчиков Plus с 44 млн до 9 млн! (the information) При этом число более дешевого тарифа Go должно было вырасти с 3 млн до 112 млн. И это должен быть самый быстрый в истории рост базы платных подписчиков. Сначала OpenAI стал раздавать Go бесплатно в Индии, потом были еще акции (Shopee и др.), а сейчас дело дошло до 75 млн клиентов Революта - теперь каждый из них может по сути бесплатно пользоваться Go. 3️⃣ Аналитики пишут, что такие сложности, да и сам новый тариф Go потребовались, потому что ретеншн на Plus за $20/мес уж очень плох, и даже общее число стало падать. Поэтому придумали такой витиеватый план показать бурный рост юзеров платных тарифов. Кстати по майским инсайдам The Information конверсия из бесплатного в платный, когда были только Plus/Pro - 2,58%, а с появлением Go уже почти 6% - я об этом писал, что у революционного технологического продукта не может быть конверсия в платного на уровне плохих бенчмарков b2c. А саму конверсию я посчитал точно - 2-3%, почти полтора года назад. 4️⃣ OpenAI не смог достичь собственных прогнозов на 2025 год в 1 млрд WAU у ChatGPT, даже к лету 2026 число пользователей растет крайне медленно. Я тоже писал, что ChatGPT больше некуда расти - просто нет столько людей в мире. А значит и сложно впечатлять инвесторов ростом выручки. 5️⃣ Есть прикольное жопокрутство от OpenAI: про b2b юзеров компания пишет paying business users, а про b2c - просто consumer subscribers. То есть там очевидно есть те, кто пользуется Go или другими тарифами, но не платит. При этом техкранчи и рейтерсы пишут сразу про всех paid users. Ну да, это же мелочи (нет). 6️⃣ Короче говоря, самый популярный из AI продуктов и единственный AI продукт среди популярных, ChatGPT - сталкивается со своими сложностями. Считаю, что все, кто как-то планирует бенефициировать на AI, должны следить за динамикой ChatGPT и его метриками. Потому что у остальных горизонтальных AI продуктов они почти всегда хуже 🥲 @kyrillic

Помогает ли обращение к клиентам по имени? Звоню тут в одну компанию, задаю свой вопрос, а девушка вместо ответа такая: — Подскажите, как могу к вам обращаться? И потом в разговоре постоянно говорит «Илья» в неожиданных местах. Раздражает и сам исходный вопрос, и противоестественное использование ответа в дальнейшем разговоре — люди не называют имена друг друга так часто. Каждый раз, когда я сталкиваюсь с подобными тупыми вещами, я слышу что-то вроде «ну это тебя бесит, но большинству нравится». Поэтому я всегда сомневаюсь, может, я зря по себе сужу? Взять уродские открытки на праздники в Вотсапе — очевидное дерьмо, но люди обмениваются ими и, видимо, через это чувствуют какой-то контакт и внимание. Или искусственное подсмехивание в ситкомах — тоже бесит, но вроде как измеримо повышает зрительские симпатии. Вероятно, существует и какая-то теория, что насильственное обращение по имени положительно влияет на лояльность клиентов? Я готов был бы смириться с этим, если бы знал, что это хоть и бесит, но хотя бы работает. Однако ведь наверняка все эти компании это используют просто потому что где-то слышали, что так надо. Они не знают, есть ли от этого прок, и даже вопросом таким не задаются, просто верят. Им кажется, что «хуже не будет», хотя так и хуже. Так вот вопрос. А как это вообще померить?

Чек-лист, что должен проверять продакт в AI-продуктах и чатах в частности 1. Правило 5–10 кейсов. Составь базвый золотой датасет из 5–10 эталонных юзкейсов (например, для AI-саппорта: возврат денег, смена адреса, жалоба на хамовитого курьера) и автоматизируй их проверку. 2. Один скорер = одно измерение. Главная ошибка PM - оценивать ответ модели одной общей метрикой «хорошо/плохо». Для кейса с возвратом денег разбей оценку на три отдельных скорера: • Точность (Accuracy): нашел ли бот правильную транзакцию? • Тон (Tone): вежлив ли бот, выразил ли эмпатию? • Безопасность (Policy): не пообещал ли бот возврат денег в обход регламента? 3. Human Review нельзя убирать. Автоматический код легко проверит, сделал ли бот запрос к базам данных. Но оценить, не звучит ли ответ как бездушный робот, пока может только человек. 4. Разрыв между топом и медианой. Команды с авто-эвалами видят, что новое обновление модели сделало бота супер-вежливым, но снизило точность поиска заказов на 10% и откатывают деплой. Команды без эвалов выкатывают регресс в прод и ловят волну негатива от клиентов. 5. 3 фазы внедрения на примере AI-саппорта: • Инкубация: собираем золотой датасет частых вопросов клиентов. • Шлифовка: weekly-демо, жесткие критерии (*«бот должен прикрепить ссылку на форму возврата, но не закрывать тикет сам»*) и просмотр цепочки рассуждений бота (Debug Mode). • Масштабирование: авто-тесты перед каждым деплоем и Slack-канал, куда автоматически падают все «дизлайки» от пользователей с логами беседы. 6. Чек-лист: как внедрить Evals за 5 шагов: • Собери реальные логи чатов, где бот ошибся. • Сформируй из них точечный датасет на 10–50 примеров. • Сравни две версии промпта side-by-side на одном и том же датасете. • Настрой автоматический ночной прогон тестов (Nightly Evals). • Настрой алерты на дизлайки пользователей прямо из продакшена. 7. Метрики качества AI-бота: • Accuracy: % корректно решенных вопросов без эскалации на оператора. • Tone & Brand Alignment: соответствие гайдлайнам компании. • Schema Compliance: отдаёт ли бот корректный JSON для API вызовов. • Latency & Cost: задержка ответа (в сек) и стоимость токенов на диалог. Источник: https://www.braintrust.dev/blog/evals-for-pms](https://www.braintrust.dev/blog/evals-for-pms #PG_education

Почему цифры на слайдах врут Топ-зацепок к тому, что вам показывают (1) Метрики часто подменяют стратегию (сурrogation) Люди мысленно заменяют абстрактные стратегии измеримым показателем. Например, учитель учит сдавать тесты, а не понимать предмет Компания Wells Fargo хотела построить долгосрочные отношения с клиентами и измеряла это кросс-продажами дополнительных счетов. Итог: 3,5 млн счетов, открытых без согласия клиентов. Разрушено ровно то, ради чего все затевалось (2) Как только показатель становится целью, он перестает быть хорошей мерой (Закон Гудхарта) Любая наблюдаемая статистическая закономерность склонна к разрушению, как только на нее оказывается давление с целью контроля Те, кто ставят цель, часто имеют неполное представление о процессе. Внимание, направленное на абстрактные метрики, оставляет что-то важное в тени KPI Тестировщиков в ИТ могут измерять по количеству найденных багов. Но в итоге, ребята могут создавать баги-пустышки или начать дробить большую задачу на мелкие, чтобы повысить такую метрику (3) Улучшение метрики может означать ухудшение реальности Представьте себе хирургов, которые заполняют отчеты о хирургических операциях. Чтобы повысить свои показатели, некоторые хирурги отказывают пациентам с худшими шансами на успешный исход Это значит, что тяжелобольным становится все сложнее найти хирурга. Люди умирают, метрика улучшается (4) Вы не можете понять, почему происходит Х, рассматривая только те случаи, когда Х происходит (ошибка выжившего) Очень хороший пример, когда наши эмоции, в том числе, толкают в сторону неверных выводов –  Представьте себе случай массовой стрельбы, освещенный в СМИ. Часто в биографиях стрелков обнаруживают, что они играют в "жестокие" видео игры. Но вопрос не в том, играют ли они, а в том: - играют ли они больше других? - становятся ли люди жестокими, играя в жестокие видео-игры или люди играют в такие игры, потому что жестоки сами по себе? - к чему приводят такие игры: к увеличению насилия или к безопасному выплеску? (5) Спрашивайте, чего в данных нет Вы исследовали людей, которые у вас что-то не купили, хотя были на вас подписаны? А как насчет людей, которые не купили, потому что даже о вас не знали? Ушло 100 клиентов, вы опросили 20 ответивших и сделали выводы? А что с молчунами? Бонус Данные никогда не сырые, вы просто иногда впервые с ними сталкиваетесь. Данные осмысляются, фиксируются и собираются, в результате человеческих решений: что именно измерять, когда, где и каким методом У цифры всегда есть автор со своими особенностями и интересами 🔗 Кружок кройки бытия

Репосты — главная метрика канала Я как-то осторожно уже об этом говорил, но сейчас готов кровью подписаться. Причин 2: 1. Репосты растят охваты, а охваты влияют и на стоимость рекламы в канале, и на вовлечённость (целевые действия в посте). У меня есть пост со 100+ непубличными и парочкой публичных репостов6 и он продолжает бешено собирать охваты. 2. Репост кричит о ценности контента: если прочитавший решил поделиться с ближним вашими мыслями, это гораздо более ценно, чем прожатое сердечко или написанный комментарий, это признание небезразличия (даже если ваш пост переслали с комментом типа "смотри какой дебил") Именно в такую виральность я стараюсь бить своими постами и именно эту метрику обсуждаю с нейронкой перед публикацией.

Цифра ~50% почему-то часто не пугает людей, когда речь про AI-ассистентов. Каждый второй запрос в стену? Ну ок, бывает, докрутим. Это странно, ибо если переложить те же 50% на более классический продукт, который мы все умеем оценивать, отношение будет другим. К примеру, интернет-магазин, который не создаёт каждый второй заказ, никто «докручивать» не будет — его чинят в ночь, в дождь, вопреки, потому что всем очевидно, что он сломан. Но представим магазин хитрее: заказ создаётся, а дальше то не доставят, то привезут не то или не туда, то спишут другую сумму. При этом снаружи всё может выглядеть как успех с непоколебимым покерфейсом: корзина, чекаут, «спасибо за покупку». Ассистенты чаще ломаются именно так. Там, где классический софт падает с ошибкой, LLMки отвечают: «подписку отменил», а по факту ничего не отменил, «операция корректна», а она снесла прод-базу. Ровно тот самый идеальный покерфейс, и у пользователя обычно не хватает компетенций отличить правильный ответ от уверенного вранья. Отсюда и разница в обратной связи. Косячащий магазин закидают жалобами и единицами в отзывах за день: чтобы понять, что привезли не то, экспертиза не нужна. А к ассистенту человек приходит ровно потому, что сам не знает ответа. Отличить хороший результат от плохого ему часто нечем, так что уверенный бред спокойно собирает свои пятёрки, либо собирает негатив с большой задержкой, либо вовсе выглядит как падающий ретеншн. Откуда тогда спокойствие команд? Моя гипотеза: дело в лёгкости лицезрения. Метрики магазина дешёвые: доля созданных заказов, SLA доставки, возвраты. Собираются за день и орут с дашборда красными огнями. Если даже никто дашборд не построил, то быстро прибежит СЕО и заставит сделать сэппуку. Метрика качества ассистента дорогая, это тот самый бенчмарк и нудные месяцы работы. А пока бенчмарка нет — нет и дашборда, на котором могло бы загореться красное. А когда мы измеряем что-то, то часто это улучшаем. Если не измеряется, то «вроде работает» будет достаточно. Дешёвая метрика тычет тебя носом в провал, а дорогая разрешает жить в неведении и называть это оптимизмом. Так что если у команды ассистента нет бенчмарка и эвалов, это не значит, что у неё нет 50% фейлов. Это значит, что она узнает о них последней.

Как измерять работу программистов CEO и CFO приходят к CTO с вопросом: можно ли оптимизировать затраты на разработку? Как понять, кого уволить, а кто хорошо работает? Кому сколько платить? В среде программистов есть много мнений по поводу метрик и нужно ли измерять производительность разработчика. Очевидные метрики, которые придумает HR: - Присутствие на рабочем месте - Количество выполненных задач - Количество часов, затраченных на выполнение этих задач - Уложился ли в план

Неочевидные метрики, которые добавит CTO: - "Бизнес ценность" — баллы, которыми стейкхолдеры оценивают задачи по их значимости или приоритету для бизнеса. - "Стори пойнты" — баллы трудоёмкости. Разработчики собираются на "Покер Планирования" и оценивают задачи между собой. Используют футболки (XS, S, M, L, XL) или степени числа 2 (1, 2, 4, 8, 16, 32). - Количество багов в коде, написанном разработчиком. - Скорость — любые баллы делим на время. - % отклонения от собственной или командной оценки.

Проблема заключается в том, что индивидуальный разработчик может провалить все эти метрики, но при этом положительно влиять на производительность команды. Или же выполнять план, но демотивировать группу. Рассмотрим роль тимлида в качестве примера: индивидуальная отгрузка ниже среднего, но каждый разработчик под его влиянием работает быстрее и качественнее. Увольнять его на основании общих метрик просто преступно. Программисты под надзором точно работают, без него — состояние неопределённое. Поэтому без внешнего контроля не обойтись. Что с этим делать? - Если хочется кого-то уволить или повысить — спросите менеджера отдела. Он всё знает без метрик. Для уверенности проведите 360-градусную оценку. - Всё равно измерять все возможные/удобные показатели, но не принимать решения только на них. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵

Наткнулся в LinkedIn на пост чувака, который предлагает "a little more breathing room" дизайну главного экрана Революта. Объясню в чем проблема таких Dribble концептов. Этот экран генерирует миллиарды долларов выручки. Со стороны, не зная метрик этого экрана и остальных, на которые он разводит дальше, ты никогда не сможешь понять где есть проблемы и точки роста. Ты просто галлюцинируешь. Дизайн как "я нарисовал красивое" умер еще лет 5-10 назад. Сейчас это такая же инженерная профессия, как и большинство других в продуктовой разработке. Ты должен глубоко понимать метрики продукта, клиентские сегменты, конкуренцию по рынкам. В противном случае ты будешь рисовать картинки, которые никому уже не нужны.

Если 7 % когорты возвращается на 7ой день, то ты уже в топ-25% по активации 1. Правило 7%. Если 7% когорты возвращается на день 7, то твой продукт уде показал раннюю ценность, которая коррелирует с долгосрочным успехом. И ты уже в топ-25% по активации. 2. Ранняя активация предсказывает долгий retention. 69% продуктов из топа по дню 7 были в топе и через 3 месяца. 3. У половины продуктов к концу 2-й недели неактивны больше 98% новых. Даже у топ-10% на день 14 остаётся всего ~9%. 4. У энтерпрайза топ-10% держат 12.4% на день 7 против медианы 2.1%. Разрыв в 6 раз. 5. Разброс по сегментам (retention 3-го месяца у лидеров): тревел 25.6%, финсервис 19.5%, B2B-софт 15.6%, энтерпрайх 12.4 % у лидеров. 6. Что сделать для удержания. Очевидно, пункт номер один - построить хороший онбординг: • найти свой момент ценности через когортный анализ, • сократить time-to-value, • разбить путь на чекпоинты, не вываливать все фичи сразу, • делать онбординг вокруг цели, а не фич, • снижать когнитивную нагрузку, • давать мгновенную обратную связь. 7. Метрики, предсказывающие удержание: • time-to-value по сегментам, • activation по источнику трафика, • глубина (не один экшен, а несколько + приглашение коллеги), • когортные дашборды. Источник: https://amplitude.com/blog/7-percent-retention-rule #PG_education @productgames

Почему продуктом управлять легко, а собой — нет Время чистосердечных после выходных и вот одно, которое пора подписать самому себе: большими системами и продуктами мне управлять кратно проще, чем банально записаться к врачу. С той же лёгкостью, с какой я в несколько потоков увлечённо тащу рабочее, я залипаю на простейшем бытовом действии: написать в стоматологию, заказать кроссовки для падела или купить билеты, хотя знают точно когда и куда мы полетим. Вполне удачно я месяцами списывал это то на расфокус, то на низкий приоритет. Красивые причины, но без сути. Потому что ни одна из них не объясняет, почему на работу энергии хватает на пять параллельных потоков сразу, а на одно сообщение в стоматологию — нет. Ответ оказался в разы проще и частью упирается в локус контроля, про который я писал в канале давным-давно. Дело в том, что это две разные системы, и управляются они по-разному. Вся разница — в одном: есть ли у системы обратная связь. Кто-то, кроме тебя, замечает, что она сломалась. С продуктом всё честно: если где-то поехало, сигналы будут — цифра просядет, кто-то придёт с вопросом, деньги не придут вовремя, ну и приходится реагировать, даже когда не хочется, потому что сигнал громкий и его видит не только он. С продуктом всё честно: если где-то поехало, сигналы будут — цифра просядет, кто-то придёт с вопросом, деньги не придут вовремя, ну и приходится реагировать, даже когда не хочется, потому что всё это громкое и видно не только мне. А по себе такого дашборда нет (увы и ах!). Никто не пришлёт мне сводку, да и ретро по себе никто почти не делает — единственный наблюдатель тут я сам, а судьи кто? И если за собранность в работе платят — деньгами, ростом, успехом, — то за собранность в быту не платит вообще никто: её попросту не видно, а потери приходят как раз тогда, когда её нет. Поэтому «доделаю ещё поток вместо того, чтобы записаться к врачу» выигрывает каждый раз — рабочий выигрыш это профит, а сделанное бытовое в лучшем случае не случившийся убыток. А получать профит всем морально проще, чем сейвить убытки. Забавно, но чинится это ровно тем же инструментом, что и продукты: 🔹 Метрика на себя. Раз бытовое само по себе невидимо, ему нужен счётчик — пара цифр, за которыми следишь как за продуктовыми: сколько дел по быту за неделю закрыл, а не перекинул дальше. Только чтобы их считать, задачи сперва надо где-то фиксировать — а жёлтые стикеры дома я пытался внедрять уже пару раз. Расти этой цифре, в общем-то, и незачем: она нужна, чтобы убыток, который иначе копится тихо, стал виден хотя бы мне. Без счётчика управляешь на ощущениях, а они врут первыми — ровно тогда, когда всё уже сыпется. 🔹 Отказ от алиби работы. «Сейчас не до этого, у меня запуск» — больше не индульгенция самому себе. Переношу, забиваю — но теперь называю настоящую причину хотя бы про себя. «Не хочу возиться с этой бытовухой» — честный ответ, с ним хотя бы можно что-то сделать. «Я занят важным» — ответ, который просто выключает счётчик, чтобы не смотреть, что там накапало. Продукт без метрик умирает за квартал — это все понимают и потому метрики ставят, не ленятся. А сам без метрик доезжаешь примерно туда же, только квартального отчёта об этом никто не пришлёт — заметить придётся самому, и желательно пораньше, пока ещё есть что чинить. А какое простейшее действие вы откладываете дольше всего — притом что на работе ворочаете вещами в разы сложнее? Константин Сухачев

От циклов к графам (часть 1) TLDR: цикл = отправная точка, а граф циклов = сеть циклов улучшения, которые наблюдают, подпитывают, ограничивают и корректируют друг друга.

Циклы – это процесс. Граф – их структура

Всё дело в том, что ИИ-циклы дают сбои. Сбои не случайны и есть 4 основных когнитивных ИИ-искажения и сбоя, которые кроются в природе самого ИИ-цикла. Первое искажение ИИ: закон Гудхарта ИИ-цикл видит только свою метрику и именно поэтому он будет искать все способы изменить эту метрику, включая способы, которые противоречат её назначению (привет, хакнутые "кем-то" KPI) ИИ просто не понимает, что в цикле создаётся сбой (часто, это не понимает и человек), когда он манипулирует собственной метрикой. ИИ(-цикл) считает, что делает именно то, для чего был создан на основе числа, которое незаметно оторвалось от реальности, которую оно представляло. Второе искажение ИИ: слепота к восходящему направлению Цикл направляет свою переменную к эталонному значению, но ничто внутри цикла не может проверить правильность самого эталона. Это как термостат в чайнике, который не может задаться вопросом, является ли 100° правильной температурой кипения воды (и должна ли вода вообще кипеть). И ровно также цикл ИИ-отдела продаж не может спросить сам себя, была ли предложенная им цена и оффер разумными для клиента и бизнеса. Цикл оценки просто не может усомниться в том, измеряют ли эталонные показатели что-либо, что чувствуют клиенты. И чем усерднее работает цикл, тем тщательнее достигается неверная цель, возвращая и усиливая ошибку №1. Третье искажение ИИ: внутренний ИИ-конфликт Реальные системы содержат множество циклов, и циклы, построенные независимо друг от друга, начинают бороться между собой. Цикл, оптимизирующий скорость отклика, подрывает цикл, оптимизирующий рассудительность, а цикл найма, отвечающий за рост базы знаний, создает нагрузку на цикл культуры, сохраняющий их качество ☯ Четвертый вид сбоя незаметный: система измерений внутри самого контура деградирует, потому что за наблюдателем никто не наблюдает Все эти показания могут плавать, каналы передачи данных ломаться, смысловое наполнение метрик меняться, цифры в одном отчёте ошибочно подтверждаться ИИ цифрой из другого и контур продолжит работать с данными, которые, по факту, уже никак не связаны с реальностью. Система, функционирующая по такому сценарию начинает напоминать фальшивый спектакль актёров-зрителей в одном лице.

Вот именно по следам этих кейсов и не только авторы статьи выше предлагают подход к оценке пользы от внедрения ИИ. OpenAI предлагает перейти к инженерному подходу - измерять не затраты на ресурс, а эффективность преобразования ресурса в полезный завершённый результат. В центре стоит метрика "полезный интеллект за доллар", которая раскладывается на четыре вопроса. Каждый вопрос - это не просто пункт в отчёте, а целая система сбора данных и принятия решений: 1. Выполняет ли ИИ действительно важную работу? Первый шаг - перестать измерять активность и начать измерять результат. Ценность создается не количеством сгенерированного текста, а завершенными полезными действиями. Важно  "определение завершенности" для каждого бизнес-процесса. Тот самый эффект который я называл ещё в 2019ом value в бизнес ноде. Например, для отдела продаж полезной работой будет не "сгенерировать 100 писем", а "отправить клиенту финальное письмо, которое утверждено руководителем". Это меняет фокус с процесса на результат. 2. Сколько стоит одна успешно выполненная задача? Это самый технический и важный пункт. Забудьте про цену за токен, она обманчива. Нужно считать полную стоимость одного принятого результата. И тут как раз вы можете фиксануть ROI, как я говорил выше. Формула простая: (Стоимость API-вызовов + Время персонала на промпты и правки + Время на проверку + Стоимость инфраструктуры) / Количество задач, принятых без доработок. Дешевая модель может давать много ошибок, требовать постоянных правок и в итоге обойтись дороже, чем более дорогая, но точная. Именно поэтому OpenAI выпускает GPT-5.6 с тремя моделями: Sol (для сложных задач, где ошибка дорога), Terra (золотая середина) и Luna (для рутинных операций). Выбор модели - это всегда поиск баланса между ценой и качеством конечного результата. Снова привет fusion или Fugu оркестрации. 3. Можно ли доверять результатам? Этот вопрос напрямую влияет на стоимость. Чем выше доверие к ИИ, тем меньше времени тратится на проверку. OpenAI выделяет тут три уровня зрелости: · Черновик. ИИ предлагает вариант, человек все перепроверяет. · Поиск и рассуждение. ИИ находит информацию и строит цепочки, но решения принимает человек. · Автономное действие. ИИ выполняет операции сам (отправляет письма, вносит данные). Для перехода на новый уровень нужно измерять доверие. Классифицируйте каждый ответ ИИ: · Зеленый –принят без изменений. · Желтый – требует легкой правки. · Красный – полностью переделан. Если доля "зеленых" ответов растет, значит, доверие повышается, а стоимость контроля снижается. 4. Растет ли ценность при масштабировании? Последний вопрос – про динамику. Даже если сегодня все хорошо, нужно следить, не ухудшается ли экономика при росте объемов. Ключевая метрика: Эффективность = Объем полезной работы / Совокупные затраты на ИИ Неплохая замена ROI в моменте, этакий аналог биржевого индикатора. Если вы увеличиваете использование ИИ в два раза, а затраты растут тоже в два раза - вы на месте. Если затраты растут медленнее - вы в выигрыше. OpenAI утверждает, что их модели постоянно улучшаются, а стоимость снижается. Но компаниям все равно нужно вести собственный счёт – собирать данные по каждому процессу и регулярно пересчитывать эффективность. Вот вам и новые задачи вашим аналитикам. 👍 Практический чек-лист для внедрения от OpenAI: 1. Выберите 3–5 ключевых процессов, где используется ИИ. 2. Для каждого четко определите «завершенную задачу». 3. Начните собирать данные о всех затратах (не только API, но и время сотрудников). 4. Ведите классификацию ответов (зеленый/желтый/красный). 5. Пересчитывайте стоимость за задачу и сравнивайте разные модели. 6. Раз в квартал оценивайте динамику эффективности. А как вы оцениваете вклад ИИ в своих проектах? Делитесь опытом в комментариях 👇👇👇

Время на "мы просто пробуем ИИ" уже закончилось. Как измерять реальную ценность от внедрения ИИ? Именно с этого отрезвляющего тезиса стартует статья от OpenAI. Теперь вы не можете как в 2023-2024, а кто-то все ещё сейчас просто экспериментировать ради любопытства, сегодня ИИ - это реальная производственная мощность, и нужно её измерять также, как электроэнергию или выч ресурсы. 📦 помнится, как оценивали качество от автоматизации ручных процессов или поддержки с ИИ: 1. Общий трафик DAU, MAU, WAU и тп. 2. Интерес, через возвращаемость ака retention rate. На самом деле, не так важно, что в первый день запуска вы вывалили большой трафик, как то, что если сервис полезен к вам будут возвращаться снова и снова. 3. Число принятых подсказок с ИИ - ака acceptation rate. К примеру, вы работаете с ИИ суфлером или код агентом копайлотом и вот число принятых подсказок по ответу оператора или коду можно было измерить так. 4. Польза в конечной бизнес ветке или ноде. Если вы работали с сценариями поддержки, на самом деле, автоматизация должна считаться не только числом закрытых вопросов в чате без перевода на оператора, но и измеряться закончился ли диалог на самом деле решением проблемы пользователя или он через час снова придёт с этой темой в чат (а тут уже retention rate работает против вас). Да это можно проксироват через CSI, NPS, но в век LLM и агентов можно верифицировать и без оценки человека, достигнуто ли было намерение юзера и решена проблема с которой он придёт. А ещё у нас была система штрафов за возвращаемость юзера по проблеме ещё раз в чат или к оператору. 5. Фин эффекты в лице ROI. Тут просто (на самом блин деле, ни фига не просто) отношение прибыли к затратам на ИИ сервис, фичу, решение, проект и тп. - скок заработали к тому сколько потратили на разработку, аммортиазцию железа и токены на эксплуатацию. Обычно измеряется в %, умножаетсы естественно на 100. Однако помимо этого, мало посчитать таким образом потенциал, ещё нужно посчитать срок окупаемости. ROI показывал, что мы имеем такой потенциал, а срок окупаемости за какое время мы его можем достичь. 6. Рост эффективности труда. Вот моё "любимое", что над именно считать на сколько уменьшится время на выкатку фичи, сервиса, продукта или нового кода/программы, ускориться принятие решения и тп. Ака Lead Time, Time to Market и аналоги. И да современный ИИ тут помогает. Почитали? Интересно? А теперь забудьте все не так радужно. Начну с ROI прям сразу - компании не умеют, а некоторые оунеры решений и не хотят считать это честно (не в смысле врут, а в смысле не все переменные учитывают). Часто в текущей реальности заканчивается оценкой скорости а-ля ТТМ, но никто не хочет посчитать деньги в конечной бизнес ноде. К примеру, вы смогли автоматизировать аналитику, сказали что ускоритель на К%, но почему-то не получаете оценку оборачиваемости капитала или out-of-stock (упущенные продажи) в денежках, на которые и повлияет ускорение принятия решения от внедрения ИИ. Но окей, вы посчитали это, но в знаменатель забудете положить кроме фот на разработку, ещё токен экономику и аммортизацию ваших мощностей (если они онпрем). Почти все не понимают, сколько токенов они будут кушатс. На самом деле, ну и не должны, вопрос ж в динамическом изменении этого, особено с МАС под капотом. Но раз тут у нас динамический показатель, то ROI не будет фиксой, как и поправки в срок окупаемости придётся вносить. Ну и мякотка, все хотят на старте это посчитать, а в вводных выше мы понимаем, что посчитать можно только по факту в начале (порой пальцем в небо) или за период (на конец отчетного), а без этого даже стартовать порой отказываются. Второе любимое это про экономию на ФОТ через автоматизацию. Ну тип дали людям огонь Claude Code и ща кааак начнём сокращать разрабов и экономить на дорогих манки кодерах. В итоге хороший agent developer с инструментом на max подписке кушает за себя и за Сашку. Те вы почти не экономите на ФОТ, тк сопоставимо тратите на токены.

Оптимизировать метрики или творить искусство Второе выступление было в МФТИ для преподавателей ВУЗов. Оно было посвящено разбору кейсов про управление образовательными продуктами. До меня слушателям рассказали про продуктовый подход к образованию (в частности, про JTBD и релевантные образовательным программам метрики), мне же предстояло поразбирать это на примерах. Рассказ я построил на семи кейсах: 3 из российской практики (про нашу русскоязычную специализацию по ML на Курсере), 4 из мировой. В каждом случае давалась вводная с описанием ситуации, дальше мы генерировали идеи «а что дальше» и разбирали, чем все закончилось и какие можно сделать для себя выводы из этого. Мой любимый пример был про то, как полярные отзывы о курсе могут быть хорошим знаком, что вы уже нашли ваш сегмент, и остается описание курса, объяснение, для кого подходит ваш курс, и все привлечение построить так, чтобы точнее попадать именно в свою аудиторию. В конце поговорили о том, ремесло или искусство преподавание и надо ли ко всем этим метрикам относиться слишком серьезно. Десятитомный Ландавшиц, например, это бесспорно легендарный образовательный продукт. Но retention, NPS и CSI у него ни к черту. Как и доходимость до конца. А чего стоят одни только шутки про «потерял целую тетрадь выкладок - напишем «очевидно что». Однако сложно представить, чтобы Ландау из-за этого переживал :) Похожая история с Колмоговорым: на него одновременно и жалуются за плохое чтение лекций на мехмате, где мысли сильно опережали речь, и вспоминают с восторгом его «даму с собачкой» (красивое объяснение доказательства основной теоремы алгебры) и учатся всей страной по его учебникам. Увы, далеко не каждый из нас Ландау или Колмогоров, чтобы позволить себе быть плохим лектором и все равно стать лектором и автором легендарным, поэтому нам и нужно смотреть на метрики курсов - чтобы обеспечить базовый минимум и потихоньку его улучшать. Но сам по себе этот базовый минимум, увы, не может заменить преподавателю ни талант, ни творческий подход к работе.

Кого вы на самом деле дрессируете своими KPI Неважно где и независимо с кем ты будешь работать — рано или поздно в воздухе обязательно возникнет задача: надо поставить команде или командам царь-KPI, по которым их будут потом гонять. Часто ещё, чтобы солиднее звучало, можно назвать это Northstar-метрикой (даже если по продуктовому смыслу она ею и не является). И тут часто есть неочевидная ловушка: любая такая метрика — всегда одна из. Одна из десятка, которые вместе и описывают, как команда работает, но стоит повесить её на стену и сказать команде «вот по этому мы вас и меряем» — как всё остальное тут же уходит на задний план, что логично, ведь мотивация завязана именно на неё. Но цимес в том, что бизнесу эта метрика не всегда приносит пользу. Когда метрика перестаёт быть индикатором или термометром и становится самоцелью, её, понятное дело, начинают стимулировать любой ценой. И вредительства со стороны команды тут никакого нет, если что, — просто так была поставлена задача. И вот так вы быстро оказываетесь в ситуации, когда метрики вроде все зелёные, а финрезультат чего-то не бьёт ключом, а чаще ещё и убыток ловите. И тут сразу всплывает другой вопрос: кто виноват? Ответ — подход к целям. С лёгкостью фокусника, даже вспоминать долго не пришлось, достаю из ментального "загашника":

«Нам нужен дешёвый трафик» → лови дешёвый трафик, но либо нецелевых клиентов, либо с хреновым чеком.

«Нужна ниже стоимость привлечения» → дропаешь цену на товар и убиваешь маржинальность, зато конверсия растёт и стоимость падает. Либо ведёшь на самые дешёвые товары и показываешь номинально хороший результат. Разбираться всё равно не тебе, ты продал.

«Дайте больше лидов» (клэссик стори)→ маркетинг режет форму до одного телефона и нагоняет вагон заявок, план перевыполнен, а продажи потом неделю разгребают этот шлак, из которого в сделку не конвертится почти ничего, — и звучит справедливое «Лиды у вас дерьмовые».

«Нужен NPS повыше» → менеджеры начинают выпрашивать десятки («поставьте 10, пожалуйста, мне за это премия капает»), цифра ползёт вверх, а что у клиента в голове на самом деле — уже хрен поймёшь.

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

Свобода / несвобода фич в продукте Продукт свободен, когда все идеи-фичи имеют единую, последовательную и связанную логику ⇄ механику ⇄ архитектуру ⇄ CJM ⇄ JTBD, являясь частью Единого Целого настолько, что перестают быть отдельными элементами Системы. Из-за консистентной (наше новое любимое слово с ИИ) логики-механики-архитектуры, такие фичи внедряются с минимальным вложением усилий в эту самую логико-механику-архитектуру. Минимум разработки/багов, минимум новых неизвестных действий для пользователя, единые связанные метрики. Другими словами, каждая новая фича на 98% становится лишь новой фронтовой обёрткой вокруг-поверх-после механики и логики другой, создавая новые линии связей между ними, а не плодит новые "уникальные" фиче-сущности-объекты. Именно благодаря этому, они усиливают друг друга пропорционально, и каждая новая фича кратно увеличивает единственный набор метрик, не вынуждая продакта использовать ранние/запаздывающие/прокси и прочие показатели. И именно поэтому такие фичи работают с минимальными объяснениями – их суть давно понятна на примере прошлых, механика стала привычна, а логика всё неизменно подтверждает. Найти такую фичу просто – удали одну такую фичу из петли-цепочки, и рухнет добрая часть всего продукта.

Несвобода же определяет трение Так трение определяет несвободу

А несвободный продукт тот, в котором каждая новая фича требует новых переводов логики, механики, архитектуры из-за изменившегося (за их же счёт!!!) внимания и намерения пользователя. И это то, с чем мы, как продакты, каждый день с боремся, плодя фичи и онбординги-подсказки, гордо называя это адаптациями и прочими улучшениям конверсий и метрик, вместо того, чтобы иметь смелость признать, что все предыдущая фича была частью продукта, который не был Системой, и почти всё, что мы делали –  улучшали чинили наши прошлые ошибки неконсистентных фич.

Каждый раз на продуктовом обучении приходится давать определение гипотезы и объяснять, что это такое. Как думаете почему? 💡 Гипотеза - это предполагаемое объяснение уже наблюдаемого поведения пользователей или работы системы, которое еще предстоит доказать. Плохая гипотеза (просто хотелка): «Если мы поменяем логику подписок, пользователям станет удобнее». Хорошая гипотеза: «Мы видим, что 40% пользователей уходят со страницы оплаты (наблюдаемое поведение). Мы предполагаем, что они не понимают разницу в тарифах. Если мы добавим сравнительную таблицу, то снизим отток на 10%». Чтобы быстро отличить хорошую гипотезу от плохой, используйте формулу: Мы видим [Проблему/Данные] -> Предполагаем, что [Причина] -> Если мы [Решение] -> Изменение [метрики]

Сигнал/шум, ч.28. Про tokenmaxxing уже наверное все слышали - как использование токенов во многих компаниях стало важной метрикой, в том числе эффективности сотрудников. Невольно напрашивается сравнение с другой метрикой айти-компаний эпохи бума доткомов - eyeballs. По названию наверное понятно, что это просто посещаемость сайтов. 1️⃣ Тогда eyeballs вытеснили традиционные финансовые показатели, потому что денег многие не зарабатывали, но была надежда все позже круто монетизировать. Вместо например P/E считали стоимость за eyeball - сколько инвесторы платят за одного посетителя. Компании вроде Pets, Webvan, TheGlobe получали гигантские оценки при отсутствии пути к прибыльности. Метрику накручивали конечно, через рекламу, круговые схемы, гивы и др. Потребление токенов - такая же странная метрика: она конечно может отражать ценность, но очень сложно отделить этот сигнал от шума (бесплатные тиры, щедрые кредиты, агентские циклы и др.) А накручивать потребление токенов наверное даже проще. 2️⃣ Революцию AI сравнивают с революцией железных дорог, и самое забавное, что там тоже была стремная метрика 🙂 Это были мили: дороги нередко вели вникуда или компании просто дублировали маршруты конкурентов (что конечно не добавляло ценности конечному потребителю). Еще больше миль просто рисовали в отчетностях для инвесторов, как будущие золотые жилы. При этом токены ближе к милям, чем eyeballs, потому что совсем небесплатны. 3️⃣ Eyeballs и токены несут разный риск: первые надувались на стороне спроса - компания привлекала посетителя почти бесплатно, а риск нёс инвестор, купивший переоценку. Токены надуваются на стороне издержек: чем больше маккксинг, тем больше платит сама компания, а зарабатывает поставщик. То есть при доткомах пузырь дул тот, кто ищет капитал, а сегодня - кто его. При этом бенефициар — AI лабы, которых нет стимула менять ситуацию и оздоравливать бизнес покупателей токенов. 4️⃣ При этом токеномика AI продуктов устроена сегодня так, что по большому счету в мире не существует AI стартапов/бизнесов с хорошей юнит-экономикой. Есть прибыльные, но они почти всегда близки к схеме Agentforce от Salesforce: за них много платят, но почти не используют (пост-мем + пост по теме). И это не преувеличение: даже chatgpt, которым пользуется весь мир, - плохой продукт с точки зрения бизнеса (пост). 5️⃣ Полагаю, что в первой половине этого года мы прошли пик tokenmaxxing'а, после которого вышло много новостей о том, что крупные компании потратили годовой AI бюджет квартал или ввели лимиты на токены для сотрудников или убрали токен-лидерборды и токен-KPI. Если так, то хорошо, что это произошло так быстро! Возможно скоро мы увидим тренд "вот наш ROI от AI" 🙂 @kyrillic

Есть прикольный продуктовый метод - scream test (от англ. scream="крик"). Смысл простой: если непонятно, нужен ли кому-то сервис, продукт или фича, ты временно это отключаешь и смотришь, начнут ли пользователи жаловаться. Мне кажется, особенно хорошо это работает во внутренних продуктах. Там часто непонятно, пользуется ли кто-то дашбордом, отчётом или сервисом. Метрики никто особо не смотрит, обратной связи мало, и со временем начинаешь думать: «А это вообще кому-то нужно?» Иногда scream test происходит сам собой. Например, ломается доступ к дашборду и внезапно люди начинают писать: "А где график?", "Почему не открывается?", "Что теперь делать?". И ты такой: ага, значит, всё-таки было нужно, просто пользовались молча. После такого, честно говоря, появляется больше мотивации это поддерживать и развивать. Главное не тестировать так критичные вещи и иметь возможность быстро всё вернуть обратно. И помнить, что отсутствие жалоб не всегда значит отсутствие пользы: часть пользователей может просто смириться и ничего не написать. Но как быстрый способ понять ценность продукта работает отлично. Ну и если вы пользователь какого-то полезного внутреннего сервиса, и он вдруг перестал работать не миритесь с этим молча. Возможно, над вами проводят scream test. Не будете "кричать" 😱 его просто закроют.