Курдюмов Дмитрий | Product operations

Capability Maturity Model (CMM), или модель зрелости процессов. Представьте две продуктовые команды. Одна с каждым спринтом работает быстрее и предсказуемее: риски просчитываются заранее, качество растёт. Вторая - бесконечно чинит баги и срывает дедлайны. Команды сильные, менеджеры опытные. Так в чём разница? Обычно - в уровне зрелости процессов. CMM описывает это как лестницу из пяти уровней: от хаоса до системы, которая постоянно самооптимизируется. 🔺Начальный — хаос Процессов нет, всё держится на отдельных «супергероях». Каждый проект уникален, половина времени уходит на исправление ошибок, результаты непредсказуемы. 🔺Управляемый Появляются базовые стандарты: шаблоны ТЗ, чек-листы релизов. Результаты более стабильны, но многое всё ещё зависит от опыта команды. 🔺Определённый Процессы описаны и стандартизированы. Есть единый playbook, команда работает по понятным процедурам. Предсказуемость высокая. 🔺Управляемый количественно Процессами начинают управлять метрики: velocity, bug rate, time-to-market. Появляются дашборды, прогнозирование и data-driven решения. 🔺Оптимизирующийся Процессы постоянно улучшаются. A/B-тесты, эксперименты, автоматизация, небольшие, но регулярные улучшения метрик. Почему это важно? Когда компании начинают искать причины проблем,искать решения, внедрять AI и прочее, они часто забывают задать главный вопрос: на каком уровне зрелости процессов они находятся сейчас. Если этот уровень не учитывать - можно вложиться в технологии и не получить ожидаемого эффекта. Официальный сайт модели https://cmmiinstitute.com/cmmi

Во всем виноват ИИ? Как думаете?😀

Синдром дойной коровы. Или как сбалансировать портфель продуктов. Я давно работаю с компаниями по выстраиванию модели управления продуктами. И когда подхожу к анализу портфеля продуктов часто вижу следующую картину: У компании есть флагманский продукт. Он живёт, стабильно зарабатывает, не сильно растёт, но и не падает. При этом компания основные усилия и ресурсы пускает на то чтобы поддерживать и развивать этот продукт. Но при этом в портфеле нет новых ставок. Нет попыток запускать новые продукты или бизнес-модели, которые также когда станут флагманскими при смерти старого. Это и есть синдром дойной коровы. Поэтому хороший портфель должен состоять не только из проектов по развитию существующего продукта, но и трансформации текущего и запуска новых. Практически это выглядит так: Около 70% усилий и инвестиций - в core cash. Это то, что кормит сейчас: удержание, LTV, повышение маржи, точечные улучшения флагманского продукта. Около 20% - в Adjacency. Соседние сегменты, новые кейсы на той же платформе, расширение модели монетизации. Это аккуратный рост на базе уже существующей инфраструктуры и компетенций. И 10% - в Options. Ставки с высокой неопределённостью: быстрые эксперименты, прототипы, MVP, проверка новых бизнес-моделей. Часть из них «умрёт», и это нормально. Задача - найти следующий Core. Портфель - это не список продуктов. Это система распределения управленческого внимания и капитала между «сегодня» и «завтра».

Гонка ИИ моделей закончилась, начинается новая гонка - ИИ агентов🏎️ Последняя новость о том что Питер Штайнбергер, создатель OpenClaw, переходит в штат OpenAI по сути является большим сигналом к тому куда начинает двигаться рынок ИИ и какая логика конкуренции формируется. Мы постепенно уходим от гонки «у кого модель умнее» к вопросу «чей агент реально делает работу и кому можно доверить доступы». OpenClaw интересен тем, что это не чат в браузере. Это агент, который находится рядом с пользователем: работает с почтой, календарём, мессенджерами, инициирует действия, а не просто отвечает на запросы. Он встроен в поток работы. Установил → подключил доступы → агент действует в твоих каналах. И здесь очень хорошо прослеживается следующий шаг - объединение разных типов агентов в единую платформу с общей памятью, ролями и правами доступа, - начиная от рабочих задач, заканчивая личными: от написания кода до администрирования твоего календаря или планирования отпуска. И здесь ключевой вопрос - доверие и безопасность. Чем глубже агент интегрирован в процессы и данные, тем выше цена ошибки. Конкуренция будет идти не только за интеллект, но и за governance, контроль и предсказуемость действий. Для меня это главный сдвиг: AI перестаёт быть инструментом для общения и становится инструментом для решения реальных задач. А вы бы доверили агенту доступ к своей почте и календарю, если он действительно экономит вам несколько часов в неделю? Или пока барьер доверия слишком высок?

