Как понять, что агент умеет делать продукт? В первом посте про изобилие кода мы приняли рабочую гипотезу:

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

Как выяснить, какую часть этой работы уже можно отдавать агентам? Окей, мы с вами знаем, что писать код они могут. Но при этом всем нам очевидно, что создать продукт это не только про написать код. Собственно в эту тему прикольный новый бенчмарк/среда для оценки того, насколько агенты могут понимать проблему, взаимодействовать со стейкхолдерами, принимать продуктовые решения и тп. FDE-Gym - 95 задач на основе 20 сценариев внедрения AI. Агент получает запрос заказчика, существующий код, документы и историю работы системы. Можно задавать вопросы виртуальным сотрудникам, выяснять ограничения, менять и проверять систему. Запрос при этом может предлагать решение, которое не поможет достичь цели. Результат оценивают по изменению бизнес-метрики внутри симуляции, с учётом нарушений и стоимости общения с сотрудниками. Уточнить всё у всех тоже не бесплатная стратегия :) Если посмотреть, как frontier модели справляются с задачками из этого бенча, то более всего они лажают, когда ограничения приходилось выяснять самостоятельно, а не было задано заранее. Причем даже получение всех ключевых фактов не гарантировало хорошего результата. Очень жизненно имхо. Это, по моему мнению, еще и про насмотренность: знать, куда смотреть, кого спрашивать, и при этом не особо их раздражать :) Мы с дружбаном тоже попробовали один из общедоступных кейсов: ночного AI-дежурного, который должен уменьшить число ненужных пробуждений инженеров и ускорить устранение инцидентов. Получилось не очень, хотя я и не согласен с оценкой, но это уже другая история. Сама идея мне очень понравилась и, разумеется, отозвалась с моими постами про симуляции и Frontier Academy Из таких экспериментов имхо могла бы вырасти общая коллекция кейсов и разборов: какую работу получается делегировать, какая информация нужна агенту, где окупается участие человека? Разумеется, здесь мы пока измеряем пользу внутри сферического коня в вакууме симуляции; перенос в реальный мир ещё нужно проверять. Реальная компания - это гораздо более сложная (complex) и адаптивная система: она взаимодействует с клиентами и конкурентами, а люди учатся и меняют поведение в ответ на наши решения и действия друг друга. Внедрение продукта само меняет условия, в которых мы проверяем его пользу, и такие эффекты сложнее уложить в симуляции. Но тем не менее я считаю, что это уже лучше, чем ничего К примеру, я сейчас работаю над одной симуляцией - небольшой тизер тут в первом комментарии. Сыграли бы в такое?

Про бокс, пояса и 190 тысяч боёв в одной базе Люблю бокс. Когда смотришь хороший бой, хочется понять регалии соперников: кто чемпион и чего именно. С любителями просто: одна федерация, олимпийский цикл, медали. В профи четыре организации: WBA, WBC, IBF, WBO. У каждой свои пояса, «суперчемпионы», временные и регулярные титулы, свои рейтинги. В одном весе может быть пять-шесть чемпионов одновременно. Простого способа понять, кто из них сильнее, нет. Вся индустрия при этом живёт на одном сайте. Ему лет двадцать. Данные не всегда точные, на запросы лимиты, спросить что-то простым языком нельзя. Это проблема не только болельщика. Мой тренер Тимур Ибрагимов (писал о нём здесь) часто ищет бои для своих боксёров. Нужен соперник в том же весе, с сопоставимым и не дутым рекордом, свободный в нужную дату. Без нормальной базы это звонки, переписки и всё тот же старый сайт, на котором нельзя сделать много запросов. Подобрать бой реально сложно. Недавно писал о найме Databricks-инженеров, и на собеседованиях в который раз восхитился тем, как искусно люди строят дата-пайплайны. Захотелось проверить себя и новые Fable и Astra: сколько из этого соберут агенты. Взял только открытые источники, без закрытых каталогов и копирования чужих баз. Сначала за выходные, потом в фоновых сессиях Claude и Codex написали десятки парсеров. Они читают Википедию на нескольких языках, протоколы атлетических комиссий Невады, Техаса и Калифорнии, результаты WBA, IBF и Британского совета по боксу, японские карты боёв. Код агенты писали сами, но под присмотром. Сергей Булаев, с подачи которого я когда-то пересел на Claude Code, помогал техническими советами: SEO, видимость в AI-поиске, базовая оптимизация сайта. Что из собранного важно людям из бокса, а что нет, объяснял Тимур. После каждого разговора с ним список того, что надо собирать, менялся. Так получился boxerbook.com: • около 190 тысяч боёв с 1880-х, у каждого видно, откуда данные и насколько они подтверждены • больше 13 тысяч боёв подтверждены официальными протоколами комиссий • собственный рейтинг, где у каждой цифры есть объяснение: почему боксёр стоит здесь, а не выше • титулы и пояса всех организаций в одном месте • календарь и результаты боёв - обновляются сами каждое утро • любительские карьеры и медали • больше 5 тысяч боксёрских залов Скоро добавлю агентов для болельщиков и промоутеров: можно будет спросить кто сильнее, когда следующий бой, почему у него такой рейтинг и получить ответ со ссылками на источники. Аналитики пишут, что главная защита приложения от конкурентов - данные, которые сложно собрать и поддерживать в актуальном состоянии. Так ли это сложно, когда есть современные инструменты? В каждой нише есть сайт или приложение двадцатилетней давности, на котором держится вся индустрия. Его терпят, потому что альтернативы нет. Чтобы повторить такую базу, нужно было годами собирать данные руками. Если исходники лежат в открытых протоколах и архивах, эту работу можно отдать агентам в фоновых сессиях. Сложнее всего было понять, какие вопросы вообще важны. Некоторые из них не задали бы ни Claude, ни Codex, ни я. Их принёс человек, у которого за плечами больше двухсот боёв. Посмотрите и напишите, чего не хватает: boxerbook.com @maxvotek | linkedin | substack

