ruspm | Technologies

Telegram-канал ruspm - Product Management & AI

25296

Product Management & AI Occultism, Philosophy & Logic, YO: @mirvla (c-f 𓇶 Meteoagent.com). SATOR AREPO TE8ET OPERA ROTAS Каналы для продактов: https://t.me/addlist/YvmnHCHUp700Nzky

Subscribe to a channel

Product Management & AI

Авито открыл набор на магистерские программы по ML и продакт-менеджменту, разработанные совместно с МФТИ и НИУ ВШЭ

В основе всех программ реальные кейсы из самого Авито, а занятия ведут эксперты компании, которые поделятся опытом разработки, запуска и управления сервисами.

Магистратура «Управление продуктом в IT-бизнесе» в ВШБ НИУ ВШЭ опирается на матрицу компетенций продакт-менеджера в Авито и охватывает всё управление продуктами: от аналитики и пользовательских исследований до бизнес-моделей и работы с данными.

В рамках «Прикладное машинное обучение и анализ данных» и «Машинное обучение (ML) в цифровом продукте» будут осваивать навыки, начиная от классического ML и компьютерного зрения до рекомендательных систем и генеративного ИИ.

👉 Больше информации о магистратуре

Сейчас у Авито запущено всего 12 программ высшего образования, включая магистратуры, для студентов и выпускников со всей страны.

Читать полностью…

Product Management & AI

Совершенствуем не только продуктовые процессы, но и собственные рабочие с помощью loop engineering и ИИ

– Самые важные знания, возможности и инсайты скрываются в паттернах и закономерностях, лежащих в основе результата, и только потом в результате

– Ценность представляет контролируемое накопление улучшений

– Цикл, который нужно запускать вручную, вспоминая о нём — это не цикл

♾️ agent loop skills
♾️ agent improvement loop
♾️ AI agent orchestration loop

Читать полностью…

Product Management & AI

Loop Engineering for Product Managers

Лучшими продакт-менеджерами станут не те, у кого самая большая библиотека промптов, а те, кто понимает, какие этапы продуктовой работы стоит превратить в устойчивые циклы, какие артефакты должны ими управлять, и какие решения должны оставаться прерогативой человека.

Анатомия и структура продуктовых ИИ-циклов, практика их создания, частые сбои и чем продакту снова поможет GitHub в материале ниже

Читать полностью…

Product Management & AI

Следующее Приложение — это не приложение

Если прямо сейчас открыть телефон и пересчитать иконки приложений, то можно насчитать от десятка до сотни иконок.

И каждое приложение за иконкой это очередная обёртка-обещание продакта и продукта: «Скачай меня и ___ станет проще/дешевле/веселее *» (и у каждой аппы: «* Но сначала потрудись изучить меня от и до»).

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

Но интерфейсы и механики всегда упрощаются (а это значит – исчезают), потому что лучший интерфейс — это отсутствие интерфейса

Поэтому в эпоху ИИ иконок больше не будет.

Появятся «нити пространства диалогов», находящиеся в Том-Самом-Нечто, выполняющим работу, которую раньше приходилось делать с помощью разноцветных иконок.

Следующее "приложение" – Пространство

Читать полностью…

Product Management & AI

Everything Is Recorded Now (с) a16z

Большинство наших рабочих обсуждений теперь записываются по умолчанию. И вам, вероятно, стоит исходить из того, что всё, что вы говорите, отныне записывается.

С технологической точки зрения очевидно, что на основе этого живого контекста компании будет построена новая система, под которую уже выстроена новая категория ПО с ИИ, организованная вокруг голоса, а не текста.

Сегодняшняя система записей — это структурированные данные: записи в CRM, тикеты, вики и документы.

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

Это большая возможность для ПО, и мы всё ещё находимся на ранней стадии понимания того, как будет выглядеть этот программный слой и кому он будет принадлежать.

Granola — яркий пример: у неё лучший контекст о культуре a16z, наших инвестициях и о том, как мы на самом деле думаем, чем почти у любого другого инструмента, которым мы пользуемся, потому что ИИ «была в комнате».

Устные и письменные культуры

Компании делятся на устные (verbal cultures) и письменные (written cultures).

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

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

– Сначала ИИ пришла в ваш корпоративный Gmail, потом в Slack, в таск-менеджер. Теперь ИИ с вами в комнате и на созвонах.

< место для мема Are they AI in the room with us right now?>

Читать полностью…

Product Management & AI

Мне не особо нравится популярность правила Парето

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

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

Мышление в духе 80/20, осознанно и добросовестно применяемое, ускоряет это размытие и падение. Так, вы становитесь ещё "успешнее и эффективнее" в том, что уже умеете и что уже работает, но... теряете способность к тому, что ещё не могли вообразить.

Проблема в том, что основатели не оптимизируют существующие Системы. Они пытаются создать То-чего-ещё-не-существует