Как мы сократили 30% инициатив и высвободили десятки миллионов рублей - без увольнений. Несколько лет назад я работал с компанией, которая упёрлась в потолок. Новых людей нанимать нельзя, бюджет не растёт, а задач становится только больше. Руководство всерьёз обсуждало сокращение расходов через ФОТ. При этом ощущение было странное: все заняты, встречи идут, проекты запускаются — но стратегического сдвига нет. И ощущение постоянной нехватки ресурсов, знакомо? Главный вопрос звучал просто: откуда взять ресурс на новое, если всё уже загружено? Мы начали не с людей. Мы начали с портфеля проектов. И первое открытие было болезненным: никто не видел полной картины. Проекты существовали в презентациях, в Jira, в Excel, в головах руководителей. Часть инициатив была «обязательной», часть — историческим наследием, часть - личными договорённостями. Некоторые команды делали проекты, о которых топ-уровень вообще не знал. Поэтому портфель собирали и сверху вниз, и снизу вверх. Это заняло время, но именно здесь были зарыты деньги. Когда мы наконец свели всё в один список, стало очевидно: компания финансирует больше инициатив, чем способна качественно переварить. Дальше мы прошли три шага. Шаг 1 - собрать реальную картину. Один консолидированный список всех инициатив без исключений: стратегических, операционных, “обязательных”, исторических. Уже на этом этапе стало видно, сколько ресурсов съедает инерция и сколько проектов живут просто потому, что их когда-то запустили. Шаг 2 — жёсткая проверка на смысл. Каждый проект должен был ответить на два вопроса: какую стратегическую цель он двигает и какой измеримый эффект даёт - в выручке, затратах или риске. Если вместо ответа звучало «это важно» или «мы всегда это делали», — инициатива попадала в зону паузы. В этот момент стало понятно, сколько бюджета заморожено в управленческой иллюзии прогресса. Шаг 3 — остановить, а не “чуть замедлить”. Мы закрыли и заморозили около 30% инициатив. Не оптимизировали, не растянули сроки, а именно остановили. Освободившихся сильных людей перевели на приоритетные направления. Концентрация резко выросла. Скорость принятия решений увеличилась. И главное - появилась энергия. В итоге компания не только высвободила десятки миллионов рублей операционного бюджета, но и смогла профинансировать новые стратегические проекты без расширения штата. Самое интересное - уровень стресса внутри снизился. Люди наконец начали делать главное, а не всё подряд. С тех пор я уверен: когда бизнесу нужно ускориться или сократить расходы, смотреть нужно не в сторону людей, а в первую очередь в сторону портфеля. Вопрос не в том, что ещё запустить. Вопрос в том, что вы готовы остановить. Какие 1–3 проекта вы бы отменили уже сегодня, чтобы освободить ресурс под главное?

🤖 ИИ не делает команду сильнее. Он делает сильнее сильных - и слабее слабых Google провел исследование, как команды работают с AI, и вывод очень приземлённый: AI - это множитель. Если сотрудник делает «на коленке» и не включает голову - с ИИ он просто начнёт производить больше ошибок что и раньше. А вот сильный специалист с AI ускоряется кратно: быстрее думает, быстрее проверяет гипотезы, быстрее выдаёт результат. К чему это ведёт: 📌 Сильные будут стоить дороже 📌 Людей в командах станет меньше 📌 Вес каждого сотрудника для бизнеса вырастет Значит, менеджеру и фаундеру ещё важнее уметь работать с сильными. И начинать придётся с себя: ✅ быть человеком, с кем хотят работать ✅ иметь нетворк, чтобы быстро “дотягиваться” до нужных спецов ✅ создавать условия, где хочется остаться ✅ строить культуру результата + человечности ✅ ставить себя и других на роли по сильным сторонам, а не куда придется