По мере ускорения развития ИИ в командах, которые занимаются продуктом, разработкой и дизайном, останутся только две роли. 1. «Слоп‑генератор» Чел, который умеет вайбкодить и экспериментировать с невероятной скоростью. Самостоятельно проверяет множество смелых гипотез и находит среди них что-то ценное. Пусть срабатывает лишь одна идея из ста - это норм, если за неделю ты успеваешь проверить десять идей. В стартапах и при запуске новых направлений такие люди станут особенно ценными. 2. «Повзрослевшие» Они берут идеи и первые признаки успеха, которые обнаружили «слоп‑генераторы», и превращают их в качественный продукт. Продумывают архитектуру и безопасность, выстраивают рост и следят, чтобы продукт помогал достигать бизнес-целей. Их задача - превратить перспективную находку в масштабируемый успех. При этом доля успешных запусков у них - 50% и выше. Стратег и сильный межфункциональный специалист. Глубоко понимает продукт, бизнес, пользователей, конкурентов и устройство рынка. Умеет работать со всеми командами — от разработки и финансов до продаж и поддержки. Мастерски находит общий язык с людьми и добивается согласия. Хорошо принимает стратегические решения, в том числе о распределении бюджета и ресурсов, и понимает, как растить бизнес. Если ты работаешь в продуктовой, инженерной или дизайн-команде, развивайся в одном из двух направлений: стань лучшей «слоп‑пушкой» или одним из тех, кто превращает удачные находки в сильные продукты. Быть просто средним специалистом в узкой области и рассчитывать на отличную карьеру уже не получится.

Как вести журнал ошибочных решений в команде: от простого к сложному Цель журнала в том, чтобы фиксировать и показывать паттерны ваших ошибок на всём протяжении изменяющейся жизни а) продукта; б) команды и устранять именно их (паттерны-причины), которые создают следствия (ошибки). – Тегируйте каждую запись по типу ошибки: неверные изначальные данные, неправильная оценка, спешка, избегание конфликта, и т.п. причины. Анализируйте ошибки, ищите повторы, устраняйте причины ошибок, чтобы не лечить следствие ошибок каждый раз. Разделяйте плохое решение и плохой исход Четыре разных типа задач: хорошее решение и хороший исход / хорошее и плохой исход / плохое решение, но хороший исход / плохое решение и плохой исход. Самый недооценённый тип: «плохое решение / хороший исход», при правильном заполнении и поиске тех самых причин, в таких идеях спрятан ключ как вам прийти к самым успешным решениям. Пишите «пре-мортемЫ» заранее, а потом сравнивайте с настоящей причиной. Помогает подложить ту самую соломку где надо, знаю команду, в которой есть чел с отдельной ролью именно под это.

«Мы ожидаем изменение метрики на X%, уверенность в этом 70%». Это два разных ощущения, понимание их помогает калибровать общее ощущение вашей реальности

– Обогащайте пост-контекст принятого ранее ошибочного решения отдельным полем «Что мы проигнорировали / не заметили / поняли не так» + состояние, в котором принимаете решения: стресс, дедлайн, кто был в комнате, какой информации не хватало. Фиксируйте, какие данные вы не стали собирать и почему Потому что уже через полгода каждая ошибка вспоминается как очевидная, а состояние и условия в которых она возникла забываются. Так, спустя время, ошибку можно легко приписать глупости, хотя причина в была условиях (ошибка после ошибки – точно глупость).

Записывайте, какую историю вы рассказали о решении с ошибкой (совет на будущее из прошлого: старайтесь избегать одной яркой истории)

