Технология, продукт и компания это разные вещи, хотя я не сразу это поняла. У нас долго был некрасивый фронтенд, и меня это совершенно не беспокоило, потому что за ним была вся сложная часть: CRM, инструменты аутрича, AI-сервисы и куча процессов, которые сначала нужно было просто заставить работать. Я была одержима именно этим, и на интерфейс сил почти не оставалось. Технология работала, продуктом это стало уже позже. Сейчас мы упёрлись в следующий уровень, и он оказался тяжелее обоих предыдущих, потому что здесь уже почти не про код и не про интерфейс. Клиент должен получать обещанное сегодня, а не «в среднем за квартал». Клиентов становится не три, а двадцать пять, и старые способы держать всё под контролем просто перестают работать. Качество не должно зависеть от одного конкретного человека, значит нужны процессы. А ещё нужны плейбуки под конкретных людей и ситуации, потому что одному клиенту важна одна формулировка в письме, а другому совершенно другая. И это не решается тем, что вы наняли ещё разработчиков, мне кажется, именно здесь и видно, кто по-настоящему построил компанию, а кто просто хорошо сделал продукт. В новую категорию зайдут десятки компаний, а лидерами станут единицы, и разница между ними и остальными почти никогда не в технологии, потому что на старте она у всех примерно одинаковая. Не знаю, окажемся ли мы среди лидеров, но точно понимаю, где сейчас основная работа: год назад мы учились делать технологию, потом учились превращать её в продукт, а сейчас учимся строить компанию. И кажется, что третий уровень по-настоящему никогда не заканчивается. А вы на каком уровне? Напишите в комментарии👇🏼

Смыслы и команда Помню как работал над одним продуктом. Задачи сыпались отовсюду. Это была стадия активного роста. Куча функционала, параллельно пересборка интерфейсов, планирование промо и много чего еще. За всем этим добром, я упустил самое важное - это смысл. То есть, у меня то в голове он был, а поделиться им со своей командой я забыл. Здесь мне становится стыдно. На уровне задач, которые шли в разработку, я старался максимально полно описывать зачем нам это и какой профит принесет. Но глобально, это лишь отдельные части пазла. Гораздо проще собирать, если видишь общую картинку. А когда ты собираешь не один, эта картинка становится чертовски важной штукой. Если твоя команда понимает: - для кого делает продукт - какие задачи он решает - что это дает бизнесу - и на какие метрики нужно смотреть ... то появляется магия. Та самая, когда все видят смысл своей работы. Когда любой может предложить идею, и она ложиться в канву продукта. Когда есть драйв делать то, что ты делаешь. И много, много других "когда". Задача продакта - донести смысл. Он отвечает за команду, за бизнес и за счастье пользователя. В свое время я упустил этот момент и сожалею, что не могу крутануть колесо обратно. Но, не все так печально. Исправить ситуацию сложно, но можно. Посмотрите на свои команды, подумайте над тем, точно ли все понимают смысл того, что делают? Донесите его и увидите, какие чудеса начнут происходить💫 #продуктовыйпуть

2. У разработчиков часто есть паттерн поведения: В важной поворотной ситуации вместо того, что сейчас действительно важно (например, выпустить продукт на рынок) - бесконечно допиливать фичи, чтобы и кофе варило, и шаттлы в космос запускало. И этот паттерн неоднократно повторяется во все поворотные моменты. То есть наличие такого паттерна показывает, что в будущем он будет выбирать допиливать. Например, вместо выпуска продукта на рынок, когда надо захватить долю рынка - продукт допиливается ещё 2 года, пока рынок потерян. И наличие вот этого вектора у фаундера "ещё немного допилить вместо коммерчески важных действий" - важный риск в партнёрстве при запуске бизнеса. Если я вижу такой вектор - я сразу обговариваю, будет ли в важной ситуации фаундер слушать меня как маркетолога и партнёра или будет сбегать в бесконечное допиливание, и будут ли у меня рычаги воздействия в этой ситуации. ИИ видит факты и риски, и даже может построить прогноз (если вы ему сказали, где именно и какой прогноз строить, и на что обратить внимание). Я смотрю на то, как эти факты связаны между собой и что они говорят о будущем поведении системы. Предикторы рисков. И принимаю решение, как мне защищать от этих рисков себя или вверенный мне бизнес. Вы можете увидеть в разборе ИИ плюс-минус те же факты и риски. За вычетом того, что он не увидел, пока я об этом не сказала (а вы, соответственно, не догадались у него спросить). Но дальше - сможете ли вы увидеть те же прогнозы, что я? Примете ли вы на основании этой информации те же решения, что я? Увидите ли, где и как надо подстелить соломку? Если у вас меньше опыта, чем у меня - вы не догадаетесь о части этих вещей подумать или спросить у ИИ. И именно этим отличается опытный эксперт с ИИ - от менее опытного человека с ИИ.