И когда правило 80/20 применяют к построению компании под новую идею, продукт, операции или бизнес, оно активно вводит в заблуждение и с самого начала ведёт по неверному пути.

Потому что достичь 80% теоретического потенциала не означает, что вы нашли product‑market fit и создали Нечто, что любят пользователи, или построили бизнес, который может жить сквозь время. Это означает, что вы сделали самую лёгкую часть и теперь занимаетесь оптимизацией ради оптимизации.

Аналогично с 90/10 работает и венчур. Верхние 10% инвестиций в фонде определяют, будет ли фонд хорошим, отличным или легендарным. Ставки внутри распределены неравномерно и они сосредоточены на дальнем конце распределения на компаниях, которые НЕ оптимизировали достижимое, а достигают то, что раньше считалось магией и невозможным.

Если хотите быть Великими, нацельтесь на 90% и выше. Правило 80/20 — это неправильный компас для пути.


Достичь 90% достаточно сложно, но это всё ещё лёгкая часть, если смотреть-на-вещи-правильно. Если хотите стать легендарными, посвятите себя тому, чтобы пройти дистанцию «последних 10%».

...Быть первым – быть в 10 раз больше ближайшего конкурента.
Самолет использует 10% своего топлива для взлета...

Последние первые 10% — это и есть 90% работы и 90% награды.

И в следующий раз, когда речь зайдёт о правиле 80/20, спросите себя, над чем бы вы работали, если бы перестали оптимизировать под «эффективность по Парето» и посвятили себя 10%.

Читать полностью…

Product Management & AI

Loop Engineering — это замена себя как человека, который пишет промпты ИИ, на Систему, которая делает это за вас

5 компонентов цикла (и один бонусный)

Для цикла нужно пять вещей и одно место, где хранить состояние.

1. Автоматизации, которые срабатывают по расписанию и сами занимаются поиском и сортировкой.

2. Worktrees («рабочие деревья»), чтобы два агента, работающих параллельно, не мешали друг другу.

3. Навыки (Skills) — прописанное знание о проекте, которое агенту не придётся угадывать каждый раз.

4. Плагины и коннекторы для подключения агента к уже используемым инструментам.

5. Суб-агенты, чтобы один агент генерировал идею, а другой её проверял.

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

1. Автоматизации — сердце цикла

Именно автоматизации превращают разовый запуск в настоящий цикл. В Codex вы создаёте автоматизацию на вкладке Automations: выбираете проект, промпт, частоту запуска и то, где он будет выполняться.

Результаты попадают в папку Triage, а те запуски, которые ничего не нашли, просто архивируются. OpenAI использует это внутри для ежедневной сортировки задач, подготовки commit-отчётов и поиска недавно внесённых багов.

Claude Code достигает того же через планирование и хуки: /loop запускает промпт или команду с заданным интервалом, можно настроить cron-задачу, хуки на разных этапах жизненного цикла, или отправить всё в GitHub Actions.

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

2. Worktrees: чтобы параллельность не превращалась в хаос

Когда запускается больше одного агента, файлы начинают конфликтовать. Git worktree решает эту проблему: это отдельная рабочая директория в своей ветке, но с общей историей репозитория. Codex и Claude Code поддерживают эту изоляцию — либо встроенными средствами, либо через флаг --worktree.

3. Навыки (Skills): чтобы не объяснять проект каждый раз заново

Навык — это папка с файлом SKILL.md, содержащим инструкции и метаданные, а также опционально скрипты, справочные материалы и ресурсы. Codex вызывает навык по $название или /skills, а иногда и сам, когда задача соответствует описанию навыка. Claude Code делает то же самое.

Навык — это однократно записанное намерение, которое агент читает при каждом запуске


4. Плагины и коннекторы: чтобы цикл касался реальных инструментов

Цикл, который видит только файловую систему, слишком мал.

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

5. Суб-агенты: разделяем созидателя и проверяющего

Самое полезное структурное решение в цикле — отделить того, кто пишет, от того, кто проверяет.


ИИ, написавшая код, слишком снисходительна к своей собственной работе. Второй агент с другими инструкциями (и иногда другой моделью) ловит ошибки, которые первый сам себе наговорил.

Что цикл всё ещё не делает за вас:

Цикл меняет работу, но не удаляет вас из неё. Проверка всё равно остаётся за вами. И если цикл работает без присмотра, он также и совершает ошибки без присмотра.

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

И, наконец, удобная поза «наблюдателя» опасна тем, что очень легко перестать иметь своё мнение и просто принимать то, что выдаёт цикл.

Цикл не знает разницы. Вы знаете.
Всё дело в поиске: а) правильного б) Баланса


Постройте цикл. Но постройте его как тот, кто намерен оставаться инженером/продактом, а не просто нажимателем кнопки