– Самое полезное поле: «первые звоночки или первый момент, когда мы заметили/могли заметить ошибку». Ловите самые ранние сигналы ошибок. И эти сигналы могут приходить ощущениями ещё на стадии планирования (и даже раньше). – Второе по полезности поле: «что мы защищали»: утверждённый ранее родмэп, упрямство, личное авторство, бюджет, обещание СЕО/инвесторам, красивую историю-презу. Ошибки держится на подобном, пойми на чём именно. – Добавьте поле «Чья это была ошибка: человек / процесс / Система». Люди – без имён, это не поиск виноватых! Видя как ошибка живет на каждом из этапов, вы сможете лучше видеть слабые и сильные места в командных и продуктовых процессах и понимать, как на них влиять. Ещё одно недооцененное поле «Кто возражал и чем закончилось» для фиксации возражений которые вы систематически игнорите и недослушиваете (почему?). Часто, те кто возражают это: 1) люди с низким статусом в команде; 2) те, кто говорит осторожно; 3) тот, кто говорит самую больную правду и именно они часто оказываются правы. Ещё раз – без имён! – История побочных эффектов ошибок – то, что решение сломало в соседних фичах/механиках/процессах/метриках. Помогает видеть и лучше понимать связи внутри продукта. – Ведите журнал и по ошибкам конкурентов, это а) чужие; б) бесплатные уроки, и они могут делают вас лучше, чем собственные провалы, потому что в них нет эго, которое защищается. – Статус: «ошибка признана / решение пересмотрено / отменено» превращает журнал из архива в рабочий инструмент. Раз в год перечитывайте журнал и ищи решение, которое тогда казалось ошибкой, а теперь нет (или наоборот). Время переворачивает оценки чаще, чем кажется и является лучшим лекарством от уверенности в собственных суждениях (о времени). Будьте абсолютно честны, только так этот журнал будет работать. Честность в том, чтобы записывать даже те ошибки, которые страшно/некомфортно признавать. Свежий взгляд в журнал продукт возвращает честность. Spend ten minutes every day deliberately writing down what you got wrong. Not journaling about ego gratitude lists, but a f***ing. daily. error. log.

ИИ научился собирать дашборды за вечер. Почему они не стали полезнее? Еще несколько лет назад подготовка нового дашборда для команды могла занимать месяцы: исследование аналитиков, интервью стейкхолдеров, выбор метрик, а затем кропотливая верстка и проверка в несколько итераций. Сегодня черновик дашборда ИИ собирает за вечер. И выяснилось неприятное: свободные руки разработчиков никогда не были главным ограничением. Мы проанализировали фреймворк Dashboard Canvas, о котором несколько лет назад рассказывал Роман Бунин читателям нашего блога (сама статья — здесь). И поделимся тем, что за это время изменилось вместе с внедрением ИИ в работу. Самый трудный блок в фреймворке Dashboard Canvas — вопросы и бизнес-решения. Заказчик говорит «хочу следить за метриками», и эту фразу нужно превратить в правило действия: — если retention проседает, запускаем рассылку по конкретным сегментам; — если менеджер не выполняет план, руководитель открывает его сделки и ищет те, которые поможет закрыть. Пока у метрики нет порога и следующего шага, на экране просто красивая картинка. ИИ может предложить варианты действий, но не определит за команду, какие решения она действительно готова принимать и на каких условиях. Второе, что подорожало, — данные. Модель уверенно напишет запрос к таблице, где сделки дублируются, а план лежит в экселе с другими написаниями фамилий менеджеров. График будет аккуратным и неверным, сама аккуратность только добавит доверия к ошибке. Поэтому недостаточно правильно поставить задачу модели. Нужно проверить источники, логику расчета и итоговые цифры. ИИ ускоряет работу с данными, но не отменяет ответственность за их качество. Подробнее об этом и том, как повысить качество ответов ИИ, мы говорили в недавнем подкасте. Третье — контекст. Кто откроет дашборд, когда, на каком экране и что сделает дальше. Нужна ли мобильная версия, как часто обновлять данные, нужно ли обновление в реальном времени — все решается вопросом: что я сделаю, если увижу это прямо сейчас? Если ответ «расстроюсь», эта опция не нужна, как бы легко это теперь ни было собрать. Что действительно изменилось к лучшему — цена итерации. Раньше ошибку в требованиях находили после недель разработки. Теперь за вечер можно показать заказчику три черновика и сразу после изучения макета услышать: «я смотрю это на стендапе с ноутбука, мне нужна одна цифра сверху». Скорость в доработке прототипа позволяет быстрее собирать обратную связь на кастдевах и итеративно улучшать его. Обратная сторона дешевизны — дашборды плодятся. Когда новый отчет стоит час, их появляется сорок, и ни один не отвечает на вопрос, ради которого его делали. Обычно делают два типа отчетов: обзорный отвечает на вопрос «как у нас дела в целом?», аналитический — «почему именно так?». Разделять отчеты и иметь возможность перейти из одного в другой по клику должно стать базовым правилом работы с ними. Если коротко: ИИ ускорил создание дашбордов и проверку гипотез о том, как они должны выглядеть. Но не снял с команды ответственность за главное: понять, какие решения должен поддерживать отчет и можно ли доверять данным. Именно в этих шагах остаются самые ценные инсайты. Хорошая новость в том, что на них наконец-то появилось больше времени и когнитивных ресурсов. Подробно про Dashboard Canvas, список вопросов к заказчику, принципы верстки и архитектуру отчетов — в статье. Читать статью ➡️ @productmindset