Что с движком? Иногда такой вопрос стал прилетать в комментариях. Решил, что лучше напишу объясняющий пост. Я делал движок для создания 3д игр и относительно регулярно постил отчеты о прогрессе. Движок изначально планировался универсальным и функциональным. А кор-составляющей движка была нативная разработка агентами. Потом я увидел, что почти каждый уже пилит под себя движок. Плюс понял, насколько это глубокая и вечная тема. Что побудило меня сдаться и бросить идею. Но наработки не хотелось просто так сложить в полку, поэтому я сделал пивот в сторону движка для рекламных креативов. Фишка была в том, чтобы он использовался для создания 3д-болванок, по которым генерится видео в ИИ. И в целом получилось что-то интересное. Я начал погружаться в тему глубже, но и это направление пришлось оставить. В какой-то момент я сделал несколько прототипов игр и отправил в одно из топ-издательств. Ребятам понравилось то, что получилось, и мы начали делать итерации. Под издательство я сделал специальный пайплайн, куда вошел и движок. Движок перестал быть фокусом и самоцелью. Потому что реальной потребностью стал именно пайплайн под быструю пересборку прототипов и работу над продуктовыми итерациями. И все это уже не универсальное, а под конкретный жанр. Итерируем уже чуть более трех недель. Вышли на финишную прямую доработок, чтобы провести тест. По данному направлению не хочется что-то загадывать и озвучивать раньше времени. Но мне очень нравится продуктовая работа и использование агентской разработки именно для продуктовых итераций. Надеюсь, что вскоре смогу расскать про это больше. Данная ветка развития мне определенно по душе и нужна. @timurtaepov

🎾 как за час навайбкодил прототип > протестил > сменил направление в последний месяц дико влюбился в падел, играю постоянно, и для меня это стало способом не выгорать ну и, как это бывает, в какой-то момент начал смотреть на это уже как продакт стал валидировать гипотезу, что у людей есть частая боль — быстро найти 4-го игрока, когда кто-то в последний момент сливается с игры, из инсайтов - множественные сообщения в чатиках побрейнштормил с гпт, выделил сегменты, подумал про риски, потом пошел в клод и буквально за час навайбкодил простой прототип на джанго с базой данных и вот в процессе понял самое интересное: история, скорее всего, не про b2c в лоб логичнее идти через b2b-модель и делать продукт в первую очередь для клубов, а b2c использовать как канал лидогенерации и тебе не нужно рисовать прототипы в фигме, не нужно сливать сотни тысяч на мвп, чтобы быстро протестировать гипотезу навайбкодил пре-мвп > продолжил в том же направлении или же сменил вектор

