Как AI меняет работу продуктового менеджера: тренды и инструменты

Главным навыком PM становится не «умение написать ТЗ», а умение принимать правильные решения в условиях неполной информации.

Это, пожалуй, самое интересное изменение.

Раньше было дорого создать продукт:

идея → аналитика → дизайн → разработка → тестирование → релиз.

С AI стоимость создания сильно падает.

Поэтому появляется новая проблема:

Мы теперь можем очень быстро создать неправильный продукт.

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

Поэтому становятся гораздо важнее:

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

PM должен становиться более «техническим»

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

Но PM всё чаще должен уметь:

• работать с API;
• понимать LLM;
• пользоваться CLI;
• создавать прототипы;
• работать с MCP;
• подключать данные к AI;
• самостоятельно собирать небольшие инструменты;
• понимать архитектуру AI-продуктов.

Atlassian уже прямо продвигает идею, что PM должен быть комфортен с CLI и уметь использовать AI-инструменты непосредственно в процессе создания продукта.

То есть граница:

Product Manager ↔ Designer ↔ Developer

становится гораздо менее жесткой.

AI-продукты требуют совершенно другого Product Management

Здесь появляется отдельная специализация:

AI Product Management.

У AI-продукта нельзя управлять качеством так же, как у обычного SaaS.

Нужно думать про:

• Hallucinations — галлюцинации, когда AI придумывает факты или выдаёт неверную информацию как достоверную.
• Latency — задержка, время от отправки запроса до получения ответа.
• Token cost — стоимость обработки токенов, то есть стоимость использования AI-модели.
• Model selection — выбор модели, подходящей для конкретной задачи.
• Prompt / context — инструкция для AI и контекст, который AI получает для выполнения задачи.
• Evaluation — оценка качества работы AI по заранее определённым критериям.
• Permissions — разрешения, определяющие, что AI имеет право делать в системе.
• Privacy — конфиденциальность и защита пользовательских данных.
• Guardrails — защитные ограничения, которые не позволяют AI выходить за установленные рамки.
• fallback-механизмы.

То есть PM теперь должен управлять не только UX, но и поведением вероятностной системы.

IEEE в 2026 году описывает этот переход как движение от классических roadmap/requirements к управлению reasoning systems, где поведение системы нельзя полностью задать заранее фиксированными требованиями.

Давайте разберем на примере:

Как это работает в обычном SaaS

Представим интернет-магазин.

Требование:

Если пользователь нажал «Добавить в корзину», товар должен появиться в корзине.

Можно написать почти математически:

Input: add(product_id=123)
Expected output: товар 123 появился в корзине.

И проверить:

Нажал → товар появился
Нажал → товар появился
Нажал → товар появился

Есть достаточно чёткое понятие correct / incorrect.

То же самое:

Если пароль неправильный → показать ошибку.

Если сумма заказа > 10 000 ₽ → бесплатная доставка.

Если товара нет → нельзя оформить заказ.

Это детерминированные требования.

А теперь возьмём AI

Например, мы создаём AI-агента поддержки.

Требование:

«Ответить клиенту правильно, полезно и вежливо».

Проблема: что именно является правильным ответом?

Клиент:

«Я получил товар, но он мне не подходит. Что делать?»

AI может ответить:

«Вы можете оформить возврат в течение 14 дней…»

А может:

«Конечно. Давайте разберёмся. Если товар не использовался, его можно вернуть…»

Оба ответа могут быть правильными.

Но клиент может написать:

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

Теперь появляется огромное количество вариантов.

Невозможно заранее написать:

IF message = X
THEN answer = Y.

Причём проблема ещё глубже

У AI нет заранее заданного полного пространства поведения.

Допустим, мы говорим:

«AI должен хорошо объяснять сложные вещи».

Что такое хорошо?

Можно написать 100 требований:

• не врать;
• быть кратким;
• объяснять понятно;
• использовать примеры;
• не использовать жаргон;
• учитывать контекст;
• не повторяться.

Но всё равно останутся миллионы ситуаций, которые мы не предусмотрели.

То есть Product Manager сталкивается с:

Open-ended behavior (неформальное поведение)

вместо:

Predefined behavior (предопределенное поведение)

QA-инженер тоже меняет свой подход к работе

В обычном SaaS можно написать:

10 000 тест-кейсов → прогнать → убедиться, что всё работает.

Для AI это гораздо сложнее.

Например:

Пользователь: «Мне очень плохо, я не знаю, что делать».

Какой должен быть точно ожидаемый результат?

Мы не можем просто сравнить ответ AI со строкой:

"Правильный ответ: ..."

Потому что хороших ответов может быть много.

Поэтому появляются системные оценки.

Мы начинаем оценивать:

• Factuality — фактическая точность
• Relevance — релевантность, соответствие запросу
• Safety — безопасность
• Completeness — полнота ответа
• Consistency — последовательность и непротиворечивость
• Task success — успешность выполнения задачи
• Hallucination rate — доля галлюцинаций, то есть процент ответов с выдуманными или неверными фактами
• Latency — задержка ответа
• Cost — стоимость выполнения запроса

То есть вместо:

«Ответ должен быть именно таким»

получаем:

«Ответ должен соответствовать таким-то критериям качества».

И вот здесь меняется работа Product Manager

Для обычного продукта PM может сказать разработчику:

«Когда пользователь нажимает X, система должна сделать Y».

Для AI-продукта часто приходится говорить:

Это уже совершенно другой тип Product Requirement (требований к продукту).

Возникает новая концепция: «Product Manager + AI team»

PM получает виртуальную команду:

PM

1. Research Agent агент исследования
2. Analytics Agent аналитический агент
3. Competitive Intelligence Agent агент конкурентной разведки
4. UX Agent агент по пользовательскому опыту
5. Prototype Agent агент создания прототипов
6. PRD Agent агент подготовки продуктовой документации
7. QA Agent агент контроля качества и тестирования
8. Growth Agent агент роста продукта

И PM становится не исполнителем всех этих операций, а оркестратором.

Это очень похоже на то, как раньше руководитель управлял людьми:

«Проведи исследование»
«Проанализируй данные»
«Подготовь варианты»
«Сделай прототип»

Теперь часть этих поручений можно отдавать AI.