🧩 От слов к виджетам Сегодня UI обычно подстраивается под задачу: отдельный экран для покупки, карты, настройки или аналитика. Но с генеративными моделями появляется другой сценарий — интерфейс сам собирается под человека и конкретную задачу, в зависимости от рекомендаций и предпочтений пользователя. На AI RnD Day Ира Пионтковская рассказала, как может выглядеть такой подход и какие технические проблемы возникают на практике. 📌 TLDR LLM пишет код, браузер превращает его в интерфейс. Но кто проверит, что кнопки работают, график не врёт, а виджет отвечает на исходный запрос? Generative UI — это не просто "LLM рисует HTML". Модель должна сгенерировать работающий интерфейс, пользователь — взаимодействовать с ним, а система — понять, действительно ли UI решает задачу с приемлемым качеством. 💥 Красиво ≠ правильно У интерфейса как минимум три слоя проверки: внешний вид, поведение и смысл. Текст может читаться, кнопки — нажиматься, а задача всё равно останется нерешённой. Например, график расходов аккуратно сортирует дни недели по алфавиту. Визуально всё хорошо, а хронология потеряна. 🎙 Почему UI становится частью диалога В классическом интерфейсе пользователь говорит: "покажи шкафы глубиной до 40 см", а приложение показывает экран с результатами. В GenUI модель может создать сам интерфейс под текущую задачу: показать варианты, дать выбрать один, открыть план комнаты и позволить перетащить шкаф. Получается, что виджет становится частью реплики модели — примерно как жест или указание в разговоре. Это особенно интересно вместе с full-duplex voice: пользователь может сказать «этот сюда», модель — показать объект и место на экране, а пользователь — сразу изменить его положение. 🧠 Главная проблема — как проверить UI Сгенерированный HTML может выглядеть красиво, но при этом содержать смысловую или функциональную ошибку. Поэтому мы исследуем VLM-as-a-judge, которая получает запрос, код и скриншоты двух виджетов и должна определить, какой лучше решает задачу. На примере бенчмарка дефектов: берём корректный график и намеренно добавляем один дефект — обрезанный текст, наложение элементов, пропавший объект, подпись не по теме или противоречие с данными. Основной разброс появляется на задачах, где нужно обнаружить ошибку, а не просто прочитать изображение. Например, на обнаружении обрезанного текста Gemini 2.5 Pro дал 100% правильных ответов, GPT-5 — 92%, а Grok 4.20 — 31%. 🛠 Можно ли обучить самого судью? Да. Мы собрали пары из хороших и намеренно испорченных виджетов: перекрытия, блюр, зависания, подмена темы и другие дефекты. Затем дообучили Qwen3.6-35B-A3B. На тесте после DPO точность на повреждённых виджетах выросла с 66% до 100%, а среднее время ответа сократилось примерно с 820 до 25 секунд. 🤖 Следующий уровень — GUI-агент Визуальной проверки недостаточно. Интерфейс может выглядеть правильно, но кнопка не работать. Поэтому следующий шаг — дать GUI-агенту реальный сценарий: "Добавь дубовый шкаф в список покупок". Агент сам кликает по интерфейсу, выбирает нужный объект и проверяет состояние приложения. Если ожидаемый результат не достигнут, траекторию действий и ошибку можно вернуть генератору для исправления. Так появляется полноценный цикл: LLM генерирует UI → GUI-агент взаимодействует → проверяется состояние → ошибка возвращается генератору. 🔚 Выводы Generative UI — это следующий шаг после обычного chatbot-интерфейса: модель может не только отвечать, но и собирать форму взаимодействия под конкретную задачу. Но чтобы это работало в проде, одного сильного генератора недостаточно. Нужны проверяемые среды, модели-судьи и агенты, способные взаимодействовать с интерфейсом. В конечном счёте хочется прийти к системе, где каждой задаче — свой интерфейс, а его качество проверяется автоматически. А после доклада был задан очень хороший вопрос о недалеком будущем: "Будем ли мы жить в одном едином окне, в котором отражена вся наша жизнь?". Кажется, что все к этому идет! 🔗 Более подробно — в презентации Ирины (оставим в комментариях файлом) и в записи выступления (тайминг: 5:04:40). #genui #paperwatch #conference

Мои клиенты надругались над платформой за 24 млн.руб. и после этого я не боюсь ИИ  🤖 В 2017 году я работала в крутом маркетинговом агентстве с головным офисом в Лондоне и там разрабатывали ультрамодную платформу, чтобы собрать в одном месте инфо по клиентам из разных стран.  Нужно было, чтобы клиенты заполнили свои данные.  У нас был один “специфичный” клиент 😁 – платформа была на английском языке и мы решили помочь с переводом. Мы сделали СКРИН экрана с формой, подписали перевод, упаковали в PDF (чтоб уж точно заполнил платформу, а не вложение) и отправили с четкой инструкцией.  Что же сделал этот клиент?  Вместо того, чтобы заполнить платформу, он РАСПЕЧАТАЛ скрин экрана, вписал свои данные обычной шариковой ручкой, отсканировал и прислал мне 😡 А вы говорите ИИ! Иногда прогресс бессилен перед людской упертостью!   Пока сотрудники Antropic массово увольняются и говорят об уничтожении человечества - я сплю спокойно, потому что пока есть такие клиенты - апокалипсис нам не грозит А у вас было что-то подобное на практике?)