Оверкаст и лимит выпусков В начале недавнего выпуска АТП Марко Армент рассказывал про фичу Episodes limit в Оверкасте (начало темы где-то в 7:50): https://atp.fm/703 У любого подкаста можно настроить, сколько выпусков держать скаченными на устройстве. Скажем, ставишь три выпуска, перестал регулярно слушать какой-то подкаст — следующие три выпуска скачались, а дальше уже не качаются — чё зря место тратить. Ну или слушаешь ты выпуски нерегулярно — наготове всегда ждут только последние три, а остальные, если что, придётся скачать вручную. Так вот, Марко рассказывал о проблеме. Что, если человек вручную просит скачать какой-то выпуск, а у него уже три и так скачано? Не удалять же его сразу же для поддержания порядка! А как тогда быть? Марко ввёл в базе данных специальный скрытый флаг «выпуск скачан вручную», чтобы такие выпуски не учитывались в лимите. Это очередной пример того, как даже самые, казалось бы, тривиальные фичи требуют продумывания и учёта разных случаев, которые на первый взгляд могут быть неочевидны. Все проектировщики интерфейса и дизайнеры продуктов должны такие примеры впитывать и копить. В общем, Марко рассказывает дальше. Решение со скрытым флагом худо-бедно работает. Но если пользователь нет-нет, да скачивает выпуски вручную, у него копится расхождение между настроенным и фактическим количеством хранимых выпусков. Постепенно он, разумеется, забывает, что что-то скачивал вручную. Но он видит, что лимит не работает: в каких-то подкастах лежит пять, в каких-то семь выпусков без видимых причин. И он пишет Марко багрепорт или жалобу в Апсторе! В итоге жена подсказала Марко решение всех проблем: просто не давай, говорит, пользователям скачивать больше выпусков, а выводи сообщение: «У вас стоит лимит на три выпуска, а это уже четвёртый». Марко решение понравилось, а мне нет. Оно конечно снимает проблемы с Марко, но не с пользователя. Теперь ведь получается, что программа не выполняет прямую просьбу пользователя скачать подкаст, причём делает это, как говорят юристы, «по формальным основаниям». Оверкаст, чё прикопался, видишь же, я прошу скачать этот выпуск? Просто скачай! Соблюдай принцип «Дай нажать!» Ещё хуже, что при обновлении Оверкаст удаляет все скаченные выпуски сверх установленного лимита. Я бы предложил в таком случае выводить компактное немодальное сообщение: “Episode limit for %podcast% raised to 4”. Так мы и просьбу пользователя уважим, и никаких скрытых статусов вводить не станем. Ну и при обновлении, соответственно, поднять лимиты тем подкастам, которые фактически уже больше набрали вследствие ручной скачки.

Несколько наблюдений за последнее время • Гипотеза: дело не только в мощнейшей прокачке harness-составляющей кодинг-агентов (ultracode, /goal, системных промптов, поиска по актуальной документации в инете и всего остального). Нынешние frontier-модели Opus 5, GPT-5.5 Sol уже обучались на данных, появившихся после начала распространения вайбкодинга в прошлом году и успели вобрать в себя всю накопленную мудрость работы с LLM-разработкой (включая, конечно же, мою статью на Хабре) — поэтому они уже сами достаточно хорошо понимают, как двигаться по задаче, и сейчас их нужно заметно меньше направлять. • Если ещё в конце прошлого года можно было поразить клиента, собрав сразу после первого брифинга рабочий прототип личного кабинета, то сейчас клиенты всё чаще сами приносят завайбкоженные прототипы как часть ТЗ. И всё чаще просят сделать возможность управлять данными на сайте через агентов. То есть теперь продуктам нужна не столько админка, сколько API или MCP. • Code First подход к веб-разработке — сейчас основной в моей студии. Это когда проект начинается не с попытки полностью спроектировать продукт в Figma с воображаемыми данными, а с того, что мы как можно раньше собираем его рабочую версию: со всей логикой, интеграциями и полноценным интерфейсом. Главное преимущество — сразу начинаешь работать с реальными данными: каталогом товаров из 1С, пользователями из CRM, контентом страниц и т.д. И уже на этом этапе становится понятно, как продукт на самом деле должен выглядеть и работать. На этапе красивого дизайна на макетах очень редко получается учесть все особенности реальных данных. Поэтому, когда дело доходит до интеграции настоящего контента, зачастую всё начинает разваливаться. Поэтому мы сначала делаем работающий продукт, а дизайн и UX докручиваем уже в процессе — поверх реальности, а не предположений. Ну и в целом проект быстрее движется, когда уже с первого дня нужно доставать все данные из источников, а не на последних этапах интеграции вёрстки.

