Марти Кейган был самым влиятельным голосом в области управления продуктами на протяжении двух десятилетий. Его книги *INSPIRED*, *EMPOWERED*, *TRANSFORMED* определили словарь, который индустрия использует, чтобы говорить о себе. Когда Кейган пишет, мир продуктов реорганизуется вокруг того, что он говорит.

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

В декабре 2023 года Кейган опубликовал [«Вклад менеджера по продукту»](https://www.svpg.com/the-product-manager-contribution), где он определил четыре критически важные области знаний, которые премьер-министр должен передать команде: глубокое знание клиентов, свободное владение данными и аналитикой, глубокое понимание бизнеса (выход на рынок, заинтересованные стороны, экономика, соблюдение требований) и владение конкурентной средой и отраслевыми тенденциями. Его вывод был однозначным:

> Это четыре важнейших вклада, которые вам абсолютно необходимо внести в команду. Эти знания не исходят от дизайнера продукта и не от инженеров, но дизайнеру и инженерам необходимо, чтобы эти знания были представлены в команде, если они хотят принимать разумные и обоснованные решения.
>
> *Марти Кейган, ["Вклад менеджера по продукту"](https://www.svpg.com/the-product-manager-contribution), декабрь 2023 г.*

В январе 2025 года он пошел дальше. В ["Управление продуктами AI 2 года спустя"](https://www.svpg.com/ai-product-management-2-years-in) он утверждал, что «вопреки распространенному мнению, роль менеджера по продукту становится более важной, но и более сложной в генеративных продуктах на основе искусственного интеллекта, а не меньше».

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

## Поворотная точка

К маю 2025 года в книге «Эра создателя продукта» (https://www.svpg.com/the-era-of-the-product-creator) Кейган объявил, что роль менеджера по продукту абстрагируется до общей функции, которую может выполнять каждый. Дизайнеры, инженеры, основатели, заинтересованные стороны, любой человек, обладающий «чувством продукта» и способный использовать новые инструменты прототипирования на базе искусственного интеллекта, может выступать в роли «создателя продукта». Премьер-министр больше не был незаменимым интегратором. Премьер-министр был одним из возможных воплощений роли, которая теперь была открыта для всех желающих.

Этот сдвиг ускорился в течение оставшейся части 2025 года и в 2026 году. [«Цель прототипов»](https://www.svpg.com/the-member-of-prototypes/) (сентябрь 2025 года) переопределила исследовательскую работу как работу по прототипированию. ["Прототипы против продуктов"](https://www.svpg.com/prototypes-vs-products/) (ноябрь 2025 г.) предупредили менеджеров по проектам, что они ставят себя в неловкое положение, путая прототипы с производственным программным обеспечением. ["Создавайте, чтобы учиться, или создавайте, чтобы зарабатывать"](https://www.svpg.com/build-to-learn-vs-build-to-earn/) (апрель 2026 г.) сжато описывает вклад премьер-министра в создание и тестирование прототипов, основанных на понимании продукта. А [Часто задаваемые вопросы о сборке для обучения](https://www.svpg.com/build-to-learn-faq/) (апрель 2026 г.) систематически лишали роль премьер-министра всех самооценок, которые не были «строителями»: ни решающего, ни защитника команды, ни менеджера, ни человека, который объясняет «почему».

Осталось следующее: вы создаете прототипы, тестируете их на четыре риска, и ваше чувство продукта подсказывает вам, что делать с результатами.

## Что потерялось

Вот Кейган в октябре 2023 года, описывающий премьер-министра уполномоченной продуктовой команды:

> Глубокие знания клиента, данных, отрасли и особенно вашего бизнеса (продажи, маркетинг, финансы, поддержка, юриспруденция и т. д.) абсолютно не подлежат обсуждению и необходимы.
>
> *Марти Кейган, ["Product vs. Feature Teams"](https://www.svpg.com/product-vs-feature-teams), октябрь 2023 г.*

А вот Кейган в январе 2022 года, объясняющий, как премьер-министр решает вопрос жизнеспособности:

> Крайне важно, чтобы менеджер по продукту имел прямой доступ к экспертам вашего бизнеса: в области маркетинга, продаж, услуг, финансов, юриспруденции, соблюдения нормативных требований, производства, профильных экспертов и т. д. Менеджер по продукту должен установить отношения с этими людьми, при которых заинтересованная сторона считает, что менеджер по продукту понимает соответствующие ограничения и обеспечит их устранение в любом предлагаемом решении.
>
> *Марти Кейган, ["Два в коробке PM"](https://www.svpg.com/two-in-a-box-pm), январь 2022 г.*

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

Кейган 2022 года это понимал. Cagan 2026 воспринимает это как фоновый шум.

## Пропущенный ход

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

Однако Кейган отчасти прав в отношении чего-то реального. ИИ позволяет одному человеку одновременно выполнять больше ролей. Я выполняю все функции своего стартапа, продукта, проектирования, проектирования и вывода на рынок способами, которые три года назад потребовали бы команды из пяти человек. Теперь проектный менеджер может создавать прототипы и поставлять программное обеспечение так, как никогда раньше. В этом есть реальная эффективность, особенно на раннем этапе, когда контекст сосредоточен в одной голове и каждая передача является чистой потерей. Премьер-министры должны строить. В этом Кейган прав.

Он ошибается, когда сворачивает определение роли в соответствии с новыми возможностями. Человек может носить шляпу ПМ и шляпу строителя. Это не делает их одинаковой шляпой. Роль менеджера по-прежнему определяется комплексным суждением в четырех областях знаний. Строительство – это другой вид работы с другими критериями качества. Когда один человек делает и то, и другое, он хорошо выполняет две работы, а не одну совмещенную работу. Смешение «один человек может делать больше вещей» с «теперь роли одни и те же» — это именно та категориальная ошибка, которая приводит к тому, что организации перестают нанимать сотрудников ради глубины интеграции, поскольку они предполагают, что у строителя она уже есть.

Аргумент практически пишется сам собой, и он уже скрыт в собственных работах Кейгана.

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

Это неудачи интеграции, а не неудачи прототипирования. Это междисциплинарная напряженность, которая существует во взаимоотношениях *между* измерениями, а не в каком-то одном из них. Никакое количество прототипов Lovable не сможет их обнаружить.

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

PM как интегратор становится *критической* проверкой системы, которая теперь оптимизирована по скорости, но не по согласованности.

## Патология, которую уже вылечили

Есть еще одна ирония, которая обостряет противоречие. Патология, на которую ответил Кейган, когда менеджеры по проектам ничего не делают, кроме координации, содействия и написания спецификаций, никогда не прикасаясь к реальному продукту, была настоящей и серьезной проблемой. Но это была проблема конкретной эпохи, когда для создания прототипов требовались дизайнерские или инженерные навыки, которых не хватало многим проектировщикам. Не имея доступа к самому продукту, они заполняли свои дни менеджментом Jira, встречами с заинтересованными сторонами и представлением дорожных карт.

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

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

## Чего на самом деле требует смысл продукта

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

С точки зрения [Часто задаваемые вопросы по сборке для обучения](https://www.svpg.com/build-to-learn-faq/) все эти действия выглядят как «не сборка». Но они являются основой, на которой растет чувство продукта. Определяя работу менеджера проекта как создание прототипов и тестирование, Кейган рискует создать менеджеров проекта, которые владеют инструментами, но им не хватает контекстуальной глубины, чтобы знать, что прототипировать. Это именно тот вариант неудачи, о котором он предупреждает, не осознавая, что его собственные рамки препятствуют действиям, которые его предотвращают.

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

## Более сильный аргумент

Вот что мог бы сказать Кейган и что уже подразумевает его архив с 2020 по начало 2025 года:

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

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

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

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

Речь идет не только о ПМ. Каждая дисциплина работает над одним и тем же структурным вопросом: когда уровень выполнения вашей работы поглощается, ваша идентичность мигрирует в то, что ИИ только что сделал проще, или в то, что ИИ не может сделать? Дебаты с премьер-министром являются одним из примеров этого вопроса, который виден потому, что в трудах Кейгана зафиксированы обе стороны противоречия. Более широкая переориентация каждой роли программного обеспечения — это один и тот же вопрос, который применяется повсюду. Я излагаю институциональную версию в [The Human Inversion](/posts/series/the-human-inversion), серии из пяти частей, посвященной основам, исполнению, проверке и тому, кто сохраняет последовательность, когда середина растворяется.

---

Ничто из этого не означает, что Кейган ошибается во всем. Разница между [строить, чтобы учиться, и строить, чтобы зарабатывать](https://www.svpg.com/build-to-learn-vs-build-to-earn/) реальна и полезна. [Система четырех рисков](https://www.svpg.com/four-big-risks/) – хороший стартовый контрольный список. Предупреждение о менеджерах проектов, которые [путают прототипы с продуктами](https://www.svpg.com/prototypes-vs-products/), своевременно. И призыв к менеджерам проектов действительно взаимодействовать с продуктом, создавать, а не просто описывать, всегда был одним из его самых ценных вкладов.

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

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

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