Коллеги, ситуация 🤌 сейчас одна компания делает редизайн интернет-магазина. В феврале он должен выйти. Дата поставки стоит в феврале. Что произойдёт в феврале? Ничего. Ничего не будет. Вот где происходит подмена понятий 👀 Есть бурная деятельность. Таски, тудушки. Есть результат работы: лендинг, текст, процесс продажи, презентация, дизайн, релиз, Google-табличка. И мы очень часто говорим: раз сделали результат какой-то работы, значит он сработает. Самое страшное, что если упороться, то можно выпустить. С багами, с легаси, со взрывным кодом. А у людей уже есть план. И они будут его придерживаться. Но вопрос другой: что в итоге? Что изменится в итоге? Чтобы изменились метрики, должно измениться поведение пользователей. Чтобы изменилось поведение пользователей, надо что-то в процессах работы поменять. Метрики отражают поведение пользователя. Возьмите сейчас любую свою задачу и спросите: что изменится в итоге? 🎯 P.S. Как говорится, «Где деньги, Лебовски?»

Ща делаю лендинг для нового продукта и уже, честно говоря устал. Я пилю его с gpt неделю, придумываю всякие приколюхи, не хочется йет эназе джипити лендинг пейдж. Нейроночка иногда устаёт и ловит какой-то луп тупняка, я бешусь. Но потом все-таки доделываю, оттачивая промпты до состояния маленьких prd. Сегодня понял, что всё нахрен, не могу, хочу прокатиться на велике, подышать воздухом и любись оно конём. Пишу — ну сделай там как-нибудь бэст практис туды-сюды, чтоб зашибись было, красивенько и понятно. И он такой хренак и сделал. И как бы норм! Оно становится умнее нас, и если раньше надо было соревноваться в мастерстве продуманных до мелочей промптов, то теперь достаточно просто предложить сделать по красоте. НО! На радость кожаных, в отбитый креатив оно пока не умеет, а я там такого навертел, ну прям квест с пасхалками. Даже если вы у меня ничего не купите (ЪУЪ!), то в атмосферу точно погрузит. Toggl говорит, что за 2 недели на лендинг ушло 23 часа, почти полные сутки! Казалось бы — вот тебе нейронка, вот ахулиард лет опыта в продукте, но когда начинаешь делать то, что считаешь важным, неизбежно получается долго. Десятки итераций визуала, развилок, текста... Но я тут твёрдо решил, что не остановлюсь, пока сам себе не скажу, что вот теперь кайф. Итого: у меня получается очень странная штука, которая получит либо вау-отклик, либо сверчков. И вот это самое страшное. Я вообще это писал в лайф-канал, но рука дрогнула. Выкатить бы мне анонс уже позавчера, но если честно, просто ссу. Готово уже почти всё. Надавите на меня реакциями что ли, они бесплатные!! Вот чтобы я вернулся через часик домой, а тут нихрена себе Антошка с наступающим ДР, сотня лайков, типа мы с тобой.

Быстро закрыть продукт - тоже киллер-фича Вот ещё один интересный подход к продуктовым инновациям: У Сбера появилось направление DISRUPT (какой ещё вам нужен пруф, что все продакты меня читают? 🤔). Если кратко, то это такой внутренний венчурный инкубатор для ИИ-сервисов, что-то вроде Google Labs или Copilot Labs у Microsoft. И у него есть две необычных особенности: - Первая - команда тестит гипотезы сразу на живых внешних юзерах. - Про вторую детально ниже, а сначала несколько примеров продуктов, которые из него уже успели выйти: 1. Мультитул. Это десктопный агент для любых рабочих задачек - типа сборки през и отчётов на основе документов, с подтягиванием контекста из почт, календарей и т.д. Из необычного - туда можно подключить свою нейросеть (не только что уже есть под капотом, а вообще любую). 2. Тайп. Локальный голосовой набор для Windows и macOS. Под капотом модель GigaAM, заточенная под распознавание русской речи, процессинг локально на устройстве. 3. Консьерж. Ищет рестораны, отели и маршруты, ставит события в календарь и может позвонить куда надо. Живёт в мессенджерах. 3. Айва. Ассистент по здоровью, анализирующий КБЖУ по фото блюд, составляющий программу тренировок и подсказывающий, к какому врачу записаться. Но весь прикол даже не в сервисах, а в общем правиле, по которому они живут (та самая вторая особенность). Тут конкретный фокус на ретеншене. Успешным считается только тот продукт, к которому пользователи стабильно возвращаются. Если нет - его быстро закрывают и берут следующую гипотезу. И это довольно необычно, ведь в корпорациях инновации часто загибаются, потому что нет системы, чтобы быстро распознать провал и отстрелить его. В итоге, продукт запускают - он обрастает командой, метриками и всем остальным - и легко может получится "зомби", высасывающий бюджеты и усилия годами. А тут, получается, быстрое закрытие продукта - это часть самой фабрики. А тестирование сразу на внешних юзерах (в том числе - юзерах сервисов Сбера) явно ускоряет решение и повышает его достоверность. А то если тестировать на сотрудниках (как часто делают), то это... ну такое. Сотрудники любят сильно отклоняются от среднего по юзер-больнице или вообще влюбляться в свой продукт по уши. Я недавно писал про GigaChat 3.5 Ultra и Reasoning, где Сбер отдал обе модели в опенсорс под лицензию MIT. И там делал отдельный акцент, что ценность всей этой истории будет зависеть от того, что строится вокруг самих моделей. Так вот, думаю, этот DISRUPT - и есть попытка поскорее построить это "вокруг". Только не одним большим запуском (который, если провалится, то сразу и весь), а десятками небольших ставок с дефолтным правом на быстрый провал. Дизраптор