Рост роли «AI Product Builder» Традиционные PM-роли сокращаются (до 30% в целом и до 70% в SaaS), вместо них растёт гибридная роль Product Builder — человек, который сочетает product thinking, техническую грамотность, дизайн и быстро прототипирует/шиппит с помощью AI. Количество таких специалистов резко выросло. Организации перестраивают весь product lifecycle вокруг AI. В статье Forbes (от 30 июля 2026): «The Rise of the AI Product Builder: The Future of Product Management» репортят что традиционные product managers будут исчезать к 2030 году. По данным 2026 CPO Impact Report от Products That Count: - ставки PM сократились на 30% в целом и на 70% в SaaS. - При этом появилась и быстро растёт новая роль — Product Builder. Драйверы Старое ограничение (стоимость и скорость исполнения) исчезло. Новое узкое место — человеческое суждение: что строить, когда строить и как создавать реальную ценность. ИИ может генерировать требования, прототипы, код, тесты и документацию. Но он не может решить: - решает ли инициатива значимую проблему клиента - соответствует ли она стратегии бизнеса - является ли лучшим использованием ресурсов === Большинство компаний просто ускоряют старые процессы с помощью ИИ → получают лишь инкрементальный эффект. Топы перестраивают весь product lifecycle под возможности ИИ. PM был в основном координатором Product Builder фокусируется на создании outcomes, используя ИИ Большинство организаций всё ещё построены вокруг функций (product / design / engineering с разными руководителями, метриками и процессами). Эти границы становятся всё менее оправданными. Главный вопрос: что происходит, когда важнее становятся capabilities (способности), а не functions (функции)? Что Builder PM не означает Это не «один человек делает три работы (product + UX + engineering) за одну зарплату». Это не промоушен, а часто просто cost-cutting под красивой обёрткой. Хорошие инженеры любят инженерию и не хотят становиться PM. Дизайнеры не всегда готовы писать бизнес-кейсы. Ролевая компрессия имеет пределы. Настоящий Builder PM — это product-менеджер, который умеет использовать ИИ, чтобы стать в разы эффективнее, не отказываясь от того, что делает его ценным. Это не единорог, а 10x PM. Речь о leverage (рычаге), а не о расширении обязанностей. Правильный reframing Вопрос не «как мне теперь заменить инженеров с помощью AI-кодинга?». Вопрос: как использовать ИИ, чтобы стать 3x / 5x / 10x product-менеджером? ИИ удешевил не только building, но и learning. Побеждает тот, кто быстрее учится (рынок, потребности..) Discovery нельзя пропускать Парадокс: в agent-heavy workflow нужно больше живого синхронизирования с инженерами и дизайнерами, а не меньше. Хорошие Builder PM: - регулярно проводят customer interviews (не только на старте) - строят постоянные каналы обратной связи - сознательно защищают время на discovery даже при росте скорости Главный рычаг — feedback loops Большинство команд просто «используют AI-инструменты». Лучшие строят системы, которые сами улучшаются. Пример: fintech-команда добавила в конец каждого ИИ-ответа вопрос «Это было правильно?». Ответ пользователя сразу шёл в обучение модели. ИИ становился умнее прямо в потоке работы пользователей. == 💡Задача лидера — не просто решать, куда вставить ИИ в продукт, а спроектировать всю систему product management, где ИИ создаёт рычаг, где риски, и где feedback loops делают систему умнее со временем. Именно так получается 10x.