Читать полностью…

Product Management & AI

Что такое циклическая работа ИИ-агентов (agent looping) и открытые/закрытые циклы (по мотивам Anthropic Workshop: Build Agents That Run for Hours)

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

Циклический процесс — это выстроенная вами Система


Её может запустить практически любая платформа для работы с ИИ-агентами; всё зависит от того, как именно вы настроите связи между ними.

В самом простом варианте цикл — это работа агента над собственным результатом:

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

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

Вся эта иерархия продолжает циклически проходить этапы исследования, планирования, выполнения и проверки, пока цель не будет достигнута.

Вы задаете цель, и система выполняет цикл до тех пор, пока работа не будет завершена в соответствии с установленными вами требованиями.

Открытые и закрытые циклы:

ОТКРЫТЫЙ ЦИКЛ носит исследовательский характер. У него есть условия и цель, но вы предоставляете ИИ-агенту или группе агентов широкое пространство для манёвра. Система может пробовать разные пути, делать открытия и создавать то, что вы не описывали в деталях.

Проблема в стоимости – открытый цикл, дающий реальную свободу для исследований, потребляет безумное количество токенов. Для 90% команд, не имеющих неограниченного бюджета, такой подход недоступен, а при работе над проектами с нечёткими стандартами такая Система рискует превратиться в генератор некачественного «мусора».

ЗАКРЫТЫЙ ЦИКЛ имеет чёткие границы в котором ИИ-архитектор сначала проектирует весь маршрут работы:

> ясная цель
> определённые этапы
> проверка на каждом этапе
> точка остановки или возврата результата вам (с передачей данных об эффективности)

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

> за цель отвечает архитектор
> за конкретные шаги отвечают специалисты
> узкопрофильные исполнители выполняют частные задачи
> контрольный этап гарантирует качество и исключает небрежность

Читать полностью…

Product Management & AI

Жизнь роботов в 2026: пассажир авиакомпании Southwest Airlines в США решил взять с собой в салон андроида, и вот что из этого получилось

Аарон Мехдизаде летел из Лас-Вегаса в Даллас и взял в салон своего робота Стьюи, который не пролезал по габаритам ручной клади, а отравлять багажом выходило дорого. Поэтому Аарон просто взял и оформил роботу... билет на соседнее кресло (услуга, которую обычно заказывают для перевозки хрупких вещей).

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

PS. После полета Southwest Airlines быстро опубликовала новые правила перевозки, в которых прописала запрет на перевозку роботов в салоне или зарегистрированном багаже вне зависимости от их размера и назначения. Причина банальна — безопасность при перевозке литий-ионных аккумуляторов.

Читать полностью…

Product Management & AI

Так майский дайджест протекает по Колумбии огнём

Алхимическая задача
Настройки мышления
Гольф глазами продакта
Галлюцинации ИИ = твои галлюцинации

Не пользователи, а люди
Personas это JTBD
– 55 когнитивных искажений
– Библиотека идей, законов и концепций

Минимализм умер
Postmortems for UX
Единство аффекта и интеллекта
Почему мы делаем разные выводы

Теория карьерных якорей
8 часов работы делают тупее
Продакшен — ничто
Про первый лайк

Причина тех долгов – продакт
ИИ психоз у CEO и у компаний
AI-native Startup Founder's Playbook
The “Bug-Free” Workforce

Agent Memory That Survives
Промпт-инжиниринг для не-инженеров
Structured-Prompt-Driven Development
Как экономить токены

State of AI 2025–2026
Design Systems Report
Why research needs to research itself

Пытаясь спланировать непонятное
Решение уравнения без решений
Почему близнецы не симметричны

😌 Persistent Visions by Mark Seelig
🧘‍♂️ Ya-man from The Disciple's Path

Ad: Если нужен английский для работы, то AgileFluent – лучшее решение

Читать полностью…

Product Management & AI

Гипотезы, задачи, фичи – всё начинается как план. Сначала план (но это всё не точно)

0) Сначала сохрани контекст, что в голове, потом планируй. Помни о главном – цели.

Промпт (люблю писать для ИИ капсом):

Задача: ___ Аудитория:___ Контекст:___ бла-бла-бла

НО СНАЧАЛА ОТДЕЛЬНО СФОРМУЛИРУЙ ПЛАН: как ты будешь разбирать и что проверишь перед задачей, прежде чем писать предложение. Прежде чем составлять сам план, задай мне 5–7 уточняющих контекст и ситуации вопросов, ответы на которые сильнее всего повлияют на результат (по одному за раз).


1) Кидай в обработку ИИ сырые данные/транскрипты, даже если это часовой колл. Кинешь саммари и ИИ пропустит и потеряет контекст сразу на 2 этапах: на этапе создания саммари и на этапе работы с саммари.