Самый смешно запоротый A/B в моей практике Как-то раз в A/B тесте нашей модельки с альтернативным решением, заказчику (онлайн-магазину) понадобилось рассказать, зачем нужно брать хэши от айдишников пользователей перед делением на группы, потому что заказчик хотел просто брать четные айдишники в одну группу, а нечетные в другую. Рассказали, что не все вещи, кажущиеся равномерным распределением, правда им являются. Рассказали про то как многие смело разбивают клиентов на группы по последней цифре телефона и потом внезапно узнают, что группы перекошенные. И даже рассказали, что не все хэши одинаково хорошо перемешивают группы и какие предлагаем использовать. Дальше первую неделю A/B видим как стабильно ведем в тесте, радуемся, готовимся праздновать, но на очередном созвоне с заказчиком мимолетом ловим очень тревожную фразу. СТО заказчика решил поделиться своим ноу-хау:«хэш же нам нужен, чтобы результат был максимально непредсказуемым, так что я сделал не hash(id), а hash(id+email), чтобы еще лучше перемешивало группы» 🗿 Осторожно интересуюсь: а когда человек не залогинен, как это работает? СТО: тогда e-mail - пустая строка. Я: а сразу после логина? СТО: сразу после видим e-mail и уже не пустая. В общем, при логине с вероятностью 50% группа менялась, а логин был обязателен для оформления покупки… Кстати, времени у заказчика на еще один правильный А/В не было, так что как вы думаете, что было дальше, и чем закончился проект? :)

Ты не владелец продукта, ты владелец тасок в статусе «в работе». Так как Система не создана для перемен. Смысл: не трогать то, что приносит деньги. Те, кто платят деньги, будет принимать решения за них. Ты будешь продавать свои идеи тем, кто за них платит деньги, чтобы убедить их в том, что твой успех будет их. Ты будешь отвечать за свой "успех" лишь только в случае провала. Фреймворк приоритезации один – фичи и идеи сверху. Ты выберешь востребованные зелёным цветом метрики под такие фичи. И снова создадите фичи под зелёный свет. Все остальные инициативы будут требовать дополнительной валидации, исследования рынка, анализа потребностей аудитории, ок юристов, соответствия культуре. Ещё одной дополнительной валидации. И ещё одной... И т.д., пока ты не поймешь. Реализация будет определяться тем(и), кто подберёт востребованные в нужный момент времени слова. Ты выучишь нативный язык свой корпы. Тебя будут ценить когда ты скажешь «да» вместо «нет». Ты будешь жаждать ещё больше встреч вверху. Ты будешь тратить больше сил на конкуренцию за «да», а не на рынке. Любимый юзерами продукт/фичу вырежут одним письмом. Однажды ты поймёшь, что уже не помнишь, зачем твой продукт нужен людям. И вот ты потерял Огонь. Все знают об этом. Все молчат.

«Я не ЦА своего продукта» Это самая тупая фраза, которую можно услышать от продакта. Туда же идет фраза «я нерепрезентативен» и петросянская шутка «дилер не употребляет собственный товар». Если ты каждый день не пользуешься своим продуктом, то не чувствуешь боль своих пользователей. Не страдаешь от того, что при сворачивании приложения сбрасываются значения полей. Не бесишься, когда приложение зависает в самый ответственный момент. Ты сидишь в своем теплом офисе и не чувствуешь страдания курьера, который под дождем пытается что-то сделать в твоем поделии. Когда разговариваю с продактами, спрашиваю пользуются ли они своим продуктом. Если говорят, что не пользуются или еще хуже - пользуются в основном конкурентами - перед тобой пропащий человек. Поэтому приложение для аренды бизнес джетов должен делать продакт-богач с золотыми зубами.