Новое применение Claude Подождите! Не проматывайте на следующий канал. В этом посте не будет ни слова про вайб кодинг, который уже всем порядком надоел 😁 Я хочу вам рассказать про новый подход к разработке внутренних систем для оффлайн процессов. Кто когда-нибудь сталкивался с задачей создания системы, которой ежедневно будут пользоваться десятки людей с разными ролями, в разных локациях, с разным контекстом, тот знает насколько сложно продумать все сценарии и ограничить MVP теми функциям, без которых не обойтись. Именно такая задача стояла перед моей командой — система управления стоком мотоциклов для сети из десятков магазинов дилеров-партнеров, которая позволит оцифровать путь от добавления мотоцикла в продажу до его выдачи покупателю. Стадия развития продукта такая, что никакой автоматизации и синхронизации стоков с партнерами нет. У многих из них нет вообще никакой системы для управления своими стоками. Вместо того, чтобы проектировать сложную систему ролей и прав доступа, мы решили сделать 3 ключевых роли, переключиться на интерфейс которых может любой авторизованный пользователь системы. Грубо говоря это тот, кто управляет стоком всех магазинов, тот кто отвечает за актуальность стока определенного магазина или сети магазинов и тот, кто находится в магазине и отвечает за выдачу товара клиенту. В MVP заложили те действия, которые, как мы думаем, должен делать каждый из них. И главное. На каждое действие в системе добавили логи: какой пользователь, что сделал, с каким юнитом, когда и под какой ролью. И доступ админа, который может в удобном интерфейсе отфильтровать логи по всем параметрам и выгрузить их в CSV. Дальше начинается самое интересное, то что теперь доступно любому с подпиской на Claude Cowork. Нахожу в логах какую-то аномалию, например, продавец удалил юнит из системы вместо того, чтобы отметить его как выданный клиенту. Или менеджер стока удалил юнит и через минуту создал такой же с небольшими отличиями. Прошу Claude сделать анализ всех таких кейсов и получаю идеи для доработок — добавить обязательный выбор причины удаления и предупредить, что при продаже нужно использовать другую функцию. И добавить возможность редактировать определенные параметры у юнитов в доступном стоке для нужной роли. Наверное, к этим выводам мы бы пришли сами. После долгих разговоров с операционной командой, наблюдений за их работой и анализа метрик. Но с Claude это стало возможным после двух недель с момента внедрения системы, когда накопилось достаточно логов для анализа. Бонусом стало добавление интерфейса для анализа логов по юниту, который менеджеры операционной команды используют для «расследования» ошибок своих подчиненных и точеного проведения воспитательной работы 😁 Единственный минус — в этом месяце я дважды достиг лимита токенов, что стоило компании $400. Но, уверен, что польза от таких расходов инвестиций будет намного выше. Ведь каждое улучшение системы, сделанное по наводке AI, улучшает эффективность всего продукта и напрямую влияет на бизнес метрики! #lifehacks #aifuture #claude #salmon

Касдевить нельзя запускать — Провел 32 интервью, — похвастался фаундер. — Много узнал — Как продавать выяснил? — Пока нет Двадцать лет нам вбивали в головы: сначала касдев — потом продукт. Когда сайт стоил 100к рублей, а приложение — полгода разработки и пару миллионов — это был закон выживания. Ошибся сегментом — сжег бабло, похоронил компанию. Разговоры обходились дешевле кода, поэтому мы «изучали потребителей». Год назад я написал пост с этим же заголовком и честно признался: не знаю, где теперь ставить запятую. ИИ уронил стоимость разработки до нуля, простенький Booking собирается за вечер — так зачем болтать? За год насмотрелся на команды в Product Games — и запятая нашлась. Те, кто месяцами проводил интервью, приносили красивые отчёты: «боль подтверждена», «сегмент валидирован». Те, кто запускался, приносили другое: «слабали лендинг, налили трафика, одна оплата». Или: «оплат ноль, зато двое послали нахер». Слова ничего не стоят, поэтому люди врут. А вот своими кровными — нет. Вывод прост: если гипотезу можно проверить продажей — нахер разговоры. Оставь интервью для того, что за вечер не соберешь — томографов и софта для атомных электростанций, например. Там запятая на старом месте. В остальных случаях: кастевить нельзя, запускать.