Не жмись на токены – лишнее фильтруется само, значения есть в каждом слове/фразе.

2) Требуй у ИИ 3+1 вариантов с трейд-офами, а не один. Сначала разведи варианты и смотри на них сверху, после выбирай, далее фильтруй через: «Почему сейчас и почему это, а не другое», после собирай из элементов нужный вам.

Явные non-goals (что мы НЕ делаем) выписывай отдельным блоком.

3) Pre-mortem в план, чтоб хоронить фичи вначале и не хоронить в конце. Проси описать 3 варианта, как твоя затея провалится. Сужай область мышления ИИ через "какое одно предположение в плане, если оно неверно, рушит всё?" + "опиши условия, при которых этот проект стоит остановить, а не продолжать".

Реалистичые сроки начинаются со здоровых и реалистичных задач. Срыв сроков – кривые и нездоровые задачи.

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

5) RACI прямо в плане. На каждый блок указывай кто делает, с кем советоваться, кто апрувит, кого просто информируем. Хорошо помогает увидеть слабые места не только в фичах, но и в людях.

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

7) 20% усилий закрывают 80% боли, и облегчённый вариант гипотезы/идеи/фичи/продукта оказывается самым успешным.

8) 80% планов не нужны 😎

Читать полностью…

Product Management & AI

Синхронность и фрактальность в userflow→UX→UI→коде

Никогда не думал, что скажу такое, но...

КАК ЖЕ СИЛЬНО техническое мышление разрабов может помогать продакту в осознании и познании механик продукта и пользователей.


Простыми словами:

–  Баги в коде (я не про баги со скобками и запятыми, а про ошибки логики и архитектуры кода) = баги в пользовательской проблеме/решении. То, что было не продумано/забыто в коде, аналогично этого же не будет хватать пользователям в механиках продукта.

– У любой механики → фичи → кода есть обратная сторона, которая является логическим продолжением и завершением петли механики. Логика, вообще, любимое слово наших друзей-программестов )))

Примеры: экшены "Добавить/Исключить", функции "Follow/Ignore" и т.п. Забыл что-то одно, и вот уже код кривой и вылезут баги когда спустя время решите делать и программист будет писать противоположную фичу по другому → userflow неполный → фича неполноценная → и, что главное для продакта/продукта – пользовательский сценарий будет не закрыт. И будут баги и пробелы, но уже в продукте/решении/процессах.

Фрактальное подобие механик/функций/кода. Моё любимое и весьма сложное даже для разрабов (на самом деле, очень просто, в этом суть Фрактала).

Реакция (не лайк) на пост, реакция на пост-комментарий (комментарий это пост, не комментарий), реакция на ответ на комментарий-пост — всё сущности должны быть максимально общими/простыми/гибкими, чтобы использовать самим себя на разных уровнях систем.

И если 3 разные сущности и типа записей контента и 3 разных типа лайка для них, то вот у тебя уже 6 зависимостей вместо 2 и 27 потенциальных вариантов багов.

Каждая (всякая ((Единая))) сущность в коде и в Системе должна быть собой, порождая своё фрактальное подобие, то есть использовать саму себя


Чем больше сущностей в архитектуре - тем больше рамок, функций, зависимостей и ограничений они все в себе несут. И тем больше ограничены все наши фичи, сценарии, механики и пользователи в продукте. Мы сталкиваемся с этим, когда слышим от разрабов: "Ууу, у нас архитектура этого не позволяет". Вот, это оно!

– У всего должен быть (есть) Один-Источник-Правды

Статус пользователя, статус заказа, статус объекта, чего угодно – если оно хранится и проверяется в двух местах (зачем? почему? в чем причина этого? в процессе? а может быть, что-то не так с таким процессом?), то вы внедряете несколько несколько вызовов, несколько зависимостей, несколько проверок, 2+ логики и 2+ функции...

И однажды, 100%, они разойдутся, Система для себя сделает одно, а пользователь увидит иное и это превратит их/ваш userflow→UX→UI→код с продуктом в Хаос...

Смотри в продукт душой и сердцем продакта глазами программиста. Это – бесценно!

Читать полностью…

Product Management & AI

I think the reason so many people don't understand how big AI is going to be is that they don't understand that

everything is an algorithm


Specifically, they don't realize that companies are just a collection of algorithms

– Think about that very carefully every day 👆

Читать полностью…

Product Management & AI

Причина тех долгов в продукте – продакт

А в эпоху ИИ не должно быть никакого тех. долга вообще.

ИИ должен устранить весь технический долг: а) который был накоплен ранее; б) любой последующий планируемый тех долг ещё до того, как представить свой готовый код.

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

И если ИИ говорит вам, что "оставляет что-то на потом", это первый шаг к галлюцинациям и сигнал, что ты:

1) неверно определил проблему пользователя → 2) придумал несуществующий userflow → 3) спроектировал кривой UX/UI, механику решения и фичу = поэтому ИИ тупит с логикой и архитектурой кода и предлагает взять тех. долг.

Причина тех долгов в продукте – продакт

Читать полностью…

Product Management & AI

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

И это именно тот зазор между причиной~и~следствием, где таятся все возможные варианты развития событий


Когда Будда говорил о непостоянстве как об источнике страдания; когда квантовая физика открыла бесконечную вероятностную природу реальности; когда предприниматели обнаруживают, что рынки по своей сути непредсказуемы, то все они указывают на одну и ту же истину:

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


Религиозное сознание называет это верой; предпринимательское – смелостью; а нейробиологическое – регуляцией миндалевидного тела со стороны префронтальной коры головного мозга.

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

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

Суть здесь не в том, чтобы победить страх, а в том, чтобы осознать простые вещи:

неопределённость – это базовое состояние Вселенной-Реальности, и именно сопротивление ей (а вовсе не сама неопределённость) порождает паралич воли


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

К этому состоянию нужно прочувствовать Путь.

Практика проста. Замечай моменты, когда ты пытаешься избежать мелкой неопределённости: навязчиво проверяя телефон, чрезмерно готовясь к незначительным беседам, ища подтверждения своей правоты и безопасности снова, снова и снова.

Вместо этого сделай паузу, чтобы ощутить телесный и подсознательный дискомфорт, не пытаясь при этом немедленно его устранить.

Дыши. Пропускай. Чувствуй.

Далее, начни действия: вступи в разговор, не планируя заранее, что именно ты скажешь; начни проект, ещё не чувствуя его полной готовности; выбери другой маршрут, не сверившись с картой.

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

Именно это древние стоики называли "добровольным дискомфортом". Именно этот принцип лежит в основе экспозиционной терапии.

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

Трансформация же происходит за счёт накопления такого опыта.

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

Comfortable with Uncertainty: 108 Teachings on Cultivating Fearlessness and Compassion by PEMA CHÖDRÖN (c)

Читать полностью…

Product Management & AI

Что фундаментально изменило мир к худшему, но люди этого ещё не осознали?

То, что смартфоны и алгоритмические ленты сделали со скукой и... пользой от неё.

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

Это было когнитивное состояние, которое переводило мозг в режим, который сегодня мы называем «сеть пассивного режима работы мозга» (default mode network) – своего рода фоновую ментальную обработку, во время которой он консолидирует воспоминания, развивая мышление через (не)осознанное воображение, фантазию, эмпатию, генерируя творческие идеи и выстраивая связ(ан)ное-ощущение-Себя-и-мира.

Когда мы смотрели в окно, ждали автобус или тихо сидели после ужина, наш мозг выполнял одну из самых важных своих работ.

Скука была, в самом прямом смысле... двигателем сознания и внутренней жизни.

Читать полностью…

Product Management & AI

8 советов по работе с логами продукта

1. Ведите decision log с условиями пересмотра, а не просто с решениями

Записывайте не только «что решили», но и «при каком сигнале пересмотрим», например, «откатим приоритет, если retention упадёт ниже X».

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

2. Калибруйте собственные прогнозы и лог: дата релиза, ожидаемое внедрение, ожидаемый эффект и через время сверяйте их с фактом.

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

3. Размечайте решения как «дверь в одну сторону» или «в две стороны»

Обратимые решения принимайте быстро и дёшево, необратимые – с реальной строгостью.

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

4. Инструментируйте спеку, а не продукт

Определяй метрики и названия событий прямо в PRD, ещё ДО разработки (а не «допишем аналитику потом»). Потому что «мы забыли это трекать» это самая частая и самая дорогая (и лекго предотвратимая) ошибка продакта.

События/метрик нет в документе = их и не будет после


5. Ведите в лог карту допущений с осями «уверенность × влияние»

Отделяйте discovery-долг от delivery-долга как список открытых вопросов и допущений с явной пометкой, насколько вы в них уверены.

Де-рискинг самого опасного допущения и вот вы уже перестаёте строить уверенно поверх того, во что на самом деле не верите


6. Делайте pre-mortem с триггерами, а не как разовое упражнение

Опишите провал до запуска, а к каждому сценарию провала привяжите опережающий индикатор из пункта 1 и 2.

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

7. Заведите «кладбище» отклонённых идей с причинами. Каждая зарезанная фича отправляется в searchable-список продуктовой wiki с строкой «почему нет».

Это лекарство от бесконечного цикла переобсуждения одного и того же командой и одновременно ваш самый честный материал для раздела «Не делаем» в новых PRD.

Сильный продакт узнаётся по тому, как быстро он объясняет, почему "нет"


8. Кодифицируй ход мышления-решений

