Ничего необычного, это GitHub продакт-менеджера, благодаря которому чувака взяли Senior AI PM в Google Cloud
У Аакаша вышла хорошая пейвол-статья про гитхаб для продактов на примере github.com/shubhamsaboo. Кому влом платить:
Активный GitHub рассказывает о вас то, что не может передать ваше резюме:
– Гитахб публично показывает, что вы действительно Создаёте Нечто, а не просто умеете красиво рассказывать о создании чего-то.
В нём можно вести логи своих вайб-продуктов, продукта компании, и вести свой продуктовый продакт-лог (блог?).
– Гитахб показывает то, как именно вы это нечто создаёте. Всё то, что мы обычно вырезаем из резюме, дабы оно прошло фильтры машин/эйчаров, можно рассказывать в своём гитхабе.
NDA? Никто ж не запрещает в нём делиться вашими публичными апдейтами продукта и намекать на то, как вы с командой к ним пришли.
– Свой Гитахб и форки показывают вашу продуктовую насмотренность и осведомлённость в области любых продуктов, их конкурентов (альтернативных решений проблем) и окружения и дополнений вокруг них. Просто потому, что гитхаб про опенсорс, а опенсорс есть чистый креатив без правил.
– Гитахб показывает, что вы, как минимум, понимаете то, как работают технические команды, что такое Код, и что вы умеете работать с инструментами, которые ваша команда использует ежедневно. То есть то, что вы – специалист.
– Да и в целом, Гитахб – это своеобразная соц сеть, в которой можно найти кучу полезного.
У Аакаша вышла хорошая пейвол-статья про гитхаб для продактов на примере github.com/shubhamsaboo. Кому влом платить:
Активный GitHub рассказывает о вас то, что не может передать ваше резюме:
– Гитахб публично показывает, что вы действительно Создаёте Нечто, а не просто умеете красиво рассказывать о создании чего-то.
В нём можно вести логи своих вайб-продуктов, продукта компании, и вести свой продуктовый продакт-лог (блог?).
– Гитахб показывает то, как именно вы это нечто создаёте. Всё то, что мы обычно вырезаем из резюме, дабы оно прошло фильтры машин/эйчаров, можно рассказывать в своём гитхабе.
NDA? Никто ж не запрещает в нём делиться вашими публичными апдейтами продукта и намекать на то, как вы с командой к ним пришли.
– Свой Гитахб и форки показывают вашу продуктовую насмотренность и осведомлённость в области любых продуктов, их конкурентов (альтернативных решений проблем) и окружения и дополнений вокруг них. Просто потому, что гитхаб про опенсорс, а опенсорс есть чистый креатив без правил.
– Гитахб показывает, что вы, как минимум, понимаете то, как работают технические команды, что такое Код, и что вы умеете работать с инструментами, которые ваша команда использует ежедневно. То есть то, что вы – специалист.
– Да и в целом, Гитахб – это своеобразная соц сеть, в которой можно найти кучу полезного.
Product Management & AI
Всё что нужно – это пустой родмэп (с) Я намеренно держу план проекта пустым. Недавно ко мне в офис зашла вице-президент по продажам. Она хотела к пятнице создать панель управления отчётностью. Я сказал ей, что это уже есть в плане проекта. Она стала выглядеть…
Смерть отслеживания задач – это эволюция
Отслеживание задач/тикетов – это функция корпоративного принуждения, направленная на то, чтобы люди (хотя бы!) вели списки дел, чтобы другим людям было ясно, кто за них отвечает, чтобы другие люди согласовали выполнение этого другими людьми...
Истинная суть, лежащая в основе подхода к разработке продуктов, которую все знают:
Бэклог/родмэп даёт ощущение ложной уверенности в важном и спокойствия, показывая следующее "100% точно важное" действие (вот оно, только протяни палец), но именно из-за этого мы месяцами начинаем забивать и апрувить их вопросами и задачами, которые... устаревают месяцы назад.
Чистое пустое пространство заставляет отступить в сторону и спокойно подумать о том, что действительно следует делать дальше, поскольку видение и мышление становятся менее инерционными и предвзятыми.
Всего два простых вопроса:
Кошмарный сон любой корпы – работа без задач, которая означает потерю значительной части ежедневного контроля над тем, как ведётся работа.
Но именно такой подход назревает уже несколько лет (ок, десятков лет), и именно так развиваются автономные и гибкие команды/продукты.
Всё что требуется для этого:
– Небольшие и плоские структуры. Если вы хотите работать без списков задач, то каждая проблема/задача/вопрос должны решаться одним сообщением с одним человеком.
– Участники команды, которым вы доверяете самостоятельное управление проектом, а также участники, которым вы доверяете принимать небольшие независимые решения. Первые и вторые должны стать той самой единой структурой.
– Высокий уровень рабочего контекста и инфраструктуры разработки. Первое содержит в себе всю необходимую вводную информацию-базис для команд, второе позволяет им свободно трансформировать её в продукты без ограничений.
✨ Единственные рамки: исправление ошибок должно иметь приоритет над работой над новыми фичами, а стабильное состояние продукта должно быть таким, когда ошибок вообще нет ✨
Только достигнув этого состояния можно пробовать отказываться от того, что мы привыкли называть "отслеживанием задач".
И если ты хочешь увидеть, как выглядит будущее, ищи ответ не на kanban-доске.
Отслеживание задач/тикетов – это функция корпоративного принуждения, направленная на то, чтобы люди (хотя бы!) вели списки дел, чтобы другим людям было ясно, кто за них отвечает, чтобы другие люди согласовали выполнение этого другими людьми...
Истинная суть, лежащая в основе подхода к разработке продуктов, которую все знают:
Если что-то ВАЖНО, это всплывёт. Снова. Снова. И снова. Пока до тебя это не дойдёт
Если что-то важно, тебе напомнят о его существовании. Снова. Снова. И снова. Пока... нутыпонел
Тебе не нужно отслеживать что-то важное, чтобы помнить о его существовании. Потому что см. выше почему
Бэклог/родмэп даёт ощущение ложной уверенности в важном и спокойствия, показывая следующее "100% точно важное" действие (вот оно, только протяни палец), но именно из-за этого мы месяцами начинаем забивать и апрувить их вопросами и задачами, которые... устаревают месяцы назад.
Чистое пустое пространство заставляет отступить в сторону и спокойно подумать о том, что действительно следует делать дальше, поскольку видение и мышление становятся менее инерционными и предвзятыми.
Всего два простых вопроса:
Почему это происходит именно сейчас? Что говорится этим?
Кошмарный сон любой корпы – работа без задач, которая означает потерю значительной части ежедневного контроля над тем, как ведётся работа.
Но именно такой подход назревает уже несколько лет (ок, десятков лет), и именно так развиваются автономные и гибкие команды/продукты.
Всё что требуется для этого:
– Небольшие и плоские структуры. Если вы хотите работать без списков задач, то каждая проблема/задача/вопрос должны решаться одним сообщением с одним человеком.
– Участники команды, которым вы доверяете самостоятельное управление проектом, а также участники, которым вы доверяете принимать небольшие независимые решения. Первые и вторые должны стать той самой единой структурой.
– Высокий уровень рабочего контекста и инфраструктуры разработки. Первое содержит в себе всю необходимую вводную информацию-базис для команд, второе позволяет им свободно трансформировать её в продукты без ограничений.
✨ Единственные рамки: исправление ошибок должно иметь приоритет над работой над новыми фичами, а стабильное состояние продукта должно быть таким, когда ошибок вообще нет ✨
Только достигнув этого состояния можно пробовать отказываться от того, что мы привыкли называть "отслеживанием задач".
И если ты хочешь увидеть, как выглядит будущее, ищи ответ не на kanban-доске.
Product Management & AI
Ценность и Продукты – Определяй ядро ценности через CJM. Найди одну-две точки, без которых продукт для пользователя бессмыслен. Усиливай именно их. – Скорость ценности – то, как быстро пользователь получил ощутимый результат в первые минуты/часы. – Эхо…
Если бы завтра какая-то команда с $50M инвестиций клонировала ваш продукт, что бы она не смогла воспроизвести даже через три года?
Будьте честны – это не ваша база клиентов/данных/УТП/НКП/культура/стратегия/понимание/связи и т.п. С $50M вы можете купить всёэто, а ИИ плевать на ваши "знания".
Если вы перебираете варианты с ответами, то вы должны осознать, что держите в руках просто наборы фич, а не свет и бриллианты. Потому что фичи копируются и поглощаются, это физика природы рынка фич.
Не больше, а ярче, крепче и сильнее.
Ваша деятельность и продукт приносит и накапливает ценность Вне-Времени, или вы бежите по беговой дорожке, скорость и длина которой увеличивается с каждым кварталом?
Выживают только те Продукты, которые изначально не были просто продуктами
Если это не то, что вы строите, сейчас самое время выяснить, что же это такое.
Будьте честны – это не ваша база клиентов/данных/УТП/НКП/культура/стратегия/понимание/связи и т.п. С $50M вы можете купить всёэто, а ИИ плевать на ваши "знания".
Что конкретно вы создали, чему научились или что заработали, что требует времени и что нельзя купить за деньги?
Если вы перебираете варианты с ответами, то вы должны осознать, что держите в руках просто наборы фич, а не свет и бриллианты. Потому что фичи копируются и поглощаются, это физика природы рынка фич.
Что вы создаёте, что становится ярче, крепче и сильнее с течением времени?
Не больше, а ярче, крепче и сильнее.
Ваша деятельность и продукт приносит и накапливает ценность Вне-Времени, или вы бежите по беговой дорожке, скорость и длина которой увеличивается с каждым кварталом?
Выживают только те Продукты, которые изначально не были просто продуктами
Если это не то, что вы строите, сейчас самое время выяснить, что же это такое.
This media is not supported in your browser
VIEW IN TELEGRAM
Ключ понимания Систем лежит в мышлении системой действий-состояний пользователя, а не набором страниц с моментами. Когда продакт игнорирует системы, он начинает создавать моменты.
Истинное продуктовое мышление – исследование природы самой проблемы ещё до того, как она вообще была сформулирована.
Потому что каждое взаимодействие существует в более широком контексте целей пользователя, его психо-эмоциональных состояний, наложенных и отражающихся в ограничениях продукта (и продакта ), которые вызывают у пользователя ответную реакцию.
Точки входа и выхода:
1. Какие это пользователи?
2. При каких условиях они начинают взаимодействие?
3. Какие состояния пользователя существуют в них до него?
4. Как, в какой момент и за счёт чего механика и функция продукта меняет поведение такого пользователя?
5. Что происходит после взаимодействия?
6. Какие последствия и состояния могут возникать ещё?
7. Что, в какой момент и за счёт чего определяет эти последствия?
Точка, где рождается формулировка состояния пользователя и есть точка сборки любой гипотезы, фичи и Систем.
Главные ответы начинают появляться с пониманием того, какой паттерн воспроизводит эту ситуацию снова и снова.
Истинное продуктовое мышление – исследование природы самой проблемы ещё до того, как она вообще была сформулирована.
Потому что каждое взаимодействие существует в более широком контексте целей пользователя, его психо-эмоциональных состояний, наложенных и отражающихся в ограничениях продукта (
Точки входа и выхода:
1. Какие это пользователи?
2. При каких условиях они начинают взаимодействие?
3. Какие состояния пользователя существуют в них до него?
4. Как, в какой момент и за счёт чего механика и функция продукта меняет поведение такого пользователя?
5. Что происходит после взаимодействия?
6. Какие последствия и состояния могут возникать ещё?
7. Что, в какой момент и за счёт чего определяет эти последствия?
Системное продуктовое мышление спрашивает о том, почему этот пользователь в этом состоянии вообще оказался в этой точке?
Точка, где рождается формулировка состояния пользователя и есть точка сборки любой гипотезы, фичи и Систем.
Главные ответы начинают появляться с пониманием того, какой паттерн воспроизводит эту ситуацию снова и снова.
Февральский дайджест красным цветом
О, этот ярко-красный свет
– Глиммер продакта
– Закон тревоги Гудхарта
– Управление незримым
– Иллюзия могущества ИИ
– Что поручаем ИИ, а что нет
– Как ИИ может утопить
– Как снизить себестоимость ИИ
– Будущее IT
– Jakob Nielsen's 18 Predictions 2026
– 26 Useful Concepts for 2026
– Смерть задач – их эволюция
– Фибонначи трудозатрат
– Золотые правила интерфейсов
–Product Manger Product builder
– GitHub продакт-менеджера
– Слова, фреймворки, кирпичи
– SaaS = API для ИИ
– Контекст = король для ИИ/продакта
– Фокус внимания – роскошь
– Классификация точек
– Айтишники. Останутся. В Телеге.
♾️ Infinite Moments by Erik Wollo
Упавшая в ночи картина изменилась
О, этот ярко-красный свет
– Глиммер продакта
– Закон тревоги Гудхарта
– Управление незримым
– Иллюзия могущества ИИ
– Что поручаем ИИ, а что нет
– Как ИИ может утопить
– Как снизить себестоимость ИИ
– Будущее IT
– Jakob Nielsen's 18 Predictions 2026
– 26 Useful Concepts for 2026
– Смерть задач – их эволюция
– Фибонначи трудозатрат
– Золотые правила интерфейсов
–
– GitHub продакт-менеджера
– Слова, фреймворки, кирпичи
– SaaS = API для ИИ
– Контекст = король для ИИ/продакта
– Фокус внимания – роскошь
– Классификация точек
– Айтишники. Останутся. В Телеге.
♾️ Infinite Moments by Erik Wollo
Упавшая в ночи картина изменилась
Product Management & AI
🧠 Есть колоссальная разница между ИИ-агентом, который тупо следует инструкциям и ИИ-агентом, который понимает предметную область Наткнулся на интересный плагин для Claude ArsContexta, который строит Zettelkasten базу знаний для ИИ (навыки/систему знаний/продуктовая…
The Company Graph
Когда говорят, что ИИ/человек не может выполнить ту или иную работу, на самом деле говорят, что им "не предоставили весь контекст".
Всё дело всегда в контексте.
И источник проблемы не в том, что контекста не существует (он существует), а в том, что он разбросан повсюду внутри компании.
Поэтому каждой компании и необходим структурированный граф её знаний. Это хранилище всего контекста:
– идеи, гипотезы, фичи с их разбором в разрезе всей истории их жизни, метрик, отзывов пользователей и происходящих изменений-обновлений;
– каждое решение команды с альтернативами и обоснованием (что решали, что решили и почему);
– каждое совещание (извлеченные утверждения, решения, пункты действий и стратегические изменения);
– все, что вы опубликовали, каждую исследовательскую сессию и каждый конкурентный анализ.
Такой граф не только обновляется и улучшается благодаря вам и команде (вместе с ней), но и выполняет свою главную JTBD – помогает команде через ИИ в предоставлении всем правильного контекста.
Невозможность организовывать работу в пространстве знаний – вот, что погубило все старые продуктовые и проектные wiki. Old school Wiki были просто хранилищем. Граф ИИ – тот самый живой менеджер старой корпоративной википедии.
Потому что теперь ИИ не только имеет быстрый доступ к данным, но и:
– замечает, какие данные/спецификации/идеи не синхронизированы с вашей командой или противоречат друг другу;
– накапливая достаточное количество наблюдений, ИИ может предлагать структурные изменения в Системе именно на основе контекста.
То, что произошло с разработкой ПО с помощью Vibe Coding, совсем произойдет и с интеллектуальным трудом и управлением. И если в 2025 год ИИ писал код, то в 2026 году ИИ начнёт менеджерить решения в компаниях через их знания.
Ваш продукт и компания уже является (и всегда был) графом знаний, имея весь необходимый контекст информации и данных о себе.
Вопрос лишь в том:
1) можете ли вы, ваши коллеги итолько потом ИИ их сохранять, чтобы видеть;
2) хотите ли вы, чтобы их видели Те-Кто-Стоят-За-ИИ
Когда говорят, что ИИ/человек не может выполнить ту или иную работу, на самом деле говорят, что им "не предоставили весь контекст".
Всё дело всегда в контексте.
И источник проблемы не в том, что контекста не существует (он существует), а в том, что он разбросан повсюду внутри компании.
Поэтому каждой компании и необходим структурированный граф её знаний. Это хранилище всего контекста:
– идеи, гипотезы, фичи с их разбором в разрезе всей истории их жизни, метрик, отзывов пользователей и происходящих изменений-обновлений;
– каждое решение команды с альтернативами и обоснованием (что решали, что решили и почему);
– каждое совещание (извлеченные утверждения, решения, пункты действий и стратегические изменения);
– все, что вы опубликовали, каждую исследовательскую сессию и каждый конкурентный анализ.
Организация знаний в области и структуру + правильное наименование = ИИ, говорящий на языке вашего продукта о самом себе.
Такой граф не только обновляется и улучшается благодаря вам и команде (вместе с ней), но и выполняет свою главную JTBD – помогает команде через ИИ в предоставлении всем правильного контекста.
Невозможность организовывать работу в пространстве знаний – вот, что погубило все старые продуктовые и проектные wiki. Old school Wiki были просто хранилищем. Граф ИИ – тот самый живой менеджер старой корпоративной википедии.
Потому что теперь ИИ не только имеет быстрый доступ к данным, но и:
– замечает, какие данные/спецификации/идеи не синхронизированы с вашей командой или противоречат друг другу;
– накапливая достаточное количество наблюдений, ИИ может предлагать структурные изменения в Системе именно на основе контекста.
То, что произошло с разработкой ПО с помощью Vibe Coding, совсем произойдет и с интеллектуальным трудом и управлением. И если в 2025 год ИИ писал код, то в 2026 году ИИ начнёт менеджерить решения в компаниях через их знания.
Ваш продукт и компания уже является (и всегда был) графом знаний, имея весь необходимый контекст информации и данных о себе.
Но самые полезные для организации знания находятся не в документах, а в головах людей.
Вопрос лишь в том:
1) можете ли вы, ваши коллеги и
2) хотите ли вы, чтобы их видели Те-Кто-Стоят-За-ИИ
Контекст продакта
Продукт, которым управляет продакт – это система, похожая на стеклянную каплю принца Руперта: чрезвычайно прочная и ярко сияющая. Но надломи её «хвостик» непродуманным решением и она разрушится, обрушив доверие пользователей и похоронив годы работы.
В команде продакта собираются спецы, каждый со своим видением, амбициями и глубокими знаниями. Они подобны алхимикам, которые свято следуют своему сердцу и не всегда готовы подстраиваться под других. Продакт удерживает баланс между их личными убеждениями и целями компании.
А процессы, в которых всё это существует, напоминают головоломку из параллельных реальностей многомерного пространства, в которых официальные регламенты переплетены с негласными договоренностями, корпоративной политикой и всё теми же амбициями, но уже у руководства...
Пост вдохновлен описанием контекста тимлида Евгением Антоновым из Яндекса. Думаю, наше мнение здесь сходится: менеджмент — это адски сложная работа с кучей контекста, которая только со стороны кажется простой.
Продукт, которым управляет продакт – это система, похожая на стеклянную каплю принца Руперта: чрезвычайно прочная и ярко сияющая. Но надломи её «хвостик» непродуманным решением и она разрушится, обрушив доверие пользователей и похоронив годы работы.
В команде продакта собираются спецы, каждый со своим видением, амбициями и глубокими знаниями. Они подобны алхимикам, которые свято следуют своему сердцу и не всегда готовы подстраиваться под других. Продакт удерживает баланс между их личными убеждениями и целями компании.
А процессы, в которых всё это существует, напоминают головоломку из параллельных реальностей многомерного пространства, в которых официальные регламенты переплетены с негласными договоренностями, корпоративной политикой и всё теми же амбициями, но уже у руководства...
Пост вдохновлен описанием контекста тимлида Евгением Антоновым из Яндекса. Думаю, наше мнение здесь сходится: менеджмент — это адски сложная работа с кучей контекста, которая только со стороны кажется простой.
Telegram
Тимлид Очевидность | Евгений Антонов
Контекст тимлида
Недавно записывал один подкаст, где одним из вопросов мы затронули контекст тимлида.
Это полезно понимать как для текущего тимлида в разрезе его нагрузки в настоящий момент, так и для тимлида, который приходит в новую команду/компанию,…
Недавно записывал один подкаст, где одним из вопросов мы затронули контекст тимлида.
Это полезно понимать как для текущего тимлида в разрезе его нагрузки в настоящий момент, так и для тимлида, который приходит в новую команду/компанию,…
Product Management & AI
The Company Graph Когда говорят, что ИИ/человек не может выполнить ту или иную работу, на самом деле говорят, что им "не предоставили весь контекст". Всё дело всегда в контексте. И источник проблемы не в том, что контекста не существует (он существует)…
Решения и действия (с)
Если разложить любую профессию на составляющие то, вы обнаружите одну и ту же повторяющуюся примитивную структуру:
Решения и действия. Всё
Каждая работа, каждый рабочий процесс, каждая профессия, начиная от менеджера до СЕО – это всего лишь уникальная перестановка и комбинация этих двух вещей с разной частотой и амплитудой в зависимости от контекста.
ПО автоматизировало «действенную» часть работы и поглотило действие, но уровень принятия решений остался человеческим, потому что принятие решений требует рассудительности, учёта контекста, терпимости к неопределённости, распознавания образов в неполной информации, креативности и творчества. Для всего этого необходим интеллект (и вкус – прим.). А интеллект раньше не был доступен по запросам из промптов.
Вот почему работники интеллектуального труда чувствовали себя неприкасаемыми. Они не просто кликали мышкой. Они РЕШАЛИ, НА-ЧТО кликать. Но ИИ полностью меняет это.
Подключите ИИ к ПО и данным, и вы замкнёте цикл. Теперь вы можете создавать сущности, которые могут принимать решения и действовать автономно, от начала до конца.
Марк Андреессен однажды сказал, что ПО поглотит мир. Оно поглотило лишь часть работы. Теперь ИИ пришел, чтобы завершить трапезу.
Но, как ни парадоксально, это не убивает рабочие места в сфере разработки ПО и менеджмента, а создаёт бесконечный спрос на них.
Каждый рабочий процесс, который теперь можно автоматизировать, нужно пересоздавать заново.
Здравоохранение, юриспруденция, логистика, финансы, исследования – каждый из них представляет собой фрактал решений и действий, и каждый теперь является программной проблемой. Весь потенциальный рынок теперь охватывает все существующие рабочие процессы, выполняемые человеком.
Но зверь ИИ дик. Он галлюцинирует, дрейфует, ломается, нуждается в ограничениях, циклах оценки, защите и доверии. Кто-то должен его приручать, подключать к реальным системам, данным, заставляя работать всё это в продакшене.
Поэтому менеджеры и разработчики, которые понимают, что они больше не создают инструменты, а создают системы сущностей, не будут заменены.
Так они эволюционируют в Архитекторов всего, что будет их заменять.
Если разложить любую профессию на составляющие то, вы обнаружите одну и ту же повторяющуюся примитивную структуру:
Решения и действия. Всё
Каждая работа, каждый рабочий процесс, каждая профессия, начиная от менеджера до СЕО – это всего лишь уникальная перестановка и комбинация этих двух вещей с разной частотой и амплитудой в зависимости от контекста.
ПО автоматизировало «действенную» часть работы и поглотило действие, но уровень принятия решений остался человеческим, потому что принятие решений требует рассудительности, учёта контекста, терпимости к неопределённости, распознавания образов в неполной информации, креативности и творчества. Для всего этого необходим интеллект (и вкус – прим.). А интеллект раньше не был доступен по запросам из промптов.
Вот почему работники интеллектуального труда чувствовали себя неприкасаемыми. Они не просто кликали мышкой. Они РЕШАЛИ, НА-ЧТО кликать. Но ИИ полностью меняет это.
ПО – это «действие по триггеру»
ИИ – это «принятие решения по запросу»
Подключите ИИ к ПО и данным, и вы замкнёте цикл. Теперь вы можете создавать сущности, которые могут принимать решения и действовать автономно, от начала до конца.
Марк Андреессен однажды сказал, что ПО поглотит мир. Оно поглотило лишь часть работы. Теперь ИИ пришел, чтобы завершить трапезу.
Но, как ни парадоксально, это не убивает рабочие места в сфере разработки ПО и менеджмента, а создаёт бесконечный спрос на них.
Каждый рабочий процесс, который теперь можно автоматизировать, нужно пересоздавать заново.
Здравоохранение, юриспруденция, логистика, финансы, исследования – каждый из них представляет собой фрактал решений и действий, и каждый теперь является программной проблемой. Весь потенциальный рынок теперь охватывает все существующие рабочие процессы, выполняемые человеком.
Но зверь ИИ дик. Он галлюцинирует, дрейфует, ломается, нуждается в ограничениях, циклах оценки, защите и доверии. Кто-то должен его приручать, подключать к реальным системам, данным, заставляя работать всё это в продакшене.
Поэтому менеджеры и разработчики, которые понимают, что они больше не создают инструменты, а создают системы сущностей, не будут заменены.
Так они эволюционируют в Архитекторов всего, что будет их заменять.
RevenueCat опубликовали ежегодное исследование рынка подписок
Внутри много всего, из интересного:
– Жёсткие пейволлы превосходят фримиум по конверсии: приложения, требующие оплаты сразу, конвертируют пользователей в 5 раз эффективнее, чем модели фримиум (10,7% против 2,1%). Однако в долгосрочной перспективе это преимущество исчезает и спустя год показатели удержания пользователей (retention) для обеих моделей становятся практически идентичными.
– Приложения сокращают пробные периоды вопреки статистике: пробные периоды длительностью от 17 дней обеспечивают конверсию на 70% выше, чем короткие триалы (42,5% против 25,5%). Тем не менее, разработчики продолжают переходить на 3-дневные пробные версии. Сегодня почти половина всех приложений предлагает пробные периоды длительностью не более четырех дней, тем самым, возможно, упуская значительную часть потенциальной конверсии.
– 55% всех отмен 3-дневных пробных периодов происходит в «нулевой день» (день установки приложения). Битва за подписчика выигрывается или проигрывается уже во время первой сессии, что вынуждает разработчиков мгновенно создавать для пользователя тот самый aha-moment.
— Почти треть всех отмен подписок в Google Play происходит не по воле пользователя, а из-за сбоев при списании средств — этот показатель вдвое больше аналогичный показатель в App Store (14%).
– ИИ помогает продавать, но не удерживать: приложения на базе ИИ приносят на 41% больше выручки в пересчёте на одного платящего пользователя, однако отток аудитории в них происходит на 30% быстрее.
Внутри много всего, из интересного:
– Жёсткие пейволлы превосходят фримиум по конверсии: приложения, требующие оплаты сразу, конвертируют пользователей в 5 раз эффективнее, чем модели фримиум (10,7% против 2,1%). Однако в долгосрочной перспективе это преимущество исчезает и спустя год показатели удержания пользователей (retention) для обеих моделей становятся практически идентичными.
– Приложения сокращают пробные периоды вопреки статистике: пробные периоды длительностью от 17 дней обеспечивают конверсию на 70% выше, чем короткие триалы (42,5% против 25,5%). Тем не менее, разработчики продолжают переходить на 3-дневные пробные версии. Сегодня почти половина всех приложений предлагает пробные периоды длительностью не более четырех дней, тем самым, возможно, упуская значительную часть потенциальной конверсии.
– 55% всех отмен 3-дневных пробных периодов происходит в «нулевой день» (день установки приложения). Битва за подписчика выигрывается или проигрывается уже во время первой сессии, что вынуждает разработчиков мгновенно создавать для пользователя тот самый aha-moment.
— Почти треть всех отмен подписок в Google Play происходит не по воле пользователя, а из-за сбоев при списании средств — этот показатель вдвое больше аналогичный показатель в App Store (14%).
– ИИ помогает продавать, но не удерживать: приложения на базе ИИ приносят на 41% больше выручки в пересчёте на одного платящего пользователя, однако отток аудитории в них происходит на 30% быстрее.
Revenuecat
State of Subscription Apps 2026 – RevenueCat
This report provides unique insights into in-app subscription performance, based on the world’s largest subscription app data set.
Product Management & AI
Продакт-менеджмент в СССР Если вы думали, что agile, waterfall, roadmap и project management придумали недавно, то это не так. P.S. На самом деле, очень познавательный фильм.
3,000 лет д.н.э: Проект-менеджмент
1855: Структура ж/д компании
2026: Структура ИИ-агентов
В 1855 году у Нью-Йоркско-Эрийской железнодорожной компании возникла проблема. Железнодорожный транспорт в то время представлял собой крупнейшую в истории страны структуру по сложности своей организации.
Начальнику железной дороги Дэниелу МакКаллуму, который в то время был ведущим мыслителем в области менеджмента, было поручено найти решение. Так он разработал первую в истории современного мира сложную, многоуровневую, древовидную организационную схему (хайрес).
Схема представляет собой дерево, корни которого символизировали президента и совет директоров. Ветви – пять оперативных подразделений и сервисных отделов (ремонт локомотивов, автомобили, телеграф, типографию, а также казначейство и секретариат. Листья же обозначали местных агентов по продаже билетов, грузоперевозкам и экспедированию грузов, подчиненных руководителей, поездные бригады, бригадиров и так далее.
Одной из отличительных особенностей схемы Маккаллума для Эри является то, что она функционирует одновременно и как карта и как организационная схема. Вы можете видеть как структуру всей железной дороги и расположение её подразделений, так и организационную структуру каждого подразделения.
На схеме Маккаллума самые высокопоставленные руководители компании расположены внизу, что противоречит современному пониманию иерархических организационных схем.
Несмотря на достижения МакКаллума в конце XIX века, организационные схемы получили широкое распространение лишь спустя почти сто лет, с появлением бизнес-школ в США. До этого момента организационные схемы появлялись в исторических документах лишь в контексте военных действий.
P.S. Маккаллум просто скопировал всё с языка Кипу эпохи среднего горизонта (периода до инков), в котором цифры завязывали узелками и могли использовать для учёта расходов и доходов. Некоторые из узлов так же, как другие особенности, такие как цвет, представляют нечисловую информацию, которая до сих пор ещё не была расшифрована.
В 2006 году американский исследователь Гари Уртон обнаружил, что в узелках Кипу заложен код, напоминающий двоичную систему. 3,000 лет до нашей эры. Заложен код.
Trello, Jira, Notion, Obsidain? А может, лучшеНастя Кипу?
Всем пятницы и выходных!
1855: Структура ж/д компании
2026: Структура ИИ-агентов
В 1855 году у Нью-Йоркско-Эрийской железнодорожной компании возникла проблема. Железнодорожный транспорт в то время представлял собой крупнейшую в истории страны структуру по сложности своей организации.
Начальнику железной дороги Дэниелу МакКаллуму, который в то время был ведущим мыслителем в области менеджмента, было поручено найти решение. Так он разработал первую в истории современного мира сложную, многоуровневую, древовидную организационную схему (хайрес).
Схема представляет собой дерево, корни которого символизировали президента и совет директоров. Ветви – пять оперативных подразделений и сервисных отделов (ремонт локомотивов, автомобили, телеграф, типографию, а также казначейство и секретариат. Листья же обозначали местных агентов по продаже билетов, грузоперевозкам и экспедированию грузов, подчиненных руководителей, поездные бригады, бригадиров и так далее.
Одной из отличительных особенностей схемы Маккаллума для Эри является то, что она функционирует одновременно и как карта и как организационная схема. Вы можете видеть как структуру всей железной дороги и расположение её подразделений, так и организационную структуру каждого подразделения.
На схеме Маккаллума самые высокопоставленные руководители компании расположены внизу, что противоречит современному пониманию иерархических организационных схем.
Это совершенно другая организация, нежели пирамидальная структура, в которой руководители находятся на вершине, в отличие от этой, где они находятся внизу
Несмотря на достижения МакКаллума в конце XIX века, организационные схемы получили широкое распространение лишь спустя почти сто лет, с появлением бизнес-школ в США. До этого момента организационные схемы появлялись в исторических документах лишь в контексте военных действий.
P.S. Маккаллум просто скопировал всё с языка Кипу эпохи среднего горизонта (периода до инков), в котором цифры завязывали узелками и могли использовать для учёта расходов и доходов. Некоторые из узлов так же, как другие особенности, такие как цвет, представляют нечисловую информацию, которая до сих пор ещё не была расшифрована.
В 2006 году американский исследователь Гари Уртон обнаружил, что в узелках Кипу заложен код, напоминающий двоичную систему. 3,000 лет до нашей эры. Заложен код.
Trello, Jira, Notion, Obsidain? А может, лучше
Всем пятницы и выходных!
Product Management & AI
11 типов ИИ-агентов Существуют различные типы архитектур агентов, специализирующихся на восприятии информации, её анализе, рассуждениях, действиях и абстракциях. 1. GPT — универсальные генераторы текста, отличающиеся беглостью и универсальностью, обученные…
Subagents vs. Agent Teams: в чём между ними разница + 5 паттернов оркестрации
Субагенты – это параллелизм через изоляцию
Субагент – это специализированный экземпляр в Claude/ChatGPT, работающий в собственном изолированном окне контекста. Представьте, что вы выступаете руководителем исследовательской группы. Вы не читаете каждый первоисточник лично, а делегируете конкретные вопросы исследователям, они возвращаются к вам с квинтэссенцией полученных данных, и вы синтезируете всё это в единый, связный результат. Именно так работает механика с субагентами.
Каждый субагент получает:
– Собственный системный промпт, определяющий его специализацию.
– Конкретный набор инструментов, к которым он имеет доступ.
– Чистое, изолированное окно контекста.
– Одну конкретную задачу для выполнения.
По завершении, родительскому процессу возвращается лишь окончательный результат. Не полная цепочка рассуждений и не промежуточные шаги, а только сжатый вывод.
Смысл использования субагентов заключается не только в параллелизме, но и в компрессии. Вы дистиллируете огромный объём поисковой активности в чистый сигнал, не засоряя контекст родительского агента информационным шумом.
Существует одно жесткое ограничение: субагенты не могут взаимодействовать друг с другом напрямую. Все результаты возвращаются к родительскому агенту, который выступает в роли единственного координатора.
Это ограничение не то чтобы, недостаток, а скорее, особенность архитектуры и механики. Оно обеспечивает предсказуемость системы, в котрой вы всегда точно знаете, по каким каналам движется потоки информации и где принимаются решения.
Команды ИИ-агентов – это координация через коммуникацию
Команды агентов представляют собой принципиально иную модель. В то время как субагенты это недолговечные исполнители, которые выполняют конкретную задачу и исчезают, команды агентов – долгоживущие сущности, которые сохраняют своё состояние, напрямую взаимодействуют друг с другом и координируют свои действия посредством общего состояния.
Команда агентов состоит из трёх ключевых компонентов:
– Лидер команды, который координирует работу, распределяет задачи и обобщает результаты.
– Члены команды в лице независимых экземпляров агентов, каждый из которых обладает собственным контекстным окном и работает параллельно с остальными.
– Общий список задач, в котором отслеживается статус каждой задачи, а также зависимости между задачами.
Главное отличие от субагентов заключается в прямом взаимодействии по принципу «от равного к равному». Участники команды могут обмениваться сообщениями, делиться результатами, выявлять препятствия и вести переговоры, не пропуская всё через родительского ИИ-агента руководителя.
Вот как следует подходить к выбору между этими двумя подходами:
1) Суб-агенты работают по принципу «запустил и забыл». Вы ставите им задачу, они её выполняю и отчитываются о результате. Никакого взаимодействия или диалога между агентами. Ни общей памяти, ни сохранения текущего состояния, потому что жизненный цикл каждого суб-агента ограничен рамками одной сессии.
2) Команды ИИ-агентов работают на принципах сотрудничества, сохраняют своё состояние и накапливают контекст с течением времени. Результаты, полученные в процессе выполнения любой задачи, мгновенно становятся доступны ИИ-коллегам по команде.
Используйте суб-агентов, когда ваша работа допускает «параллельное» выполнение: независимые потоки исследований, изучение кодовой базы или поиск информации, когда родительскому агенту требуется лишь краткая сводка результатов.
Используйте команды агентов, когда работа требует постоянного согласования действий: в ситуациях, когда агентам необходимо сверить свои результаты перед переходом к следующему этапу, или когда открытие, сделанное в одном потоке, влияет на дальнейшие действия другого ИИ-потока.
Субагенты – это параллелизм через изоляцию
Субагент – это специализированный экземпляр в Claude/ChatGPT, работающий в собственном изолированном окне контекста. Представьте, что вы выступаете руководителем исследовательской группы. Вы не читаете каждый первоисточник лично, а делегируете конкретные вопросы исследователям, они возвращаются к вам с квинтэссенцией полученных данных, и вы синтезируете всё это в единый, связный результат. Именно так работает механика с субагентами.
Каждый субагент получает:
– Собственный системный промпт, определяющий его специализацию.
– Конкретный набор инструментов, к которым он имеет доступ.
– Чистое, изолированное окно контекста.
– Одну конкретную задачу для выполнения.
По завершении, родительскому процессу возвращается лишь окончательный результат. Не полная цепочка рассуждений и не промежуточные шаги, а только сжатый вывод.
Смысл использования субагентов заключается не только в параллелизме, но и в компрессии. Вы дистиллируете огромный объём поисковой активности в чистый сигнал, не засоряя контекст родительского агента информационным шумом.
Существует одно жесткое ограничение: субагенты не могут взаимодействовать друг с другом напрямую. Все результаты возвращаются к родительскому агенту, который выступает в роли единственного координатора.
Это ограничение не то чтобы, недостаток, а скорее, особенность архитектуры и механики. Оно обеспечивает предсказуемость системы, в котрой вы всегда точно знаете, по каким каналам движется потоки информации и где принимаются решения.
Команды ИИ-агентов – это координация через коммуникацию
Команды агентов представляют собой принципиально иную модель. В то время как субагенты это недолговечные исполнители, которые выполняют конкретную задачу и исчезают, команды агентов – долгоживущие сущности, которые сохраняют своё состояние, напрямую взаимодействуют друг с другом и координируют свои действия посредством общего состояния.
Команда агентов состоит из трёх ключевых компонентов:
– Лидер команды, который координирует работу, распределяет задачи и обобщает результаты.
– Члены команды в лице независимых экземпляров агентов, каждый из которых обладает собственным контекстным окном и работает параллельно с остальными.
– Общий список задач, в котором отслеживается статус каждой задачи, а также зависимости между задачами.
Главное отличие от субагентов заключается в прямом взаимодействии по принципу «от равного к равному». Участники команды могут обмениваться сообщениями, делиться результатами, выявлять препятствия и вести переговоры, не пропуская всё через родительского ИИ-агента руководителя.
Вот как следует подходить к выбору между этими двумя подходами:
1) Суб-агенты работают по принципу «запустил и забыл». Вы ставите им задачу, они её выполняю и отчитываются о результате. Никакого взаимодействия или диалога между агентами. Ни общей памяти, ни сохранения текущего состояния, потому что жизненный цикл каждого суб-агента ограничен рамками одной сессии.
2) Команды ИИ-агентов работают на принципах сотрудничества, сохраняют своё состояние и накапливают контекст с течением времени. Результаты, полученные в процессе выполнения любой задачи, мгновенно становятся доступны ИИ-коллегам по команде.
Используйте суб-агентов, когда ваша работа допускает «параллельное» выполнение: независимые потоки исследований, изучение кодовой базы или поиск информации, когда родительскому агенту требуется лишь краткая сводка результатов.
Используйте команды агентов, когда работа требует постоянного согласования действий: в ситуациях, когда агентам необходимо сверить свои результаты перед переходом к следующему этапу, или когда открытие, сделанное в одном потоке, влияет на дальнейшие действия другого ИИ-потока.
Product Management & AI
Figma says you can't use the word "dev mode", решив стать патентным троллем И если в вашем сервисе используется фраза-режим Dev Mode, то вам стоит переименовать фичу, чтобы не получить иск, как вчера получил досудебное СЕО Loveble, узнав, что Фигма запатентовала…
Как там дела у Фигмы после IPO
1. Тул #1 для UX/UI/дизайна
2. Отказ от поглощения Adobe, компенсация в $1B
3. Скандал вокруг прав на слова dev mode и Config
4. Выход на IPO
4. 6-ти месячный lock-up акций после IPO
5. Акции упали на 80% (на языке биржи они превратились в мусор)
>> Figma сейчас здесь <<
Figma в 2026 году убыточна на -120% (они тратят $220 чтобы заработать $100), а рост выручки замедлился до 30%, что по стандартамкомпаний стартапов её уровня считается весьма слабым результатом.
Для понимания особой печали сотрудников Фигмы – после IPO они стали богатыми на экране, но из-за локапа не могли продать акции и выйти в кеш и наблюдали за падением цены своих акций.
Ко всему прочему, Фигме на хвост наступают конкуренты типа https://penpot.app (рекомендую изучить как альтернативу Фигме, есть self-hosted и тот же MCP для фронтов) и, в целом, вся ИИ индустрия, готовая в любой день выкатить и выкатывающая очереднойуникальный ИИ-тул для создания уникального дизайна и интерфейсов.
Я это всё плавно подвожу к тому, что эпоха SaaS с приходом ИИ ОЧЕНЬ сильно изменилась и рыночек в лице акций самого популярного инструмента для создания интерфейсов тому наглядный пример.
И подкидывая дров в печку AI Free Zone, скажу, что self-hosted продукты в эпоху ИИ рулят по 3 главным причинам:
– с self-hosted вы перестаёте зависеть от хотелок продактов условных Figma/Notion в эпоху ИИ-хайпа;
– с self-hosted вы платите $50/m за машину на DO вместо того, чтобы платить тысячи $ за каждого сотрудника Figma/Notion/Slack за... а за что мы платим им тысячи долларов?
– вы не кормите чужой ИИ своими данными.
И для меня приятным удивлением в этом году было обнаружить https://anytype.io для ведения тасочек и доков. Русские ребята в Швейцарии пилят удобную self-hosted замену Ношена/Обсидиана, в которой есть всё что надо от таск-менеджера и Слака, плюс шифрование ✨ В общем – make it yours.
Возвращаясь к Фигме, предположу, что её всё же выкупят и это будет OpenAI/Claude. Или, может быть, опять Adobe за... миллиард?
1. Тул #1 для UX/UI/дизайна
2. Отказ от поглощения Adobe, компенсация в $1B
3. Скандал вокруг прав на слова dev mode и Config
4. Выход на IPO
4. 6-ти месячный lock-up акций после IPO
5. Акции упали на 80% (на языке биржи они превратились в мусор)
>> Figma сейчас здесь <<
Figma в 2026 году убыточна на -120% (они тратят $220 чтобы заработать $100), а рост выручки замедлился до 30%, что по стандартам
Для понимания особой печали сотрудников Фигмы – после IPO они стали богатыми на экране, но из-за локапа не могли продать акции и выйти в кеш и наблюдали за падением цены своих акций.
Ко всему прочему, Фигме на хвост наступают конкуренты типа https://penpot.app (рекомендую изучить как альтернативу Фигме, есть self-hosted и тот же MCP для фронтов) и, в целом, вся ИИ индустрия, готовая в любой день выкатить и выкатывающая очередной
Я это всё плавно подвожу к тому, что эпоха SaaS с приходом ИИ ОЧЕНЬ сильно изменилась и рыночек в лице акций самого популярного инструмента для создания интерфейсов тому наглядный пример.
И подкидывая дров в печку AI Free Zone, скажу, что self-hosted продукты в эпоху ИИ рулят по 3 главным причинам:
– с self-hosted вы перестаёте зависеть от хотелок продактов условных Figma/Notion в эпоху ИИ-хайпа;
– с self-hosted вы платите $50/m за машину на DO вместо того, чтобы платить тысячи $ за каждого сотрудника Figma/Notion/Slack за... а за что мы платим им тысячи долларов?
– вы не кормите чужой ИИ своими данными.
И для меня приятным удивлением в этом году было обнаружить https://anytype.io для ведения тасочек и доков. Русские ребята в Швейцарии пилят удобную self-hosted замену Ношена/Обсидиана, в которой есть всё что надо от таск-менеджера и Слака, плюс шифрование ✨ В общем – make it yours.
Возвращаясь к Фигме, предположу, что её всё же выкупят и это будет OpenAI/Claude. Или, может быть, опять Adobe за... миллиард?
Product Management & AI
Вчера я проснулась и поняла, то Claude убил мой стартап (c) Ira Bodnar + прогноз рынка маркетинга и дистрибуции в эпоху ИИ Мы создали ИИ-агента, который автоматизирует управление рекламой в Google и Meta. Получилось довольно круто, клиентам это понравилось…
This media is not supported in your browser
VIEW IN TELEGRAM
Каждая фича старого SaaS теперь переосмыслена ИИ
Подумай же и ты об этом:
– Old school SaaS полагался на жёсткие предопределённые правила и данные. Теперь ИИ заменяет их контекстной логикой.
– Сбор данных раньше был в виде статичных форм с фиксированными полями, которые нужно было заполнять руками (своими или пользователей). С ИИ это а) автозаполнение; б) обогащение данных за секунды.
– Workflows раньше строились руками менеджеров и разрабов как цепочки «If-This-Then-That», где люди проектировали каждый шаг. Теперь ты описываешь всё текстом и ИИ собирает и проводит процессы.
– Импорт данных раньше был по жёстким шаблонам CSV, который ломался на любой ошибочной строке и приходилось тратить часы на её поиск и исправление. Теперь ИИ ест данные за минуты.
– Поиск внутри продукта... Помню, на заре 2010-ых был целый сегмент продуктов по поиску внутри продуктов. Где они сейчас, где будут завтра?
– Обучение/документация были протухшей базой знаний FAQ. С ИИ документация жива и актуальна.
– Аналитика была взглядом на месячную задержку данных. ИИ анализирует онлайн.
– Дизайн был делом вкуса и времени. Теперь с ИИ остался только вкус.
–Старый спам уведомлений. ИИ-саммари и группировка.
– Онбординг? ИИ-адаптация!
– API? MCP!
– SaaS теперь источник данных для ИИ.
– Новые фичи = интеграция данных, а не фич
– Новый UI/UX = голос-чат
Подумай же и ты об этом:
– Old school SaaS полагался на жёсткие предопределённые правила и данные. Теперь ИИ заменяет их контекстной логикой.
– Сбор данных раньше был в виде статичных форм с фиксированными полями, которые нужно было заполнять руками (своими или пользователей). С ИИ это а) автозаполнение; б) обогащение данных за секунды.
– Workflows раньше строились руками менеджеров и разрабов как цепочки «If-This-Then-That», где люди проектировали каждый шаг. Теперь ты описываешь всё текстом и ИИ собирает и проводит процессы.
– Импорт данных раньше был по жёстким шаблонам CSV, который ломался на любой ошибочной строке и приходилось тратить часы на её поиск и исправление. Теперь ИИ ест данные за минуты.
– Поиск внутри продукта... Помню, на заре 2010-ых был целый сегмент продуктов по поиску внутри продуктов. Где они сейчас, где будут завтра?
– Обучение/документация были протухшей базой знаний FAQ. С ИИ документация жива и актуальна.
– Аналитика была взглядом на месячную задержку данных. ИИ анализирует онлайн.
– Дизайн был делом вкуса и времени. Теперь с ИИ остался только вкус.
–
– Онбординг? ИИ-адаптация!
– API? MCP!
– SaaS теперь источник данных для ИИ.
– Новые фичи = интеграция данных, а не фич
– Новый UI/UX = голос-чат
Неудобная правда продакт-менеджмента – большинство корпоративных продактов заменят разработчики с ИИ (а не наоборот)
Работа с обратной связью, аналитика тикетов, анализ конкурентов и рынка, продуктовое знание, еженедельные отчётики, внимательно слушание СЕО на совещаниях и всё такое – комон, всё это уже делает ИИ без продактов. Нужен лишь толковый оператор-оркестратор для ИИ.
Толковый оператор – тот кто умеет правильно общаться с ИИ и строить логику процессов для машин. А это всегда разраб, как бы мы не тешили себя иллюзиями вайб-кодинга.
Просто потому, что наш вайб-код не выйдет в прод на миллионы юзеров, он всегда пройдёт через верификатора в лице разраба/СТО.
В корпоративном менеджменте верификация идеи всегда начинается и идёт через руководство, и в корпах продакт часто выступает как номинал идеи и от него требуется толькодвигание тасочек менеджмент процесса разработки идеи, по которому он с этой идеей пойдёт к... разработчикам.
Зная любовь корпораций (и их консультантов) к оптимизации людей и процессов, не удивлюсь, если колесико снова сделает оборот и всё вернётся к тому, с чего начиналось, но с НЕБОЛЬШОЙ поправкой на ИИ: "СЕО ⇔ Разрабы-операторы + ИИ". Дизайн давно в руках ИИ, менеджмент уже вот плавно переходит.
Шансы на рынке остаются у дизайнеров со Вкусом, у продактов с Видением и у разработчиков с ИИ. Всех остальных заменят разработчики с ИИ.
Навеяно новостью о том, что Марк начал использовать ИИ-агента для ответа на вопросы сотрудников, а внутри самой компании персональные агенты стали обязательным условием работы и пунктом на перформанс ревью. И всё это под продолжающейся лавиной массовых сокращений.
– Developers, developers...👏 👩🦲
Работа с обратной связью, аналитика тикетов, анализ конкурентов и рынка, продуктовое знание, еженедельные отчётики, внимательно слушание СЕО на совещаниях и всё такое – комон, всё это уже делает ИИ без продактов. Нужен лишь толковый оператор-оркестратор для ИИ.
Толковый оператор – тот кто умеет правильно общаться с ИИ и строить логику процессов для машин. А это всегда разраб, как бы мы не тешили себя иллюзиями вайб-кодинга.
Просто потому, что наш вайб-код не выйдет в прод на миллионы юзеров, он всегда пройдёт через верификатора в лице разраба/СТО.
В корпоративном менеджменте верификация идеи всегда начинается и идёт через руководство, и в корпах продакт часто выступает как номинал идеи и от него требуется только
Зная любовь корпораций (и их консультантов) к оптимизации людей и процессов, не удивлюсь, если колесико снова сделает оборот и всё вернётся к тому, с чего начиналось, но с НЕБОЛЬШОЙ поправкой на ИИ: "СЕО ⇔ Разрабы-операторы + ИИ". Дизайн давно в руках ИИ, менеджмент уже вот плавно переходит.
Шансы на рынке остаются у дизайнеров со Вкусом, у продактов с Видением и у разработчиков с ИИ. Всех остальных заменят разработчики с ИИ.
Навеяно новостью о том, что Марк начал использовать ИИ-агента для ответа на вопросы сотрудников, а внутри самой компании персональные агенты стали обязательным условием работы и пунктом на перформанс ревью. И всё это под продолжающейся лавиной массовых сокращений.
– Developers, developers...
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Product Management & AI
The Company Graph
Когда говорят, что ИИ/человек не может выполнить ту или иную работу, на самом деле говорят, что им "не предоставили весь контекст".
Всё дело всегда в контексте.
И источник проблемы не в том, что контекста не существует (он существует)…
Когда говорят, что ИИ/человек не может выполнить ту или иную работу, на самом деле говорят, что им "не предоставили весь контекст".
Всё дело всегда в контексте.
И источник проблемы не в том, что контекста не существует (он существует)…
Product Management & AI
Неудобная правда продакт-менеджмента – большинство корпоративных продактов заменят разработчики с ИИ (а не наоборот) Работа с обратной связью, аналитика тикетов, анализ конкурентов и рынка, продуктовое знание, еженедельные отчётики, внимательно слушание СЕО…
Мой старый знакомый не смог пройти мимо и прислал такой коммент к предыдущему посту. С его разрешения, дополняю пост своим ответом и накину на вентилятор свежей аналитеки от a16z (TLDR между строк: сокращайте операционку всех ещё сильнее)
>>>
Привет. Огромное спасибо за столь развернутый комментарий :) Дело в том, что я с ним и согласен и не согласен одновременно. Объясню почему.
Разрабы сейчас и разрабы пару лет назад — совершенно разные специалисты.
Как ты и описал их, большинство из них были долгое время такими: самодовольными, немного ленивыми и, к великому сожалению, неспособными понять и принять смыслов работы для пользователей.
И я думаю, что именно в этом всегда было главное недовольство к разрабам со стороны менеджеров и руководства, а не что-то личное непереносимое (с этим у большинства продактов проблем нет).
Сейчас с ИИ всё меняется (люди и процессы).
Те разрабы, кто оказался не такими и сохранили и пронесли до эпохи ИИ в себе немного пользовательской эмпатии, они поняли, что теперь с ИИ и агентами они могут СОЗДАВАТЬ продукты для пользователей, а не просто писать код для продуктов.
И такие спецы выстраивают вокруг себя на работе целую сеть из ИИ-агентов, которые работают и кодят и проверяют за них (и это видит руководство), либо... они уже пилят свои продукты. Самые хитрые делают и то и другое. А те, кто этого ещё не понял и кто по старинке с самодовольным видом пытается кодить код, их, к сожалению, оптимизируют.
А с корпами просто – в корпах всегда всё было сломано: здравый смысл, процессы, стратегия, псевдо-культура, даже монетизация и та через одно место из-за влияния фондового рынка, инвестиций,кокаинума и оторванного от реальности восприятия мира вокруг (я не говорю уже о том, что мира внутри продукта под названием пользователи и их лояльность для корпы не существует в природе). Так задумано, в этом "дух" корпы.
Всё это было сломано до нас, и с приходом ИИ будет ломаться дальше, больше, сильнее и безумнее. Мы это уже сейчас видим в виде увольнений и сокращений и рандомного перекладывания работы уволенных на плечи кривого ИИ и разных там оркестров.
А кто рулит этим процессом? Кто решает кого нанимать, кого заменять, кого увольнять? Те же, кто раньше нанимал десятки тысяч сотрудников просто "потому что можем себе это позволить".
А значит их самодурство и недальновидность будут иметь место и дальше и будут только лишь усиливаться и одобряться ИИ. Просто потому что ИИ всегда говорит им «да».
И в один момент, ИИ+консультанты скажут "настало время управления с ИИ". и они согласятся, потому что: а) это легко/удобно/контролируемо; б) это выгодно; в) их ИИ не будет заменять (но это не точно, читай меж строк аналитику a16z про оптимизацию уровней + там ещё и статейка хорошая на десерт в ретвите).
А системы всегда стремятся к максимальному упрощению, строгости и автоматизации. Не просто же так в Матрице Архитектор сидит один в комнате 👨🏼💻
Вкус. Видение. ИИ
>>>
Привет. Огромное спасибо за столь развернутый комментарий :) Дело в том, что я с ним и согласен и не согласен одновременно. Объясню почему.
Разрабы сейчас и разрабы пару лет назад — совершенно разные специалисты.
Как ты и описал их, большинство из них были долгое время такими: самодовольными, немного ленивыми и, к великому сожалению, неспособными понять и принять смыслов работы для пользователей.
И я думаю, что именно в этом всегда было главное недовольство к разрабам со стороны менеджеров и руководства, а не что-то личное непереносимое (с этим у большинства продактов проблем нет).
Сейчас с ИИ всё меняется (люди и процессы).
Те разрабы, кто оказался не такими и сохранили и пронесли до эпохи ИИ в себе немного пользовательской эмпатии, они поняли, что теперь с ИИ и агентами они могут СОЗДАВАТЬ продукты для пользователей, а не просто писать код для продуктов.
И такие спецы выстраивают вокруг себя на работе целую сеть из ИИ-агентов, которые работают и кодят и проверяют за них (и это видит руководство), либо... они уже пилят свои продукты. Самые хитрые делают и то и другое. А те, кто этого ещё не понял и кто по старинке с самодовольным видом пытается кодить код, их, к сожалению, оптимизируют.
А с корпами просто – в корпах всегда всё было сломано: здравый смысл, процессы, стратегия, псевдо-культура, даже монетизация и та через одно место из-за влияния фондового рынка, инвестиций,
Всё это было сломано до нас, и с приходом ИИ будет ломаться дальше, больше, сильнее и безумнее. Мы это уже сейчас видим в виде увольнений и сокращений и рандомного перекладывания работы уволенных на плечи кривого ИИ и разных там оркестров.
А кто рулит этим процессом? Кто решает кого нанимать, кого заменять, кого увольнять? Те же, кто раньше нанимал десятки тысяч сотрудников просто "потому что можем себе это позволить".
А значит их самодурство и недальновидность будут иметь место и дальше и будут только лишь усиливаться и одобряться ИИ. Просто потому что ИИ всегда говорит им «да».
И в один момент, ИИ+консультанты скажут "настало время управления с ИИ". и они согласятся, потому что: а) это легко/удобно/контролируемо; б) это выгодно; в) их ИИ не будет заменять (но это не точно, читай меж строк аналитику a16z про оптимизацию уровней + там ещё и статейка хорошая на десерт в ретвите).
А системы всегда стремятся к максимальному упрощению, строгости и автоматизации. Не просто же так в Матрице Архитектор сидит один в комнате 👨🏼💻
Вкус. Видение. ИИ
This media is not supported in your browser
VIEW IN TELEGRAM
Вещи, которые должен уметь игнорировать продакт для сохранения своего внимания, видения и намерения (времени-энергии):
0. 100%-ый перфекционизм
1. Дословные требования пользователей
2. Громкость голосов стейкхолдеров
3. Авторитет "экспертных" мнений
4. Блеск фич и метрик конкурентов
5. Нужда совещаний и ответов
6. Просто срочность
7. Ожидание момента
8. Мнимая определённость планов
9. Запрос на определённости извне
10. Одержимость рационализаций
11. Процесс ради процесса
12. Потребность в одобрении командой
13. Стремление к консенсусу со всем(и)
14. Шёпот. Шум рыночного хайпа
15. Страх от признания пустых работ
16. Чувство вины за фичи (те работы)
17. Сравнение себя с другими
18. Свой собственный "успех"
Безупречность не про идеальность
0. 100%-ый перфекционизм
1. Дословные требования пользователей
2. Громкость голосов стейкхолдеров
3. Авторитет "экспертных" мнений
4. Блеск фич и метрик конкурентов
5. Нужда совещаний и ответов
6. Просто срочность
7. Ожидание момента
8. Мнимая определённость планов
9. Запрос на определённости извне
10. Одержимость рационализаций
11. Процесс ради процесса
12. Потребность в одобрении командой
13. Стремление к консенсусу со всем(и)
14. Шёпот. Шум рыночного хайпа
15. Страх от признания пустых работ
16. Чувство вины за фичи (те работы)
17. Сравнение себя с другими
18. Свой собственный "успех"
Безупречность не про идеальность
Product Management & AI
Каждая фича старого SaaS теперь переосмыслена ИИ Подумай же и ты об этом: – Old school SaaS полагался на жёсткие предопределённые правила и данные. Теперь ИИ заменяет их контекстной логикой. – Сбор данных раньше был в виде статичных форм с фиксированными…
This media is not supported in your browser
VIEW IN TELEGRAM
Бэдтрип эпохи Web 2.0
Поймал вчера короткий бэдтрип в попытке начать работать с чистым Wordpress. В сознании сразу пронеслась куча воспоминаний из эпохи web 2.0, когда всё делалось руками: от контента до кода. А бэдтрип возник даже не из-за боязни чистого листа или сложности с кодом, нет (нет ничего прекраснее чем чистый белый лист).
Устанавливая нулёвую сборку WP, вдруг осознал (вспомнил), что большинство продуктов эпохи 2.0 характерны одним свойством – структурностью и ограниченностью во всём: от кода до механик работы с данными, которая лишала нас, как пользователей, той «магии» ПО и данных, на которую, на самом деле, они способны. И нам приходилось всё допиливать руками разработчиков, постоянно выслушивая сначала про те или иные технические ограничения тех времён, а после них и просто про ограничения времени.
(моя любовь в этом плане к Wordpress была безгранична, как и безгранично кол-во комьюнити плагинов к этому чудесному движку).
Традиционным продуктам 2.0 не хватало внутренней и внешней свободы механик и данных и UGC, которую даёт (и так жаждет) ИИ.
Мы, как пользователи, это всегда чувствовали, мы были недовольны этим, но нам приходилось пользоваться старыми продуктами, потому что не было ИИ.
А бэдтрип возник из-за того, что даже спустя 20 лет, в Wordpress до сих пор нет решения, которое бы позволяло продавать статьи на сайте поштучно (я не говорю уже даже про то, чтобы их можно было поштучно сдавать для чтения в аренду).
...Основная бизнес-модель контента.
Миллионное комьюнити.
20+ лет развития продукта.
Решений нет...
...ИИ написала плагин с моих слов за 5 минут.
Во Вселенной, где единственной постоянной являетсяХаос перемены, метод проверки гипотез и создания продуктов должен быть настолько быстрым, что на это должна уходить всего одна минута/один час/один день/неделя.
Проверка идей, развитие продуктов и написание кода в стиле 2.0 – это не просто медленно. Это, blyat, очень медленно.
(Фух, отпустило)
Поймал вчера короткий бэдтрип в попытке начать работать с чистым Wordpress. В сознании сразу пронеслась куча воспоминаний из эпохи web 2.0, когда всё делалось руками: от контента до кода. А бэдтрип возник даже не из-за боязни чистого листа или сложности с кодом, нет (нет ничего прекраснее чем чистый белый лист).
Устанавливая нулёвую сборку WP, вдруг осознал (вспомнил), что большинство продуктов эпохи 2.0 характерны одним свойством – структурностью и ограниченностью во всём: от кода до механик работы с данными, которая лишала нас, как пользователей, той «магии» ПО и данных, на которую, на самом деле, они способны. И нам приходилось всё допиливать руками разработчиков, постоянно выслушивая сначала про те или иные технические ограничения тех времён, а после них и просто про ограничения времени.
(моя любовь в этом плане к Wordpress была безгранична, как и безгранично кол-во комьюнити плагинов к этому чудесному движку).
Традиционным продуктам 2.0 не хватало внутренней и внешней свободы механик и данных и UGC, которую даёт (и так жаждет) ИИ.
Мы, как пользователи, это всегда чувствовали, мы были недовольны этим, но нам приходилось пользоваться старыми продуктами, потому что не было ИИ.
А бэдтрип возник из-за того, что даже спустя 20 лет, в Wordpress до сих пор нет решения, которое бы позволяло продавать статьи на сайте поштучно (я не говорю уже даже про то, чтобы их можно было поштучно сдавать для чтения в аренду).
...Основная бизнес-модель контента.
Миллионное комьюнити.
20+ лет развития продукта.
Решений нет...
...ИИ написала плагин с моих слов за 5 минут.
Во Вселенной, где единственной постоянной является
Проверка идей, развитие продуктов и написание кода в стиле 2.0 – это не просто медленно. Это, blyat, очень медленно.
(Фух, отпустило)
Конференции про лидерство смотрю уже не первый год, субботняя Dream → Teamlead на прошлой неделе не стала исключением. Больше всего зашли два доклада: про стресс и лидерство.
Из интересного:
Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure, объяснил, что тимлидер(ство) – это сначала про стек навыков по управлению собой, и только потом про управление командой. При этом нужно комбинировать в себе все виды лидерства в зависимости от КОН-ТЕ-КСТА. Контекст – король. Таким образом, научившись управлять собой, научишься тимлидству как профессии.
Еще была интересная мысль о том, что в стрессе типы (грани) тимлида обостряются и либо эволюционируют, либо регрессируют, поэтому стрессом нужно уметь управлять. И иначе, стресс начнёт управлять тобой, а потом и всей командой.
Поэтому, лидер, застрявший в одном стиле управления, скорее всего провалится (и утащит за собой команду). Стресс лишь приблизит неизбежное.
Полезный совет – рост тимлида часто происходит по фидбеку команды. Спросите коллег: а) что они в тебе как лидере видят; б) чего им в тебе не хватает.
Про ИИ тоже говорили: продуктивность с ИИ растёт быстрее качества, поэтому непродуманный ИИ в процессах не только не помогает, но и создаёт дополнительное узкое горлышко в виде растущего объёма верификации и ответственности выросшего благодаря ИИ количеству результата работы.
Из интересного:
Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure, объяснил, что тимлидер(ство) – это сначала про стек навыков по управлению собой, и только потом про управление командой. При этом нужно комбинировать в себе все виды лидерства в зависимости от КОН-ТЕ-КСТА. Контекст – король. Таким образом, научившись управлять собой, научишься тимлидству как профессии.
Еще была интересная мысль о том, что в стрессе типы (грани) тимлида обостряются и либо эволюционируют, либо регрессируют, поэтому стрессом нужно уметь управлять. И иначе, стресс начнёт управлять тобой, а потом и всей командой.
Всё втекает и вытекает из другого. И в этом вся сложность и простота одновременно ☯️
Поэтому, лидер, застрявший в одном стиле управления, скорее всего провалится (и утащит за собой команду). Стресс лишь приблизит неизбежное.
Полезный совет – рост тимлида часто происходит по фидбеку команды. Спросите коллег: а) что они в тебе как лидере видят; б) чего им в тебе не хватает.
Про ИИ тоже говорили: продуктивность с ИИ растёт быстрее качества, поэтому непродуманный ИИ в процессах не только не помогает, но и создаёт дополнительное узкое горлышко в виде растущего объёма верификации и ответственности выросшего благодаря ИИ количеству результата работы.
Product Management & AI
Конференции про лидерство смотрю уже не первый год, субботняя Dream → Teamlead на прошлой неделе не стала исключением. Больше всего зашли два доклада: про стресс и лидерство. Из интересного: Евгений Антонов, ведущий технический менеджер проектов в Yandex…
👆 P.S. И да, о чём бы с удовольствием подискутировал про стресс в айтишке с молекулярным биологом Сергеем Харитоновым:
– Яркое холодное освещение ночью и блэкаут днём – самое плохое решение для "ночных тимлидов" какое может быть, и такой подход лишь усугубляет негативные ощущения, что, собственно, Сергей и подтвердил в конце – оно не работает на долгосрок (в отличии от тимлидов).
Долгосрок – темнота и свеча рядом с экраном/ноутом (само собой, яркость которого ночью на минимум), блики света от огня на стене которой идеально заменяют естественный(!) свет Солнца, которого нет ночью и успокаивают глаза-мозг. Просто потому что в свете Солнца много есть чего. Оно же есть в огне. Смотри в огонь, будь сам огнём, Огонь-Внутри-Тебя 🔥
– Днём можно спать при свете Солнца и блэкаут-шторы не нужны (читай – они только вредят). Спи днём также, как спишь ночью – с обычной шторой или без. Все эти попытки обмануть себя приводят лишь к одному – мозг-глаза-сознание всё равно знают, что их пытаются обмануть. Их не обманешь.
– Спать можно дважды в сутки по 4 часа без вреда для здоровья. Говорю об этом как практик с 10+ летним опытом стабильной работы с полуночи и до 8 утра. Со здоровьем всё в порядке (тьфу х3). Спать 10+ часов я тоже могу и люблю, при правильном мышлении и подходе, переключение между режимами вообще не чувствуется, потому что режимов-не-существует.
– Пить магний вредно, как и пить любые витамины. Пить витамины – это дисбаланс. Лучше витамины есть органикой через постоянно полезную пищу и пить через травы/ягоды/коренья/этовсё, качая то самое "нейробиотическое чувство" (но я называю это по-другому).
А магний лучше всего усваивается нервами через кожу водой в ванне с английской солью, которая его и содержит (рекомендую миксовать с розовой гималайской). Добавь темноту и снова огонь, и вот уже эффект Х10.
– Физические тренировки и мышцы – очень тонкая тема в контексте разгрузки ими от стресса. Знаю много случаев, когда под воздействием стресса физическое переходило в фанатическое и люди гробили своё пошатнувшееся здоровье ещё больше с мыслью "сожгу стресс спортом". В итоге, выгорание и стресс уходят на более глубокий ментально-физиологический уровень и бетонируются там тренировками.
Ключ в медитации, дыхании и фасциях. Баланс и Тишина внутри тебя 😌
– Яркое холодное освещение ночью и блэкаут днём – самое плохое решение для "ночных тимлидов" какое может быть, и такой подход лишь усугубляет негативные ощущения, что, собственно, Сергей и подтвердил в конце – оно не работает на долгосрок (в отличии от тимлидов).
Долгосрок – темнота и свеча рядом с экраном/ноутом (само собой, яркость которого ночью на минимум), блики света от огня на стене которой идеально заменяют естественный(!) свет Солнца, которого нет ночью и успокаивают глаза-мозг. Просто потому что в свете Солнца много есть чего. Оно же есть в огне. Смотри в огонь, будь сам огнём, Огонь-Внутри-Тебя 🔥
– Днём можно спать при свете Солнца и блэкаут-шторы не нужны (читай – они только вредят). Спи днём также, как спишь ночью – с обычной шторой или без. Все эти попытки обмануть себя приводят лишь к одному – мозг-глаза-сознание всё равно знают, что их пытаются обмануть. Их не обманешь.
– Спать можно дважды в сутки по 4 часа без вреда для здоровья. Говорю об этом как практик с 10+ летним опытом стабильной работы с полуночи и до 8 утра. Со здоровьем всё в порядке (тьфу х3). Спать 10+ часов я тоже могу и люблю, при правильном мышлении и подходе, переключение между режимами вообще не чувствуется, потому что режимов-не-существует.
– Пить магний вредно, как и пить любые витамины. Пить витамины – это дисбаланс. Лучше витамины есть органикой через постоянно полезную пищу и пить через травы/ягоды/коренья/этовсё, качая то самое "нейробиотическое чувство" (но я называю это по-другому).
А магний лучше всего усваивается нервами через кожу водой в ванне с английской солью, которая его и содержит (рекомендую миксовать с розовой гималайской). Добавь темноту и снова огонь, и вот уже эффект Х10.
– Физические тренировки и мышцы – очень тонкая тема в контексте разгрузки ими от стресса. Знаю много случаев, когда под воздействием стресса физическое переходило в фанатическое и люди гробили своё пошатнувшееся здоровье ещё больше с мыслью "сожгу стресс спортом". В итоге, выгорание и стресс уходят на более глубокий ментально-физиологический уровень и бетонируются там тренировками.
Ключ в медитации, дыхании и фасциях. Баланс и Тишина внутри тебя 😌
This media is not supported in your browser
VIEW IN TELEGRAM
Ты слышишь? Дайджест мартовских постов перетекает в воздухе деревьев
– Почему время то летит, то ползёт
– Почему сильные команды посредственны
– Почему все встречи назначаются на час
– Что продакту включить в игнор
– Три уровня познания исследований
– Инкрементальность продуктовой разработки
– Обзор любого рынка 360
– The Company Graph
– Google Search Console для исследований
– 800 инструментов для исследований
– CIRCLES для продуктовых кейсов
– Джуны не нужны
– GitHub для продакта
– Продакты-решалы
– Когда менеджер должен вмешиваться
– Как понятно объяснять свои мысли
– Даём обратную связь по BOFF
– Насмотренность — ловушка
– Subagents vs. Agent Teams
– Что происходит с AI от a16z
– Грамотность пользователей с ИИ
– ИИ лишь увеличивает количество работы
– Ваш проект умрёт не из-за разработки
– Смерть отслеживания задач
– О ясности и сложности
– Идея множественности «Я»
🏔️ Gorillaz - The Mountain, The Moon Cave and The Sad God
– Почему время то летит, то ползёт
– Почему сильные команды посредственны
– Почему все встречи назначаются на час
– Что продакту включить в игнор
– Три уровня познания исследований
– Инкрементальность продуктовой разработки
– Обзор любого рынка 360
– The Company Graph
– Google Search Console для исследований
– 800 инструментов для исследований
– CIRCLES для продуктовых кейсов
– Джуны не нужны
– GitHub для продакта
– Продакты-решалы
– Когда менеджер должен вмешиваться
– Как понятно объяснять свои мысли
– Даём обратную связь по BOFF
– Насмотренность — ловушка
– Subagents vs. Agent Teams
– Что происходит с AI от a16z
– Грамотность пользователей с ИИ
– ИИ лишь увеличивает количество работы
– Ваш проект умрёт не из-за разработки
– Смерть отслеживания задач
– О ясности и сложности
– Идея множественности «Я»
🏔️ Gorillaz - The Mountain, The Moon Cave and The Sad God