У меня есть такой противоречивый довод один. Вообщем про предпринимателей и бизнес. Практически каждый «эксперт» последние десять лет продавал: насмотренность, софт скилы, кругозор и прочую муть. И всегда говорилось «мол не обязательно прям знать вот детали, главное умение видеть куда бежать». Так вот аи мне кажется темку то поменяет. Невозможно теперь и в будущем будет знать куда бежать, если ты прям не супер глубоко в теме. Прям очень сильно понимание важно. Ибо все остальное коммодизируется через аишку. Тут конечно скажут мол останется много всего, где невербальная составляющая много значит. Ну и пусть. Я лишь про tech. Посмотрите на качество вайб кодинг продуктов от «именитых» фаундеров. Им дали в руки лучшие инструменты. И что мы видим? В большой степени это все никому не надо. Потому что их сила была в «умении управлять командами», продажах и прочем. Но не в качестве решения/продукта. А что сделать качество нужно шарить знатно. Теперь школьник который шарит быстрее продаст потому что его решение лучше и дешевле. И это можно будет доказать и показать. Ибо инструменты теперь у всех одни. Другими словами легкость производства сильно обесценит очень большую категорию «бизнесменов прошлого» и они не смогут адаптироваться. Так как учиться новому крайне тяжело особенно в такой быстрой индустрии. Prove me wrong.

Суперпозиция — это (не)Знание того, что мы ⇄ рынок ⇄ мир ⇄ Вселенная ещё не выбрали – Это (не)Знание (внутренний и внешний спор) идёт в двух направлениях: "мы не знаем, будет ли это востребовано, потому что мы недостаточно исследовали" (незнание в нас) vs "мы не знаем, потому что рынок сам ещё не решил (потому что всё вокруг возникнет только из взаимодействия наблюдателя и наблюдаемого" (незнание в мире)).

Главная ошибка – выбирать "давайте проведём больше рисёрча" там, где рынок-мир-пространство ещё не знают помнят о проблеме

– Любая фича до своего релиза — это ничто, бесконечное пространство (не)возможных вариантов-кейсов-ситуаций и механик, которое схлопывается в реальность(и) только в момент, когда юзер её начал наблюдать. Наблюдение происходит тогда, когда Нечто постучалось в реальность памяти, и это Нечто резонирует со структурой памяти. Память – это паттерны-фракталы-артефакт(ы) В продукте фича "случается" для пользователя, только если модель продукта резонирует с его существующей ментальной памятью. В ином случае, продукт будет говорить на языке, для которого у памяти пользователя ещё нет структуры распознавания, а всё неизвестное, что происходит в вашем продукте и что не удержал пользователь, бессознательно сохраняется в сознании-памяти пользователя, потому что функция сохранения и есть определение памяти. И всё что пользователь не понял в вашем продукте, он с некоторой вероятностью сможет вспомнить и понять в продукте ваших конкурентов. Наблюдатель и наблюдаемое про вложенность, а не различные объекты

Структура продукта = структура команды = структура мира-рынка и ЦА, которая его наблюдает и строит

Продакт, пытающийся "объективно" (хаха) оценить архитектуру продукта, сам же стоит внутри того же контура, который оценивает (он оценивает сам себя, являясь частью единой Системы), но никак не наблюдателем и наблюдением снаружи. Правильное наблюдение расширяет и сужает пространство решений одновременно. Правильный внутренне-внешний рисёрч работает так же, не просто сужая 100% гипотез до 20%, а расширяя(!) оставшиеся 20% до потенциала 100%. Наблюдение это предсказание и вы можете предсказывать на основе того, что помните

Карьерные советы менеджеру продуктов, которые пора перестать воспринимать буквально Чем быстрее развивается индустрия, тем чаще может казаться, что рекомендации старших коллег и чеклисты в разных курсах и методичках становятся бесполезными. Часто проблема в том, что их продолжают повторять как универсальные правила, хотя рынок, компании и сама роль менеджера продуктов уже изменились. Знание фреймворков, работа с данными, исследования, переходы между компаниями и личный бренд по-прежнему могут помогать в достижении профессиональных целей. Но только если учитывать контекст, ограничения и цену конкретного решения. Без этого полезная рекомендация легко превращается в карьерную ловушку. Собрали 8 советов, которые пора перестать воспринимать буквально. Что в них устарело и что все еще остается актуальным — в карточках. @productmindset