Одна из самых дорогих ошибок в создании продукта - оптимизировать всё подряд, не понимая, где реальное ограничение системы Часто в своем опыте наблюдаю одно и тоже - команды внедряют новые подходы и практики SAFe, OKR, JTBD, подключают AI-ассистентов, процессов становится больше, активностей больше - а продуктовые метрики растут медленно или не растут вовсе. Почему? Потому что никто не знает, где сейчас бутылочное горлышко системы. Создание продукта - это не набор практик и процессов. Это поток создания ценности. Через призму Теории ограничений Голдратта создание продукта - это сквозной поток: гипотеза → прототип → MVP → продукт → ценность → деньги. И в каждый момент времени этот поток ограничен. Это может быть перегруженный продакт-менеджер, discovery, не успевающее за delivery, архитектура, тормозящая эксперименты, зависимость от одного стейкхолдера или команда, перегруженная «срочными» задачами. В 90% случаев системная проблема - это следствие одного ограничения. Главный вопрос менеджера Не «что нам улучшить?», а: где сейчас ограничение потока создания ценности? Пока ответа нет, фреймворки усиливают хаос, метрики не дают понимания, что делать дальше, а команды работают больше, но не быстрее. Как применять Теорию ограничений 1️⃣ Найти ограничение - смотреть не на загрузку людей, а на очереди и ожидание: где идеи лежат дольше всего, где решения зависят от одного человека, где работа «готова», но не движется дальше. Ограничение - там, где тормозится поток. 2️⃣ Подчинить систему скорости ограничения. Если узкое место - продакт, сокращаем входящий поток. Если ограничение в discovery - не разгоняем delivery. Большинство команд делают наоборот. 3️⃣ Усилить ограничение точечно - снять часть решений, упростить приоритизацию, убрать лишние согласования. Инвестировать не «везде», а туда, где система реально ограничена. 4️⃣ Проверить, не сместилось ли ограничение. После изменений оно всегда переезжает. Зрелость - это постоянная работа с потоком, а не разовая оптимизация. Итог Продукт буксует не потому, что команда слабая, а потому что менеджер системы не видит её главное ограничение. Пока бутылочное горлышко не найдено, любой подход будет работать вполсилы. Вы знаете, где сейчас ограничение в вашем потоке ценности? Делитесь в комментариях

Месяц вайбкодинга c Сlaude Code. Я больше не делаю руками то, что можно автоматизировать За последний месяц Claude Code стал для меня ежедневной рабочей средой. Я его использую чтобы автоматизировать свою ежедневную рутину и операции, собираю системы, которые по событию запускают процесс и возвращают мне результат. И насколько ускорились мои процессы - словами не передать. Если раньше, чтобы сделать лендинг, нужен был дизайнер, нужно было продумать структуру, тексты, собрать макет, согласовать. Месяц - это минимальный горизонт, если делать нормально. Сейчас при хорошем промпте и правильно настроенном контексте я собираю лендинг за 2 минуты, делаю несколько корректировок и выкладываю в прод. Если раньше, чтобы почистить компьютер, мне нужно было вручную проверять папки, искать мусор, вспоминать, что можно удалить, то сейчас - один промпт, план действий, и я закрываю задачу в пару кликов. Что я реально сделал за последний месяц: 🚀 4 лендинга. Быстрее, чем раньше делался один. 🤖 SMM-агент. Не “пишет посты”, а работает как отдельная роль: с контекстом, стилем, памятью и пониманием задач. 📬 Персональный ассистент, который анализирует переписку, сам готовит follow-up’ы, присылает важные письма из почты чтобы не пропустить. Фактически закрывает весь ручной хвост коммуникаций. 📊 Система алертинга по сжиганию трафика. Когда у тебя подключено несколько LLM, лимиты могут улетать бесконтрольно. Это была вынужденная, но очень показательная автоматизация. 🧠 И сейчас я собираю полноценную систему ассистентов, которая шаг за шагом забирает мои ручные операции: контроль, напоминания, подготовку решений, рутину. Через несколько месяцев это уже будет не набор инструментов, а полноценная цифровая команда. И главный вопрос даже не в технологиях. А в том, насколько быстро один человек сможет собирать вокруг себя “штат” из цифровых специалистов. Мы только начинаем понимать масштаб.