Что ИИ ломает в продуктовой команде и почему старые роли больше не работают Спикер: Андрей Южаков Раньше работа двигалась по цепочке: аналитика → дизайн → разработка → тестирование. Каждый передавал дальше контекст в виде артефакта. С агентами всю цепочку может пройти один человек. С приходом ИИ меняется сама единица работы: вместо отдельного артефакта ей становится клиентское изменение целиком, которое один человек ведет end-to-end, подключая экспертов там, где это необходимо. На примере банковского продукта мы проверили новую модель на большом сценарии в интернет-банке. С помощью агентов удалось самостоятельно подготовить требования, API, UX, архитектуру, бэкенд, фронтенд, gateway и тесты. Первая версия появилась примерно за неделю. Но дальше начали ломаться привычные процессы. Первая поломка: автор изменения больше не обязательно владелец результата. Границы ролей размываются. Менеджер продуктов может написать код, разработчик — придумать и реализовать фичу, дизайнер — самостоятельно внести изменение в продукт. Но возможность что-то сделать ≠ ответственность за качество результата. Например, раньше дизайнер готовил интерфейс, а затем ждал приоритизации и разработки. Теперь он может получить доступ к агенту и репозиторию и самостоятельно внести изменение. Но ответственность за UX остается на дизайнере, а за техническую надежность — на инженере. Поэтому важно определить, кто отвечает за бизнес-результат, клиентский опыт, техническое качество и стандарты — и кто в итоге может сказать: «это можно выпускать в продакшн». Вторая поломка: генерировать мы научились быстрее, чем проверять. Первую версию фичи удалось сделать за неделю, но до продакшна она дошла только через два месяца. Выяснилось, что существует множество стандартов и требований, которые нигде нормально не описаны. Узкое место сместилось с создания решения на проверку его качества: после перехода на новый процесс с агентами до 78% времени стало уходить на code review. Но и это еще не все. Отдельные части решения могли успешно пройти тесты, а после сборки на тестовом контуре начинали ломаться интеграции. Поэтому пришлось пересматривать интеграционные тесты и способы получения обратной связи. Третья поломка: привычные профессиональные роли перестают совпадать с тем, что реально делает человек. Раньше было понятно: frontend-разработчик отвечает за свой участок, backend-разработчик — за свой, аналитик, тестировщик и дизайнер — за свои. Но что происходит, когда с агентом можно сделать работу соседней роли или вообще пройти всю цепочку самостоятельно? В примере банковского продукта мы перешли к модели, в которой один человек ведет изменение end-to-end: от постановки задачи до реализации и проверки качества. Так появилась более широкая роль product engineer — человека, который лидирует клиентское изменение целиком, а не только свой технический кусочек. Такая перестройка вызывает вопросы: «Почему я должен писать тесты?», «Почему должен вести документацию?», «Я буду делать чужую работу хуже». Поэтому просто дать команде агентов недостаточно. Нужно заново ответить на вопрос: за что мы ценим человека в продуктовой команде? Сейчас по новой модели в банковском продукте работают уже восемь команд, а через новый процесс в продакшн провели больше 200 изменений. То, что раньше могло занимать около полугода работы команды, в эксперименте удалось довести до продакшена примерно за два календарных месяца. Агенты могут написать код, сделать дизайн, подготовить требования или тесты. Но они не определят за нас, что такое хороший код, хороший клиентский опыт или надежный продукт. Критерии качества, стандарты и ответственность остаются на людях. Поэтому при перестройке команды важно определить: — кто отвечает за результат для клиента; — кто отвечает за надежность и качество; — кто принимает решение о выпуске; — кто ведет изменение целиком. И еще одно правило: если после ошибки не появилось новое правило, тест или стандарт — скорее всего, мы просто заплатили за эту ошибку и ничему не научились. @productsense

Тестирую новую Image модель от OpenAI. Они и раньше были крутыми. Не чувствую сильно уже разницы между ними. Но меня поражает вот что. Один парень заработал 65 млн рублей на сервисе генерации картинок для маркетплейсов. Lovarus и его аналоги зарабатывают сильно меньше. При этом технологически более сложны. У нас и интеграции, и сервера, и данные, и прочее. А там сделал картинку и все. Не нужно ничего дополнительно обслуживать. Это я к чему? Иногда мы строим «космолет», думая, что деньги там, где сложно, где рокет-сайнс. Лично у меня есть такая установка - большие деньги зарабатываются только тяжелым трудом, переработками, сложными решениями. Но современный мир, показывает, что это не всегда так. Есть у вас кейсы, которые это подтверждают?

Сперва продали, а только через 4 месяца сделали. Мою личку в тг бывает прилетают спам-предложения сделать мне превью для ютуба. Приходит по 2-5 предложения в месяц. Хотя канал у меня маленький. Сам я прикола в этих превью не понимаю. Хотя согласен, что они могут сильнее конвертить в просмотры, при правильном подходе. Логичная мысль, если так много предложений, значит и спрос есть. Да и сервисов, которые такое делают, их просто тьма уже. Но решил потестить. Сделали доп лэндос на наш основной домен. Мол с описанием, что умеем такое делать. Хотя делать нифига не умеет, все кнопки вели на основной функционал. И прикол, спустя месяц, это стала нашей одной из самых популярных страниц по кликам. Ну раз так, то окей, можно сделать. Сделали быстро. Пошли доп оплаты. Теперь только так и проверяем. Сперва лэндос, собираем клики. Если кликают или хотят забрать результат, то делаем. А ведь могли сперва сделать, а только потом пойти тестить спрос. Логично же? Кстати, мы так еще 5 фиче проверили. Которые в итоге тупо дропнули. И делать не пришлось. То есть сэкономили ресурсы 3 человек 5 раз длиной 1-2 месяца работы.