У AI-ассистента есть две проблемы... Если вы пытаетесь хотя бы что-нибудь делегировать AI-ассистенту, то, скорее всего, сталкиваетесь с двумя проблемами: интеграцией и контекстом. Начну с более простой — с интеграции. AI-ассистент не может быть полезен, если у него нет возможности хотя бы прочитать что-то из тех систем, с которыми вы работаете. А на самом деле у ассистента должна быть возможность выполнять там разные действия. Инструментов в жизни продакт-менеджера огромное множество: задачи в одном месте, эксперименты в другом, длинные документы PRD в третьем, транскрипты звонков в четвёртом. Поэтому интеграций нужно много, и рынок, честно говоря, не успевает за растущими потребностями. На помощь нам приходит вайб-кодинг. К счастью, AI-ассистент вполне способен написать себе MCP для нужного сервиса, если у него есть доступ к API. За последнее время только для личных целей я написал себе MCP для Telegram, Gmail и календаря. Технически подкованный продакт сразу замечает: MCP — это, по сути, просто API. Но я заметил одно тонкое различие. Давайте покажу на примере. Если запросить у Gmail одно письмо, то список меток этого письма в сыром виде будет выглядеть вот так:

"labelIds": [
  "IMPORTANT",
  "Label_4579329675731606337",
  "CATEGORY_UPDATES",
  "INBOX"
]

Можно заметить, что системные лейблы прекрасно понятны, потому что у них говорящие ID. А вот мой личный лейбл показывается в ответе как Label_4579329675731606337. Чтобы увидеть читаемое название этого лейбла, нужно сделать ещё один отдельный запрос к API и посмотреть, какому лейблу соответствует этот ID. Для стандартного API это вполне рабочая схема. Нужны дополнительные данные — делаем ещё один запрос. Но для AI-агента это лишний шаг, дополнительная задержка, лишняя трата токенов и засорение контекста на ровном месте. Понятно, что сырые ID ему совершенно не нужны: их нужно сразу расшифровать. Поэтому для того, чтобы из API сделать хороший MCP, его нужно доработать напильником: выкинуть из ответа весь ненужный технический мусор и сразу дать расшифровку всех полей в человекочитаемом виде. Агент читает этот ответ по смыслу — технические идентификаторы сами по себе ему ничего не говорят.

"labels": [
  { "name": "IMPORTANT" },
  { "name": "AMS/Schools" },
  { "name": "CATEGORY_UPDATES" },
  { "name": "INBOX" }
]

И вот в 21-м веке мы подстраиваем сайты под поисковики, соцсети — под алгоритмы, API — под AI-агентов, а себя под требования постоянно меняющегося рынка. А куда деваться? Андрей Менде, PM ML Booking .com, автор симуляторов Claude code AI для продакта, ЛЛМ для продакта, ML для продакта, и др.

Борис Чёрный поделился у себя в твиттере инсайтом, как меняются роли в разработке продуктов:

По мере того как инженерия, продукт, дизайн, DS и другие функции трансформируются в роли нового типа, я размышлял о том, как могут эти роли выглядеть в будущем. Например, глядя на команду Claude Code, я вижу, как мне кажется, пять архетипов: 1. Prototyper: придумывает совершенно новые идеи; много их генерирует, и большинство так и не доходит до релиза 2. Builder: быстро превращает прототип или идею в production-grade продукт и инфраструктуру 3. Sweeper: приводит в порядок интерфейс, упрощает код и систему, убирает лишние фичи, оптимизирует производительность 4. Grower: берёт уже построенный продукт и итерациями улучшает его Product-Market Fit 5. Maintainer: отвечает за зрелость и масштабируемость системы — безопасность, надёжность, скорость и эффективность Люди могут совмещать несколько ролей, иногда три. Я также замечаю, что эти роли не привязаны к должности: в Anthropic одни дизайнеры соответствуют категории 1, другие — 2, третьи — 3. И то же самое с инженерами, продакт-менеджерами и DS. Здоровой команде нужен микс архетипов — в зависимости от продукта: • Новому продукту до PMF нужны люди, сильные в 1+2+3 • Растущему продукту, нашедшему PMF, нужны 2+3+4 и немного 5 • Продукту с прочным PMF нужны 3+4+5 и немного 2 Возможно продуктовые роли будущего будут выглядеть именно так — а не как сейчас, привязанные к конкретной специализации?