«Откуда ты узнал?» / «У нас метрика Х упала, ааачоделать?» / «СЕО опять принёс идею, что ответить» и прочее повторяющееся изо дня в день выпиши как личную библиотеку подходов и приёмов.

Ответы: «Подумал, уточнил, проверил» / «Проверил фичи, что релизили недавно» / «Вернём ему проблему»

Управление контекстом вокруг контента и есть тот самый недооценённый актив команды продукта и главный навык продакта.

Читать полностью…

Product Management & AI

ИИ уже меняет бизнес — вопрос только в том, кто им управляет 😎

Магистратура «Управление внедрением ИИ в бизнес» от МИФИ и «Школы 21» — для тех, кто хочет быть этим человеком.

Фокус обучения:

🔹 живые сценарии — куда встроить ИИ, чтобы было быстрее, дешевле, эффективнее;

🔹 управление продуктами и понимание технологий, чтобы разговаривать с разработчиками на одном языке;

🔹 реальные проекты от компаний прямо во время учёбы;

🔹 в конце — диплом МИФИ и портфолио, с которым можно идти на собеседование

Все подробности и заявка — на сайте

Читать полностью…

Product Management & AI

Метод Стэнфорда — это прежде всего способ мышления через многосторонний обзор + карту противоречий + синтез + взаимную проверку

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

Никакого ПО, никакого GitHub, никакой сложной настройки — скопируйте и вставьте промпты и через 5 минут вы будете знать о выбранной теме больше, чем те, кто потратил на её изучение десятилетия, годы, месяцы, недели, дни (Господи, что я несу, как же дико это звучит)

Читать полностью…

Product Management & AI

Летом 2024 года McDonald’s свернул тестирование голосового ИИ в Макавто и разорвал партнёрство с IBM, потому что ИИ пробивала клиентам мороженое с беконом, сотни наггетсов и путала напитки. Эксперимент обошёлся в круглую сумму, а на выходе компания получила лишь баги и вирусные тиктоки с негативом (но это не остановило её от экспериментов с ИИ).

О чём этот кейс говорит менеджерам и руководителям?

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

И чтобы не повторить судьбу ИИ-Макавто, нужно понимать специфику ИИ-проектов: как выстроить работу ИИ, как считать экономику, и как контролировать процесс.

Усилить свои компетенции в области ИИ можно на курсе «Управление ИИ-проектами» от Академии Эдюсон.

За 3−4 месяца на практике вы:

– научитесь анализировать готовность компании к внедрению ИИ, проводить аудит бизнес-процессов, оценивать сроки, риски и бюджет;

– научитесь переводить метрики в понятные бизнесу цифры и защищать бюджеты;

– освоите инструменты разработки без кода (n8n, Dify, Flowise, Cursor/Bolt), чтобы создавать ИИ-агентов и автоматизировать нужные процессы;

Обучение построено на опыте экспертов из «Яндекса», «Сбера» и других крупных компаний. Год на связи личный куратор, а доступ к материалам и будущим обновлениям останется у вас навсегда. По окончании курса – портфолио из 8 личных проектов.

Оставьте заявку с промокодом PMAI и забирайте скидку 65% и второй курс в подарок.

Читать полностью…

Product Management & AI

ИИ-ассистент: как найти рутину, собрать рабочий сценарий и посчитать экономию времени – тема бесплатного практикума «ИИ-ассистент отдела без кода» от ОТУС

О чём будет эфир:

— зачем обучать сотрудников работе с ИИ;
— где в команде обычно прячется рутина
— как собрать ИИ-ассистента без кода
— как понять, что ИИ экономит время, а не создаёт хаос
— ошибки, риски и безопасность

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

👉 Бесплатное участие

Реклама ООО «Отус онлайн-образование»

Читать полностью…

Product Management & AI

Главная точка сбора ИТ-коммьюнити этим летом 🌞

Т-Банк снова проводит «Сезон кода» — летний фестиваль про продукт и разработку. В этом году он пройдёт в двух городах: 20 июня в Санкт-Петербурге и 4 июля в Казани.

В программе три направления:

📌клиентоориентированный код с разбором решений для миллионов пользователей;

📌новая секция «Продуктовая кухня» про то, как гипотезы превращаются в рост продукта;

📌 «Бэкенд-методичка» с практиками и инструментами из ежедневной работы инженеров.

Помимо докладов — демозоны, нетворкинг, активности и традиционное афтепати с летним DJ-сетом.

Участие организовано через благотворительный взнос: 2000 ₽ в Санкт-Петербурге и 1500 ₽ в Казани.

Если хотите провести выходной среди разработчиков, продактов, архитекторов и аналитиков, успейте зарегистрироваться.

Читать полностью…

Product Management & AI

Сотрудники Anthropic едут на работу после IPO

Читать полностью…

Product Management & AI