😀

Почему любая «стратегия роста» ломается без культуры экспериментов На своём опыте я много раз видел одну и ту же картину: Компания тратит месяцы и серьёзные ресурсы на стратегическое планирование: воркшопы, фасилитация, OKR, красивые слайды. Стратегию защищают, согласуют, раскатывают по командам. А дальше она остаётся в презентациях. Через пару месяцев рынок меняется, приоритеты плывут, решения принимаются ситуативно - и стратегию уже никто не корректирует. Про неё просто перестают помнить. Проблема не в качестве стратегии. Проблема в отсутствии механизма, который заставляет её жить. Устойчивый рост дают не документы, а growth engine: регулярные эксперименты, быстрые управленческие решения и дисциплина вокруг метрик, а не мнений. Это и есть культура роста - привычка проверять гипотезы, признавать ошибки и без сожалений отключать то, что не работает. Практика на 30 дней, чтобы запустить двигатель роста. 1️⃣ Единый backlog гипотез. Соберите все идеи в одном месте и приоритизируйте через ICE / RICE. 2️⃣ North Star + дерево метрик. Зафиксируйте North Star Metric и разложите её на драйверы. 3️⃣ Ритуал growth review. Раз в неделю: что тестировали, чему научились, что конкретно меняем в продукте или воронке на следующей неделе. Не отчёт, а управленческий цикл обучения. Стратегия может устареть. А культура «учимся быстрее конкурентов» превращает рост в повторяемый процесс, а не разовую удачу.

Друзья, тут есть сильные продакты которые запускали продукты с нуля? Важнен сильный бизнес анализ и продуктовые скиллы, способность формировать простые решения решающие проблему, наличие опыта и кейсов. Вакансия по ссылке Предложение в VK.

Чтобы трансформация не была очередной новомодной инициативой, начинайте всегда с важных вопросов: 1. Какие проблемы бизнеса сейчас есть? 2. Каких целей хотим достичь? 3. Какие инициативы мы сформируем для оптимизации? 4. Какой план? Ответы на эти вопросы - ваш компас. И только когда он есть, можно смотреть на карту технологий и спрашивать не «Куда можно внедрить ИИ?», а «Какой инструмент поможет нам быстрее и лучше прийти к цели?». Это и есть разница между «внедрением ради внедрения» и осмысленной трансформацией.

Я заменил SMM-специалиста с бюджетом 30 000 ₽ в месяц своим ИИ-агентом Недавно я автоматизировал создание контента с помощью ИИ-агента, которого собрал сам. И здесь ИИ - не автор. ИИ - мои цифровые руки. Что делает ИИ (исполняющий слой): - Ищет и предлагает идеи - анализирует контекст, тренды и аудиторию. - Анализирует конкурентов - показывает, какие темы и углы уже заняты. - Пишет черновой текст - в рамках моего стиля и заданных ограничений. - Структурирует мысль - превращает набор тезисов в связный текст. - Публикует по расписанию - выполняет техническую часть. Что делаю я (управляющий слой): - Выбираю или отвергаю идеи - задаю стратегический вектор. - Формулирую рамки и цель - зачем этот текст и для кого. - Правлю и усиливаю - добавляю экспертизу, опыт и нюансы. В результате я перестал тратить часы на рутину и платить за функцию, которая по своей природе хорошо масштабируется через ИИ. Для меня это и есть нормальная модель работы с ИИ: человек - режиссёр и владелец смысла, ИИ - исполнитель, ассистент и ускоритель. Технически своего агента я собрал в Cursor с помощью Claude Code.