→ https://x.com/bcherny/status/2071379474277613732

Чем я сейчас занимаюсь Последний год активно тестим виртуальных персонажей: девушек, парней, селебов, коучей, тренеров, итд. Очень верю в этот формат продукта, потому что одиночество везде усиливается, а ИИ компаньон выслушает без осуждения, подскажет best practices и может просто поддержать. За год намайнили почти 100к юзеров и 800 платящих, но отвал подписок пока что дикий, в основном потому что мы косячим и постоянно тестим. Была опция свернуть в сторону 18+, но решили туда не идти, и сейчас фокус на health & fitness. По дороге запустили пару SEO сайтов: friend2chat.com / friend2chat.ru. Новая для меня область, пока разбираюсь, оценим через год.

Сначала сделай просто У всех ПМов есть такой чемоданчик сохраненок: шаблоны оценок, документы со старых работ, просто полезные статьи и видео. Мне пришла идея сделать такой общий мега-чемодан в сообществе ПМ совет, чтобы каждый мог скинуть что-то полезное в общий котел. Тогда мы собрались группой инициативных ребят и стали придумывать, как это реализовать. Сразу всплыла проблема с копирайтом: вдруг будут добавлять пиратский контент или корпоративные доки. После пары итераций (кажется, прошло несколько месяцев) мы придумали убойный процесс модерации. А еще апвоуты, теги и разделение материалов по группам. Когда мы все это зарелизили, то материалы добавили примерно 2,5 человека, и все эти свистелки оказались никому не нужны. Я допустил совершенно джуновскую ошибку, с головой увлекшись реализацией фичи вместо того, чтобы сначала поисследовать, кому она нужна. Этот пример подтвердил для меня простую продуктовую истину: когда валидируешь гипотезу, сначала сделай просто.

Как мы набросали 3 новых продукт за 3 часа На прошлой неделе с командой работали оффлай и в последний день решили сделать хакатон. Было офигенно! Рассказываю что успели: 1. Задача была – повеселиться, выйти немножко за рамки текущего продукта и "дать себе волю". Не было надежды что что-то из этого можно будет использовать в проде Разбились на 3 команды и делали 3 новых версии для продукта: - Маймит для HRов - Маймит для Sales - Маймит для исследователей У нас давно есть идеи вертикализации, тк сейчас продукт слишком для "всех" Короче поверх текущего Маймита за 3 часа нужно было - закасдевить клиента из воронки - навайбкодить решение, - показать решение клиенту, получить от него фидбек На выходе получили три работающих прототипа, каждая команда провела всем демо Из интересного: В sales-сегменте два агента работали параллельно: Fable и GPT 5.5 xHigh. Фейбл по итогу оказался более консистентный текущему продукту, гпт чуть больше нейрослоп (промпт был одинаковый) Для команды это было прикольно двумя вещами: - посмотреть какие подходы в работе с coding agent эффективнее: кто-то потратил половину времени на план и огромный промпт-цель. Кто-то делал итерациями и 5 параллельными агентами (оказалось хуже) - познакомиться и повзаимодействовать глубже с ребятами из команды, тк были и разрабы и сейлзы условно Результаты хакатона будем развивать дальше в продукты (дай бог). То, что получилось нельзя вчистую использовать в проде, но теперь точно будет легче тк есть вижн, первые черновики и проработка мероприятие зашло команде, немножко напоминает подготовку вечернего мероприятия в лагере – все торопятся, азарт, идеи и вот это всё. В комментах покажу pdf в sales-сегменте для сравнения от Fable и GPT 5.5 xHigh