На PeopleSense'26 одна из панелей была посвящена тому, как ИИ меняет работу ИТ-руководителей. В своем выступлении управляющий директор направления первичной недвижимости Авито Недвижимости Дмитрий Алексеев показал, как смещается акцент с контроля процессов на ответственность за результат.

Происходит вот что:
1) Еще недавно руководителем считался тот, кто контролирует процессы и держит все под контролем.

2) С появлением ИИ‑агентов стало понятно, что именно этот слой работы автоматизируется первым. Как раз для этого такие инструменты и создаются — забирать рутину и контролировать поток задач.

То, что не автоматизируется, — это ответственность.

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

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

Рецепт от Алексеева на понедельник утром, чтобы к пятнице не оказаться не у дел: разберитесь в экономике своего продукта — где он создает ценность, а где теряет деньги. Выберите одну бизнес-метрику, за которую готовы отвечать лично, и выстройте вокруг нее продуктовую, коммерческую и финансовую части. Рутину отдайте ИИ, а сами занимайтесь решениями.

Читать полностью…

Product Management & AI

Пока одни команды тратят недели на проверку гипотез, другие используют ИИ для ускорения исследований, анализа обратной связи и подготовки решений.

17 июня в 19:00 МСК ОТУС проведёт открытый урок курса «Менеджер продукта в ИТ», на котором вы узнаете:

— как превращать сырые наблюдения в проверяемые идеи;
— какие задачи можно делегировать ИИ при работе с интервью и данными;
— где ИИ действительно сокращает время проверки гипотез;
— на каких этапах решение всё ещё зависит от продуктового мышления.

👉 Бесплатное участие

В результате вы получите практическую схему применения ИИ в ежедневной работе менеджера и сможете быстрее проходить путь от идеи до выводов без потери качества решений. Реклама ООО «Отус онлайн-образование»

Читать полностью…

Product Management & AI

Как собрать дизайн-систему с Claude Code для реального AI SaaS от концепта до готовых экранов?

Есть идея, есть PRD, есть понимание, каким должен быть продукт. Но чтобы дойти до реальных экранов, нужно собрать дизайн-систему, развести компоненты, сверстать каждый экран. А гипотезы хочется проверить уже сейчас, но вы неделями собираете UI руками. Знакомо? А что если этот Путь пройдёт ИИ-агент?

3 июня в 18:00 мск Даниил Шишко из Pixel Perfect проведёт эфир, на котором возьмёт концепт и соберёт дизайн-систему через Claude Code и Figma MCP на реальном стартапе для голосовых ИИ-агентов и на её базе сверстает готовые экраны продукта.

Чем полезно занятие:

– научишься собирать дизайн-систему через Claude Code и Figma MCP сам;
– 4 скилла для Claude Code: для сборки и поддержки своей ДС;
– поймёшь, как отдать агенту рутину поддержки больших ДС.

👉 Эфир пройдёт в канале Даниила: /channel/+2YaLKdHv_p5lNDZi

Читать полностью…

Product Management & AI

🔥 Мы ждали этого от ИИ-агентов: теперь экраны авторизации проходятся без проблем

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

Наталья Савенкова, AI Product Manager в Яндекс Go, на своём опыте проверила, способны ли современные браузерные агенты помочь с такими задачами. Она столкнула лбами свежий Kimi WebBridge, привычный Playwright и BrowserMCP. Никаких синтетических бенчмарков — только реальные условия и суровая продуктовая рутина.

В статье четыре распространённых сценария:

🔸 Анализ закрытых платформ.
🔸 Визуальный аудит B2B-продуктов.
🔸 Автономные smoke-тесты.
🔸 Сборка автоматического рабочего процесса.

Прочитать полный обзор можно в блоге Городских сервисов Яндекса

Читать полностью…

Product Management & AI

Claude Code выкатили Dynamic Workflows

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

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

Dynamic Workflow — это JavaScript-скрипт, который оркестрирует субагентов в масштабе. Claude пишет этот скрипт под конкретную задачу, а рантайм выполняет его в фоне. План переходит в код, а не в контекстное окно Claude, все промежуточные результаты живут в переменных скрипта, и в контексте оказывается только финальный ответ. Тем самам ваша сессия с ИИ остаётся отзывчивой и неперегруженной контекстом, пока все агенты работают над большой задачей.

Попросите Claude Code создать воркфлоу напрямую через промпт, например, "Create a workflow...", либо включите новую настройку в ultracode) и и Claude динамически сформирует план оркестрации, которого будет неукоснительно придерживаться, что позволит ИИ и вам быть абсолютно уверенными в том, что каждый этап выполняется в правильной последовательности даже при участии сотен ИИ-агентов.

– Чо там у нас по тех долгу?

Читать полностью…

Product Management & AI

Марк вчера запустил премиум подписки для Instagram, Facebook и WhatsApp

$4/месяц для каждой аппы за стату, суперреакции, долгие сторис и всё такое, но интересно в этом всём причины и время, когда Марк решил это раскатить.

