За последний год у продуктовых команд, с которыми мы работаем, произошел одинаковый сдвиг. Раньше выкатить новую фичу было задачей на месяцы, и любая идея, попавшая в работу, по дороге проходила приоритизацию, дискавери, продуктовый комитет и защиту перед стейкхолдерами. Сейчас та же фича собирается за неделю силами трех человек на Cursor и Claude Code, и большая часть этих фильтров команде уже не нужна. Технических ограничений больше нет, а классическая задача product-market fit, попасть продуктом в реальную потребность реального пользователя, никуда не делась и стала видна гораздо отчетливее.
В абсолютных цифрах сдвиг проще всего показать через темп поставки. Команды, у которых еще в начале 2025 года выходило по два релиза в месяц, сейчас выпускают по три-четыре в неделю. У некоторых стартапов скорость поставки выросла в пять-семь раз. При этом ни в одной команде, с которой мы работали в последние полгода, ключевые продуктовые метрики не выросли в той же пропорции. Retention, conversion, NPS и LTV двигаются по своей собственной кривой, и темп поставки фич на эту кривую влияет уже намного меньше, чем привычно думать.
Почему скорость поставки перестала автоматически давать рост
Объяснение этому простое и одновременно неудобное. Скорость выпуска фич никогда не была главным драйвером роста продукта. Драйвером всегда было соответствие того, что компания делает, и того, что нужно ее пользователю. Концепция product-market fit, которую Марк Андриссен сформулировал в 2007 году, говорила именно об этом, и за пятнадцать лет ничего фундаментально не поменялось. Раньше этот тезис был частично замаскирован тем, что плохой product-market fit ощутимо болел из-за высокой стоимости каждой фичи. Команда успевала почувствовать боль через инженерную очередь, через дискуссии с менеджментом, через выбор «что мы делаем в этом квартале». Когда стоимость реализации упала, эта маскировка ушла.
Команды стали быстро упираться в новое наблюдение. Можно выпускать пять фич в неделю, тратить на это меньше людей, чем год назад, и при этом не двигать продуктовую метрику, на которую завязан рост выручки. Можно выпускать одну фичу в две недели, потратить столько же человеко-часов на пользовательские исследования, сколько раньше уходило на разработку, и получить ощутимый прирост в той же метрике. Разница между этими двумя командами заключается в том, попадает ли каждая выпущенная фича в реальную задачу реального пользователя.
Что выходит на первый план в продуктовой работе
Когда стоимость реализации становится низкой, продуктовая работа смещается в две большие области, на которые раньше у команд не всегда хватало времени.
Первая из них касается понимания пользователя через постоянные глубинные исследования. Customer development в стиле Стива Бланка, фреймворк jobs to be done Клейтона Кристенсена, регулярные интервью с реальными пользователями, наблюдение за их работой в полевых условиях, разбор того, как они сегодня решают свою задачу до того, как столкнулись с вашим продуктом. Когда команда выпускает пять фич в неделю, эти исследования должны идти параллельно поставке, иначе у команды нет основания понимать, какие из выпущенных фич попадают в цель.
Вторая большая область связана с валидацией гипотез до начала разработки. С коротким циклом сборки прототипа эта работа стала несравнимо доступнее. За день можно собрать кликабельный прототип через Cursor или Claude Code, показать его пятерым представителям целевой аудитории и через неделю иметь обоснованную гипотезу о том, нужно ли это пользователю, до того как был вложен первый человеко-час полноценной разработки. У команд, в которых метрики растут при ускоренной поставке, эта работа последовательно делается. У команд, в которых метрики не растут, она часто пропускается под аргументом «разработка же быстрая, давайте просто сделаем и посмотрим».
Что меняется в роли продакт-менеджера
Раньше типичный профиль сильного продакта на рынке выглядел плюс-минус одинаково. Глубокое понимание процессов, умение приоритизировать большой бэклог, договариваться со стейкхолдерами и инженерной командой, защищать сроки и качество. Эти навыки никуда не делись, и они по-прежнему важны. Центральная зона ответственности в роли при этом смещается.
Сейчас от продакта в большей степени ожидается, что он принесет в команду понимание реальной потребности пользователя, обоснованную гипотезу о том, как продукт может эту потребность закрыть, и способ проверить эту гипотезу до запуска разработки. Все остальные навыки, такие как приоритизация, работа со стейкхолдерами, координация, защита сроков, встраиваются вокруг этого ядра. Без этого ядра остальные навыки работают вхолостую, потому что обслуживают процесс, не привязанный к реальной потребности пользователя.
На рынке найма этот сдвиг тоже уже виден. В описании ролей все чаще появляются формулировки про customer development, hypothesis-driven development, опыт работы с jobs to be done и data-informed product decisions. Технические требования к продакту (умение работать с jira, понимание agile-процессов) при этом отходят на второй план, потому что их закрывают практически все кандидаты, и они перестали быть точкой различия.
Почему продуктовое мышление перестало быть зоной одной роли
Если остановиться только на навыках продакта, картина получается неполная. От продакта понимание пользователя ждали всегда, и это никогда не было его новой задачей. Действительно новым в последний год стало то, что ровно это же понимание теперь ожидается от всей продуктовой команды, от каждого ее участника.
Причина у этого простая. Когда инженер за день собирает работающий прототип, его шаги перестают быть исполнением чужого ТЗ и превращаются в продуктовые решения. Какой именно сценарий собирать. Какой кейс пользователя считать основным. Где остановиться, а где доделать. Если у инженера в этот момент нет своего понимания того, для кого он это делает, продуктом руководит случай или его собственная интуиция о пользователе, которая совершенно не обязательно совпадает с реальностью. Аналогичный сдвиг произошел в работе дизайнера, у которого появилась возможность за час получить от модели десяток макетов, и в работе аналитика, который собирает внутренний инструмент сам, и в работе маркетолога, который собирает лендинг за вечер.
Из этого выросла отдельная роль и одновременно отдельный профиль для всей команды, который мы подробно разобрали в отдельной статье про продакт-инженера. Главное там в том, что продуктовое мышление перестает быть зоной ответственности одного человека в команде и становится распределенной компетенцией. У продакта остается роль того, кто держит общую картину и продуктовую стратегию, но конкретные продуктовые решения принимаются на каждом рабочем месте, и они принимаются гораздо качественнее, если у каждого человека есть собственный понятный контакт с реальным пользователем.
Для руководителя это означает, что инвестиции в продуктовое мышление имеет смысл распределять на всю команду, включая инженеров, дизайнеров, аналитиков и маркетологов. Дискавери-сессии с участием инженеров, наблюдение за пользователями вместе с дизайнерами и аналитиками, регулярные интервью с участием команды, а не одного продакта. Это та практика, которая отличает команды, у которых рост метрик идет вместе с ускорением поставки.
Что делать руководителю продукта
Если в продуктовой команде уже виден эффект от ускоренной разработки, и одновременно есть ощущение, что метрики двигаются медленнее, чем ожидалось, имеет смысл оценить, какая доля квартального времени уходит на пользовательские исследования и предварительную валидацию гипотез по сравнению с долей, уходящей на разработку и поставку. Соотношение между ними обычно показывает, где команда находится сейчас и насколько ее продуктовый процесс адаптирован к новой экономике разработки.
В onagile.ru мы делаем два формата работы с этой задачей. Продуктовый консалтинг для запуска и развития продуктов, когда нужно пересобрать продуктовый процесс под текущую реальность и встроить регулярную работу с пользователями и валидацию гипотез в такт команды. И тренинг Advanced Product Ownership для продактов и product owner, которые хотят системно прокачать навыки дискавери, формулирования и валидации гипотез и продуктовой приоритизации с международной сертификацией ICP-APO от ICAgile.
Обсудить продуктовый процесс вашей команды
Поможем встроить регулярную работу с пользователями, валидацию гипотез и продуктовую приоритизацию в темп современной разработки.
Узнать подробности