Продакт-менеджер и AI: как использовать в работе

Что меняет AI в работе продакта

К 2026 году хайп про AI поутих, и стало понятно: LLM не заменяют продакта, но сильно меняют скорость рутины. То, что раньше занимало день — расшифровка интервью, черновик PRD, набросок SQL — теперь делается за час.

Продакт, который игнорирует AI, проигрывает в скорости тем, кто его освоил. Не в качестве идей — там разница меньше — а именно в скорости от мысли до проверки. Дальше — конкретные сценарии без магии.

Простая ментальная модель: AI хорошо в задачах с чётким inputом и понятным форматом outputа (расшифровка, шаблон PRD, перевод, черновик SQL). AI плохо в задачах, требующих контекста, который у него отсутствует (стратегия команды, политика организации, конкретные пользователи). Продакт, который применяет AI там, где он силён, и не применяет там, где слаб, — экономит часы и не получает галлюцинаций.

Research и анализ интервью

Самый понятный кейс. Расшифровка часовой записи — 15 минут вместо 2 часов. Кластеризация инсайтов из 10 интервью — полчаса вместо дня.

Что работает:

• Загрузить транскрипты, попросить выделить общие боли с цитатами.
• Сравнить ответы по сегментам — новые/опытные пользователи.
• Сгенерировать гипотезы на основе паттернов.
• Подготовить summary для команды и стейкхолдеров.

Что не работает:

• Заменить само интервью. AI не считывает невербалку, паузы, эмоции.
• Делать выводы без проверки. LLM додумывает то, чего в записи не было — обязательно сверять с источником.

Хороший продакт использует AI как ассистента, а не как замену себе. Финальная интерпретация всё равно на тебе.

Шаблон промпта для анализа интервью: «Вот транскрипты пяти интервью. Выдели 5 главных болей пользователей. Для каждой приведи дословную цитату из транскрипта и укажи, в скольких интервью она встречается. Если боль упоминалась только в одном интервью — пометь это явно». Такая структура заставляет модель опираться на источник, а не выдумывать.

Работа с данными и SQL

LLM хорошо генерирует SQL по описанию задачи. Особенно если показать структуру таблиц.

Сценарии:

• Черновик запроса по описанию метрики — потом доработать под реальную схему.
• Объяснение чужого SQL — что делает этот CTE, почему так агрегируется.
• Поиск багов в запросе — модель часто ловит integer division или забытый NULLIF.
• Перевод запроса с одного диалекта на другой (BigQuery → Postgres).

Что важно: проверять цифры. LLM может выдать запрос, который синтаксически работает, но считает не то, что нужно. Особенно с DISTINCT, JOIN на дубликаты, обработкой NULL.

Антипаттерн: спрашивать у модели «посчитай retention пользователей» без указания схемы. Модель додумает таблицы, придумает логичные имена колонок и выдаст запрос, который не запустится. Хороший подход — сначала кратко описать таблицы (имя, ключевые колонки, гранулярность), потом задать вопрос.

PRD и спецификации

Черновик PRD по короткому описанию — стандартный кейс. Структура, разделы, edge cases — всё это AI генерирует за минуту.

Что выходит хорошо:

• Шаблон документа с разделами: проблема, цель, метрики, сценарии, edge cases.
• Список вопросов, которые стоит уточнить у команды.
• Перевод спеки на английский для распределённой команды.
• Чек-лист перед релизом.

Что выходит плохо:

• Конкретные продуктовые решения. AI не знает контекста твоей компании, истории решений, ограничений команды.
• Приоритизация. Любая модель выдаёт «всё важно» без давления реальности.

PRD от AI без правок — это шаблон, не документ. Дальше всё равно работа головой.

Полезная техника — попросить LLM сыграть роль «скептичного инженера» и пройтись по черновику PRD: какие вопросы он задал бы на груминге, какие edge cases пропущены, где спека двусмысленная. Это закрывает классическую слепую зону: продакт не видит дыр в собственном тексте.

Прототипы и черновики

Лендинг, посадочная, простая фича-демо — за час с помощью AI и no-code инструментов. Это меняет дизайн дискавери: вместо макета в Figma можно сразу собрать кликабельный прототип и показать пользователям.

Сценарии:

• Тестовая страница с формой для проверки спроса до разработки.
• Wizard-of-Oz: интерфейс есть, бэкенд имитирует продакт вручную.
• Несколько вариантов копирайта на A/B.
• Email-цепочка для онбординга — черновик за 10 минут.

Это не отменяет дизайнера и разработчика, но позволяет проверить идею до того, как они подключатся.

Шаблон проверки спроса за один день: утром собрать лендинг с описанием фичи и формой «оставь email», днём купить на 5–10 тысяч рублей таргета на узкий сегмент, вечером смотреть конверсию. Если из 1000 показов 0 заявок — гипотеза слабая, можно не тратить квартал разработки. Это ориентиры порядка величин, конкретные числа зависят от продукта и каналов.