Мультиагентные команды вместо «одного чатбота» PM больше не «пользуется ИИ», а собирает команду агентов — Chief of Staff, PM-агент и десятки workers в циклах (loop/graph) с верификацией (Grok bot, hermes, openclaw 2.0) Суть: один агент — это ~1% потенциала; ценность появляется, когда агенты декомпозируют работу, передают её друг другу и поднимают человеку только решения. С чего начать: 1. проектировать систему (роли, handoff, verification, где человек утверждает), а не «лучший промпт» 2. Держать продукт-знания в Markdown/Git, а не в JSON/Confluence-простынях 3. Отдельная аналитика: bypass rate, качество ответа, доверие, не только «использовали фичу»

Как научиться предсказывать что угодно? 🔮 На видео спикер рассказывает, что его команда научилась за три дня до расставания предсказывать, что девушка бросит парня. Когда я впервые увидел это в трансляции, то понял только часть проблемы: спикер вообще не шарит, а команда решает странные задачи и пилит такие же фичи 😅 Тогда моего руководительского опыта не хватило, чтобы задуматься о процессах внутри компании — меня просто поразил уровень абсурда. Причём настолько, что эта история догнала меня даже спустя семь лет. Но сейчас, когда я строю собственную компанию, меня гораздо больше беспокоит другой вопрос: какие процессы внутри компании привели к тому, что топ-менеджмент рассказывает об этом на конференции как об успешном кейсе? 🤔 Начнём с самого кейса. Пока я не пересмотрел видео, у меня были разные гипотезы о том, как они собрали целевую переменную: — может быть, провели опрос? — спарсили социальные сети? — а как тогда собрали хард-негативные сэмплы? Но нет. Судя по видео, аналитики придумали сегмент на основе набора косвенных признаков. С какой точностью этот сегмент отражал реальность? Правильно: никто не знает 🙃 Дальше, вероятно, построили модель, которая научилась предсказывать эту синтетическую целевую переменную. И здесь появляется ещё один уровень неопределённости. Сначала мы с неизвестной точностью восстанавливаем целевую переменную по косвенным признакам. Затем с некоторой точностью обучаем модель предсказывать уже эту восстановленную переменную. То есть модель предсказывает не само расставание, а предположение аналитиков о расставании. На ошибку при создании таргета накладывается ошибка самой модели. Поэтому итоговое качество относительно реального события становится ещё менее понятным 🎯 Следующий вопрос: как проверяли лики? Не протекли ли в модель те же признаки, на основе которых изначально восстановили целевую переменную? 🫠 Ну и самое интересное: как измерили эффект? Никак. Модель встроили в рекомендательную систему, в которой, судя по рассказу, нет прозрачно рассчитанного финансового эффекта 💸 Итак, рецепт, как научиться предсказывать что угодно: 1. Конструируете целевую переменную с неизвестной точностью. 2. Обучаете модель предсказывать этот синтетический таргет. 3. Получаете два слоя ошибки: в разметке и в самой модели. 4. Встраиваете модель в продукт, где невозможно оценить её эффект в деньгах. 5. Рассказываете об успешном кейсе на конференции. 6. Готово — вы великолепны! 🚀 Всё это звучит смешно ровно до того момента, пока вам самим не приходится собирать такие фантастические сегменты и обучать на них модели. Напишите в комментариях, если знаете достоверный источник данных для такого сегмента. Особенно интересно, где взять качественные хард-негативные сэмплы 👇

Созвон с клиентами В самом начале проекта (первые месяцы) меня не подводит тактика - сразу после ввода карточки писать письма клиентам с предложением созвончика. Часто оказывается, что клиент богаче, чем ты думаешь, у него команда больше чем ты думаешь и ситов покупают больше, чем ты расчитывал. Также ни один Fable не продумает норм онбордит, или не предвидит баги, поэтому косяки всегда видны при скриншаре реального пользования. У меня например с англичанами веселый кейс - аккаунт сетапит Personal Assistant босса компании и она под своим и его акком на своем аймаке сидит, поэтому при клике на инвайт самой себе, инвайт открылся в браузере, где аккаунт босса залогинен и там был баг, что вместо ее имени имя босса система записала в кукисах. Также я сразу в борду в Excalidraw прям на колле их скриншоты закидываю и пишу че хотят и говорят "will me done by tomorrow morning", хотя знаю что будет уже через пару часов. Самый угар, она реально думает, что я - киприот. У нее даже мысли нет, что я из СССР 😂 Если так вести дела - это скопится, у продукта будет goodwill, использовать будут годами платить, и еще и мыслить, что там за пультом норм чел сидит, а не бездушный Клод. Короче - общайтесь с клиентами, не ссыте созвониться. Наблюдения - если просят фичу, спрашивайте зачем им (надо понять причину) - также уточняйте в каких ситуациях команда юзает ту или иную кнопку (понять внутренний воркфлоу) Это дает мега конспект как максимально пиздато сделать дизайн/фичу