Почему слепое ускорение Delivery ускоряет деградацию продукта и как этого избежать Последние годы стало трендом оптимизировать time to market. Но часто из за неправильной интерпретации такая цель начинает губительно влиять на развитие бизнеса. Компания может выпускать больше и быстрее - и при этом: - не решать реальные проблемы клиентов, - не создавать бизнес-эффект, - масштабировать неверные решения. Вместо этого стоит комплексно посмотреть на то, как компания управляет продуктом: как принимаются решения, кто несёт ответственность и как стратегия превращается в измеримый результат. Ключевой сдвиг — от логики «выпускаем фичи по роадмапу» к логике «решаем проблемы клиентов и бизнеса и отвечаем за outcome». Что это значит на практике: — Кросс-функциональные продуктовые команды (PM + дизайн + инженеры) с реальными полномочиями, а не «ресурс под задачи». — Цели через результат, а не через список фич: метрики, поведение пользователей, бизнес-эффект. — Discovery + Delivery как единый контур: команда не просто строит, а проверяет — через интервью, прототипы, эксперименты, A/B и вместе отвечают за результат — Лидерство через контекст, а не контроль: чёткие цели, ограничения, приоритеты и доверие к командам. Ускорение delivery может быть следствием. Но если ускорять delivery без изменения модели управления, компания просто быстрее производит ошибки. Знакомо?) а на чем фокус у ваших команд - выполнение планов или ценность которую приносит продукт клиентам?

Продуктовые команды больше не будут такими, как раньше С приходом ИИ меняется управленческая система ролей и процессов в компании. Сначала был Waterfall — длинная последовательная цепочка от требований до релиза. Управление строилось через последовательность этапов, заранее зафиксированные решения. Скорость была низкой, изменения - дорогими. Потом пришёл Agile. Компании перешли к небольшим кросс-функциональным командам, коротким итерациям и регулярным инкрементам. CI/CD и автоматизация поставки позволили релизить код быстрее, но сам продуктовый цикл всё равно зависит от скорости человека и прохождения этапов: discovery отдельно, delivery отдельно, инкремент - раз в неделю-две. AI меняет не скорость отдельных этапов, а сам цикл создания продукта. Сегодня гипотеза может быть сформулирована, визуализирована, реализована и протестирована за часы, а не за спринты. Discovery и delivery начинают схлопываться в единый поток обучения. Это напрямую меняет и роли в команде. Product Manager формулирует гипотезы, работает с prompt’ами, сам собирает первые прототипы, запускает быстрые тесты и управляет не бэклогом, а скоростью обучения продукта. Роль разработчика тоже смещается. Код всё чаще пишет машина. Человек становится reviewer’ом и архитектором: задаёт технические рамки, формулирует качественные prompt’ы, проверяет результат, отвечает за надёжность, безопасность и масштабируемость. Дизайн перестаёт быть узким bottleneck’ом. Ведь дизайн встроен в процесс создания продукта. Тестирование как отдельная стадия постепенно исчезает - проверки встраиваются в сам процесс генерации решений. А какие изменения уже сейчас наблюдаете вы в смене ролевой модели с приходом ИИ? Делитесь в комментариях 💬

Всё чаще замечаю, что с появлением AI возникает сильный соблазн отдать ему почти всю работу 🙂 Но именно здесь скрыта опасная ловушка. Важно чётко разделять задачи на «куда», «что» и «как». На текущем этапе AI отлично работает там, где дорога уже протоптана: ему можно дать данные, задать маршрут - и в рамках конкретной операционной задачи он действительно может работать автономно. Но делегировать AI определение «куда» — без знания контекста — опасно. AI не знает вашего vision, ограничений, рисков, договорённостей и реальной логики системы. Поэтому его ответы нельзя воспринимать как истину. Без глубокого контекста уровень галлюцинаций остаётся высоким - даже если ответ звучит уверенно и логично. На практике уже сейчас можно почти полностью отдать AI: - выполнение операций - подготовку артефактов - принятие решений на операционном уровне Но уровень этих решений не должен влиять на направление движения. Это ускорение операций, а не определение стратегии. Проще говоря: человек - мозг и центр принятия решений, AI - руки Как вывод: побеждать будут те кто эффективнее выбирает направление, ведь операционку заменит ИИ. А как вы думаете, какие перспективы развития ИИ в ближайшие годы? Делитесь в комментариях💬