AI-фичи в продукте

Отдельная история — когда продукт сам использует LLM. Здесь продакт должен понимать чуть больше технических деталей.

Что важно знать:

• Стоимость токенов. Каждый запрос — деньги. На масштабе это меняет юнит-экономику.
• Latency. Ответ модели может занимать секунды. UX должен это учитывать — стриминг, индикаторы, фоновые задачи.
• Качество. Метрики качества для AI-фичи отличаются от обычных. Тут не CR, а accuracy/relevance/satisfaction.
• Hallucinations. Модель может уверенно врать. В критичных сценариях нужны ограничители — RAG, проверки, fallback.
• Приватность данных. Что улетает в провайдера, что хранится, что можно использовать для обучения.

Продакт AI-фичи — это продакт + чуть-чуть ML. Не нужно уметь обучать модели, но нужно понимать, как они работают и где ломаются.

Полезный фреймворк для оценки AI-фичи: «Что сломается, если модель ответит неправильно в 5% случаев? В 1%? В 0.1%?» Если ответ «ничего страшного» — это потребительская фича. Если «потеряем деньги или доверие» — нужны проверки, фильтры, человеческий контроль. Этот вопрос — первое, что надо задать на старте.

Метрики качества AI-фичи

Стандартный набор:

• Accuracy / correctness. Доля ответов, которые объективно правильные. Считается на ручной разметке или через автоматические оценки.
• Relevance. Доля ответов, которые релевантны запросу пользователя.
• Helpfulness / satisfaction. Субъективная оценка пользователя — большой палец, рейтинг, явная обратная связь.
• Latency p50/p95/p99. Сколько секунд от запроса до ответа.
• Cost per request. Сколько стоит один ответ.
• Containment rate (для саппорта) — доля диалогов, которые AI закрыл без эскалации.
• Refusal rate. Доля запросов, на которые модель отказалась отвечать. Слишком высокий refusal — продукт неудобный, слишком низкий — рискованный.

Ориентиры (порядки величин): хороший support-бот удерживает containment 30–60%, accuracy на узкой задаче — выше 90%, p95 latency для синхронных сценариев — до 2–3 секунд. Эти числа сильно зависят от модели и задачи и приведены как ориентир, не как KPI без контекста.

Частые ошибки

• Доверять LLM на слово. Любые цифры, цитаты, факты — проверять.
• Заменять разговор с пользователем на «спроси у AI». Модель не знает твоих пользователей.
• Использовать AI для решений. Решения принимает продакт, AI — для подготовки материалов.
• Игнорировать стоимость. AI-фичи на масштабе могут быть нерентабельны.
• Передавать чувствительные данные. Корпоративные документы, PII — только через корпоративные инструменты с правильными настройками.
• Запускать AI-фичу без метрик качества. Через месяц непонятно, она работает или просто красиво смотрится.
• Ставить AI везде. Если задачу решает обычный поиск или правило — LLM не нужен.

Связанные темы

• Hard skills продакт-менеджера
• Discovery в продакт-менеджменте
• Продакт и исследования
• Продуктовая аналитика

FAQ

Заменит ли AI продактов?

Нет. AI заменяет рутину, но не принятие решений и работу со стейкхолдерами. Скорее, продакт без AI заменит продакта с AI — по скорости.

Какие LLM-инструменты использовать продакту?

Любая из крупных моделей — ChatGPT, Claude, Gemini. Для команды — корпоративные версии с настройками приватности. Для кода и SQL — встроенные ассистенты в IDE.

Можно ли давать LLM PRD и интервью?

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

Как готовиться к собесу на продакта в AI-продукт?

Понимать базовые метрики качества LLM, стоимость токенов, latency, hallucinations. Знать, как устроен RAG. Уметь обсудить trade-off между качеством и стоимостью.

Где грань между AI и обычным продактом?

Скоро её не будет. Через 2–3 года использование AI станет таким же базовым, как Excel или Notion.

Что такое RAG и зачем продакту это знать?

RAG — retrieval augmented generation, подход, когда модель сначала ищет нужные документы, а потом отвечает на их основе. Продакту это знать важно: RAG снижает галлюцинации, но усложняет архитектуру и стоимость, и эти trade-off обычно решает продакт совместно с инженерами.

Как считать ROI AI-фичи?

Прирост ключевой метрики (конверсия, retention, экономия часов саппорта) минус стоимость инференса, разметки, инфраструктуры и поддержки. Если ROI отрицательный — фичу резать или менять модель на дешевле.

Что делать, если фича работает «вроде хорошо», но иногда галлюцинирует?

Зависит от цены ошибки. Для рекомендации фильма — допустимо. Для расчёта налогов — недопустимо без проверки. Решение принимает продакт, исходя из радиуса вреда.

---

Прокачать продуктовое мышление и кейсы — открой Карьерник: метрики, A/B, продуктовые кейсы в формате коротких тренировок.