А видятся они в простом:

1) Бесплатная версия социалок с рекламой работала, пока предельные вычислительные затраты на инфру и код социалки ≈ 0. Код и код, крутится себе на серверах в Калифорнии, реклама, рожь, VR-Вселенная без ног, кайеф.

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

Теперь представьте на масштабах всех трёх социалок Марка. Поэтому одна лишь реклама теперь не может окупать ТАКОЕ (бедный Марк).

– 2023 год: Эпоха массовых бесплатных продуктов подходит к своему логическому завершению с введением подписки на синюю галочку в Твиттере.

Хочешь получать профит от Х в виде приоритета в реплаях и рекомендациях в ленте (то есть, быть на виду)? Значит твой продукт это ты сам, ты перепродаешь себя, а значит... это B2B, поэтому ты должен плотитьнологи
.

Теперь и Инста с Фб официально конвертнулись в сознании юзеров из B2C в B2B продукт. Вместе с юзерами.

Читать полностью…

Product Management & AI

Галлюцинации ИИ – это твои галлюцинации: испытываем их вместе с ИИ (вайбкодинг ч.4)

Подбираемся с ИИ уже к сотне фич, багов, целому параду планет различных стимуляторов, транков и всего такого всех цветов и заметил, что:

если в первых версиях ИИ часто выдавала бред из-за недообученных моделей, то нынешние версии начинают глючить и впадать в бесконечные рассуждения по одной причине – ТЫ делаешь что-то не так, а не ИИ.

Понять, что ИИ попала в петлю просто – она начинает рассуждать 3+ минут вне зависимости от переформулирований и не сдвигается в рассуждениях ни на шаг, лишь проливая воду на экран и память. Тонны объяснений и перебираний вариантов, все эти "Wait, but" и... ничего.

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

КАК ДЕЛАТЬ КОД:

– проси системный подход;
– проси фрактальное подобие;
– проси общие утилитарные модули.

– Проси сначала проверить и описать архитектуру решения по таким условиям и только после твоего апрува писать код.

– Проси комментить все допущения, которые ИИ будет делать а) во время обсуждений; б) в комментах коде. Так ты увидишь, что она додумала за тебя и сможешь исправить это как: а) до релиза; б) так и после.

– Ведите в CLAUDE .MD словарь терминов и оперируй по нему в промптах и новых сессиях. "Термин / определение + сущности" через которые вы с ИИ должны оба понимать о чём говорите. Иначе через 10 итераций у тебя "вдруг" окажется две сущности типа UserManager с разной логикой.

– Лучший способ проверить, что ИИ понимает механики и зависимости фич и кода это попросить объяснить их через "что в системе сломается, если это убрать".

Если ты видишь дальше/больше ИИ, объясни ей это и попроси обновить: а) доку в CLAUDE .MD; б) комменты в коде. Проси, чтобы писала, что код принимает, возвращает, какие сайд-эффекты. Всё это спасёт тебя и её от галлюцинаций при следующих сессиях, когда контекст предыдущих сбросится.

ЧТО НЕ ДЕЛАТЬ:

1) Думать, что ИИ всё поймёт. Она поймёт, только но по своему, по своему напишет код и не сообщит тебе об этом. А ты потом будешь тупить и пытаться отловить несуществующую багу.

И вы не найдёте её, потому что ИИ будет глючить и пропускать это место, считая его нормой работающего кода/механики, и для неё это будет "не бага, а фича". Так легендарный мэм сыграет для тебя в обратку новой краской.

– Не давать ИИ полный 360° контекст вокруг изменения или апдейта фичи. Какие механики затрагиваются фичей; какие ещё (всегда есть место для ЕЩЁ); где ещё эта фича вылезает; с какими сущностями она ещё связана и в каком контексте (снова где ещё).

– Проси ИИ выстроить приоритет задач самой, в противном случае рискуешь словить то, что один код будет создавать костыль и ломать другой, причём это будет незаметно сразу.

– Не проси фиксить баги, не объяснив их симптомы и ожидаемое ТОБОЙ поведение. У меня было много раз, когда ИИ чинила только то, что я ей описывал, и ломала то, что не упоминал.

А ещё она чинила несуществующие баги, потому что я плохо сформулировал баг-репорт и не дал весь контекст. Пришлось перепроверять и тестить половину кода и назвать это красивым словом рефакторинг.

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

– Не копите. Технический. Долг. Молча. Если что-то допускаете как "ну ок, оставим пока вот так" – закомментите это в коде и claude md.

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

...Relax. Breath...
Новое окно. И новый взгляд.
Вайбкодинг он про то, чтоб ТЫ не потерял все нити.
Но, если что – режь всё, пиши фичу с нуля с начала.

Читать полностью…
Subscribe to a channel