Всем привет, друзья 👋 Я давно не писал в этот канал - за это время произошло много всего, и, кажется, мы незаметно вошли в новую реальность. Ещё до 2024 года я писал о том, как ИИ начнёт менять продуктовую разработку. Тогда это звучало как взгляд в будущее. Сегодня - это уже повседневная практика. Настало время, где один человек в связке с ИИ может собрать первую версию продукта не за месяцы, а за дни — а иногда и за часы. То, что раньше требовало недель или месяцев, 5 ролей (PM, analyst, designer, dev, QA), десятков синков и согласований - сейчас небольшая команда (а иногда и один человек) может провернуть за считанные часы. Claude Code, Cursor, n8n уже позволят это делать. А новая модель Gemini 3.0 формирует очень достойный дизайн. С помощью AI-агентов уже сейчас можно: - собирать сигналы из данных и автоматически синтезировать инсайты - формировать продуктовые требования, исходя из вашего контекста - собирать дизайн-макеты и MVP без знания кода - анализировать результаты экспериментов Ключевое: AI - не «думает за вас», а делает мышление и реализацию быстрее и прозрачнее. Как вам новая реальность и насколько вы уже адаптиировались к ней ? какие технологии уже сейчас помогают вам? Делитесь в комментариях 💬

Всем привет! Ищу менеджера продуктовых процессов в VK к себе в команду, кто возьмет на себя сложные и амбициозные задачи развития процессов большой компании: https://team.vk.company/vacancy/42317/ Welcome отклики в личку или напрямую в вакансию🚀 Также буду рад рекомендациям🤝

Как строить разработку через Swarming? 🐝 Часто разработка идет последовательно: задача проходит через разных участников, передавая ответственность вместе с работой. Это замедляет процесс и делает его менее гибким, так как любые изменения приходится возвращать по цепочке. Альтернатива — Swarming , когда вся команда работает над одной задачей одновременно Команда вместе обсуждает решения, параллелит работу, использует парное программирование и проводит короткие синхронизации в течение дня. Ключевые принципы: Вся команда сосредотачивается на одной задаче. Цель — не распределять участников по отдельным задачам, а объединить усилия для достижения общей цели. Почему это эффективно? Задачи часто "стоят" из-за ожиданий (ответов, ревью, тестирования). Swarming устраняет эти паузы, так как все вопросы решаются сразу, а работа движется параллельно. Где использовать Swarming? 🔴Когда жмут сроки по важной фиче. 🔴При серьезных поломках или остановке продукта, где нужна вся команда. 🔴Для быстрого тестирования гипотез и выпуска решений в прод. А вы пробовали Swarming? Как вам работа в таком подходе?

Ловушка продуктовой разработки Современные компании – от Яндекса до ВК – давно научились принимать решения, опираясь на данные: 🔵Строить гипотезы на основе данных и моделирования сценариев 🔵Принимать решения на основе A/B-экспериментов. И другие полезные инструменты. Это, безусловно, шаг вперёд по сравнению с интуитивным управлением продуктом и догадками. Но есть одна проблема. За цифрами всё чаще теряется пользователь. Когда продуктовая разработка становится исключительно data-driven, мы рискуем упускать реальные потребности клиентов. Да, метрики могут расти, но понимаем ли мы, чего на самом деле хочет клиент? Какие у него боли? Какие задачи он решает с нашим продуктом? Слепая вера в цифры на мой взгляд может создавать ловушку и быть пузырём, который когда-нибудь лопнет. Ведь понимание пользователей — ключевой шаг в развитии продукта и построении новых гипотез. Поэтому я вижу идеальную продуктовую разработку как баланс двух мощных инструментов: 1️⃣ Данные. Метрики, тесты, A/B-эксперименты — всё это даёт объективную картину происходящего. 2️⃣ Исследования. Регулярные исследования, глубинные интервью, наблюдения — позволяют понять настоящие потребности клиентов. Выход в поля и общение с пользователем face to face - вот что ничего не заменит никакие цифры. Без данных мы рискуем строить продукт на догадках. Без исследования пользователей — упускать реальные потребности пользователей. Обе составляющие важны, и только вместе они дают результат. Согласны?💬