Продакт-менеджер, которого учили пять лет назад, умел три вещи: чётко ставить проблему, расставлять приоритеты в плане работ и договариваться с заказчиками внутри компании. Сейчас этого мало. Сильного продакта от отставшего эти навыки уже не отличают.
Каждое решение стало дороже. Плохо продуманная ИИ-функция стоит денег при каждом запросе. Неверно прочитанная метрика уводит не туда целый квартал. А цена, назначенная по ошибочным расчётам, съедает маржу, когда продукт растёт. Обучение пошло за этим сдвигом: от лекций о методиках к занятиям, где каждое решение нужно посчитать и защитить.
Этот текст для тех, кто выбирает обучение для команды: руководителя продукта, HR или отдела обучения. Программы продают широту тем. А команде нужно другое: научиться тому, что её продакты сейчас делают плохо. Дешевле всего выяснить это проверкой до покупки. Тест навыков с разбором по модулям покажет, за какие блоки программы стоит платить, а какие команда уже знает.
Практика без обратной связи больше не догоняет роль
Долгое время продакты учились на практике, у наставников и на общих бизнес-курсах. Это работало, пока роль не менялась. Теперь та же должность включает финансовые расчёты, оценку ИИ-систем и умение реально влиять на компанию. Основа осталась прежней: деловое мышление, умение договориться с разными отделами и стратегическое лидерство. Горчелс в The Product Manager’s Handbook называет такую роль «генеральным менеджером продукта». Вырос круг навыков вокруг этой основы, и именно там обычное обучение отстаёт.
Изменились четыре вещи. Первая: ИИ стал частью продукта, а не внутренним делом инженеров. Поэтому продакт должен понимать, как оценивают модель, где она ошибается и сколько стоит каждый её ответ. Вторая: умение работать с данными стало обязательным. Читать воронку, разбирать удержание по когортам, отличать ранние сигналы от итоговых цифр теперь требуют с порога. Третья: компании описывают, какие навыки нужны продакту, чтобы роль не была такой расплывчатой. Четвёртая: обучение должно давать почувствовать давление сроков и экспериментов, а лекция этого не даёт.
Последний пункт решает больше остальных. Продакт, который год выпускает фичи и ни разу не узнаёт, сдвинули ли они удержание, копит стаж, а не суждение. Поэтому хорошая программа строится вокруг задач, где ответ можно проверить, и первая такая задача касается денег.
ИИ-грамотность измеряется стоимостью запроса
Базовую формулу стоит уметь считать без калькулятора: стоимость ИИ-функции в месяц = запросы x токены на запрос x цена за токен. Например: 300 000 запросов x 2 000 токенов x 3 USD за миллион токенов = 1 800 USD в месяц, или 0,6 цента на запрос. Удвойте длину промпта, и счёт удвоится вместе с ней.
Обучать модель продакта никто не просит. От него ждут, что он поймёт решения вокруг неё. Как модель проверяют и выпускают. Какие показатели важны: точность, скорость ответа, падение качества со временем, цена запроса. Где риски: предвзятость, выдуманные ответы, утечки личных данных. Главная граница проходит по деньгам. Продакт, который не думает о цене запросов, пропустит функцию, которая уходит в минус, как только 5% пользователей начинают ею активно пользоваться.
Учебное упражнение выглядит так, цифры условные. ИИ-помощник в тарифе за €15 в месяц обходится в среднем в €0,30 на пользователя, но самый активный один процент пользователей стоит уже по €12. Слушатель должен найти три рычага и посчитать каждый. Первый: лимит запросов, который отрезает хвост распределения. Второй: перенос несрочных задач, например ночной сводки, в пакетный режим. OpenAI Batch API даёт за такие запросы скидку 50% при обработке в течение 24 часов, и €12 превращаются примерно в €6 для той части нагрузки, что ждать может. Третий: кэширование повторяющегося контекста. У Anthropic чтение из кэша стоит 0,1 от обычной цены входных токенов, запись в пятиминутный кэш 1,25. Если пользователь задаёт десять вопросов к одному длинному документу, контекст оплачивается почти полностью один раз, а не десять.
Самый дешёвый рычаг ещё не ответ. Правильный ответ говорит, какой рычаг меньше всего портит впечатление для какой группы клиентов и куда в итоге ставят функцию: в текущий тариф, в тариф дороже или под жёсткий лимит. Этим продуктовое решение и отличается от демо.
Аналитика и приоритизация учат не верить собственной уверенности
Основа аналитики: воронки активации и то, как люди начинают пользоваться функциями, удержание и когорты, главная метрика (North Star) и эксперименты (A/B-тесты, проверка реального прироста, порядок запусков). Данных обычно хватает. Ловушка в том, как их толкуют. Всплеск активности может оказаться сезонным. А метрика, которая растёт без роста удержания, только радует глаз и ничего не значит. Хорошая программа учит отличать шум и формулировать гипотезу, которую можно опровергнуть, ещё до теста, пока результат не подсказывает удобный ответ.
Рядом стоит юнит-экономика. PM должен собирать простую модель: CAC, CLV, срок окупаемости, маржинальность по сегментам, сценарии цены и упаковки, бизнес-кейс инициативы из roadmap. Без неё приоритизация остаётся делом мнений.
Здесь же учат считать приоритеты числом, чтобы спор не выигрывал самый громкий. Фреймворк RICE, возникший в Intercom, перемножает охват, эффект и уверенность и делит на трудозатраты. Его слабое место сидит в «уверенности». Возьмём учебный кейс. Инициатива А: охват 4000 пользователей в квартал, эффект 2, уверенность 80%, трудозатраты 4 человеко-месяца. Счёт: 4000 × 2 × 0,8 / 4 = 1600. Инициатива Б: охват 10 000, эффект 1, уверенность 50%, трудозатраты 5. Счёт: 10 000 × 1 × 0,5 / 5 = 1000. А побеждает. Но автор инициативы Б поднимает уверенность до 100%, «мы же всё обсудили», и получает 2000. Порядок перевернулся, хотя новых данных не появилось.
Поэтому в хорошей программе оценку прогоняют вслепую: двое оценивают уверенность независимо, а расхождение больше 30 пунктов становится поводом спросить, какое допущение разворачивает вывод. Слушатель, который однажды увидел, как одно число переставляет roadmap, перестаёт доверять таблицам без источников.
Работу с клиентами и лидерство проверяют на стыке отделов
В логике Customer Development, которую Стив Бланк описывает в The Startup Owner’s Manual, обучение тренирует итеративную проверку гипотез: непрерывные интервью, jobs-to-be-done, быстрое чтение рыночных сигналов. Оптику jobs-to-be-done в широкий оборот ввёл Клейтон Кристенсен разбором про молочный коктейль: люди «нанимают» продукт на конкретную работу, и понимать надо эту работу, демографический портрет покупателя объясняет куда меньше. Современная форма дисциплины описана у Терезы Торрес в Continuous Discovery Habits (2021): еженедельные контакты с пользователями вместо разового исследования перед проектом, которые ведёт сама продуктовая тройка (продакт, дизайнер, инженер), привязывая находки к дереву возможностей. Команда, опирающаяся только на дашборды, оптимизирует трение, которого так и не поняла.
Ценность продакта часто решается на стыке с продажами, инженерами, дизайном и маркетингом. Там ясная постановка задачи весит больше, чем должность. Настоящий навык в том, чтобы открыто назвать компромисс: чем жертвуем, почему и что заставило бы передумать. Хорошо оформленное несогласие стоит одной встречи. Вялое согласие, которое разваливается при реализации, стоит квартала.
Чем больше связанных направлений ведёт продакт, тем важнее видеть зависимости и привязывать план работ к измеримым результатам, а не к списку задач. Отсюда образ продакта как «мини-директора», который отвечает за итог. Марти Каган в работах SVPG называет это разницей между самостоятельными командами (empowered), которым дают проблему и метрику, и командами-исполнителями (feature teams), которым спускают список функций. Программа, которая учит отвечать за результат, готовит к первой роли. Каталог задач готовит ко второй.
Порядок модулей важнее их списка
Стройная программа строится как прогрессия, а не как набор модулей. Она начинается с явной модели компетенций (стратегия, аналитика, исполнение, лидерство, понимание пользователя, техническая грамотность): названные ожидания снижают неопределённость, из-за которой роль расплывается. Дальше идут фундаменты: жизненный цикл продукта, петли discovery и delivery, методы приоритизации и основы юнит-экономики.
На этом строится практика работы с данными и экспериментами: интерпретация воронок, дизайн метрик, чтение «шумных» данных. Модули по ИИ приходят позже, когда аналитическая база уже есть. Иначе PM судит об ИИ-функции, не умея измерить, что она даёт. Разницу между теорией и компетенцией делают два шага. Симуляции воспроизводят реальный контекст решения, где данных не хватает и время поджимает: продуктовая стратегия, ролевые игры с «продажами» и «финансами», приоритизация под бюджетным ограничением. А оценка замыкает цикл, измеряя прикладной анализ вместо заученного словаря.
Полная программа покрывает семь блоков: базовые фреймворки, данные и метрики, ИИ, рыночное и финансовое моделирование, лидерство и коммуникацию, этику и регулирование, экспериментирование. Чаще всего недооценивают этику и регулирование, хотя с момента, когда модель обрабатывает персональные данные, это проектное ограничение. Учебный модуль удобнее всего строить на конкретных случаях: какие данные видит модель, кто отвечает за её ошибки и как пользователь может оспорить решение.
Формат весит не меньше содержания. Пять решений его определяют: сцеплять теорию и практику в одних и тех же занятиях; опираться на симуляции решений; работать в реальных инструментах профессии; организовывать менторство и обучение в паре; делать PM ответственным за портфель, а не за изолированную фичу. Одни и те же понятия, усвоенные в пассивном курсе или в симуляции, дают разную компетенцию.
Инженер, PM в ИИ-компании и внутренняя академия начинают с разного
Переход из инженера в PM стартует с реального преимущества, знакомства с устройством систем, но должен закрыть бизнес-моделирование и discovery, ровно то, чему инженерия не учит. Для него ИИ-модуль можно сжать вдвое, а освободившееся время отдать интервью с пользователями и расчётам окупаемости. PM в компании, где ИИ составляет ядро продукта, нуждается в усилении по метрикам оценки, анализу реализуемости и юнит-экономике, потому что его ежедневная работа сводится к управлению стоимостью моделей. Внутренние PM-академии работают, когда стоят на симуляциях, аналитических лабораториях и воркшопах со стейкхолдерами, и проваливаются, когда сводятся к каталогу слайдов.
Уровень сдвигает акценты так же сильно. Начинающий PM выигрывает больше всего, укрепляя аналитику, понимание клиента, бизнес-моделирование и коммуникацию. PM среднего уровня переносит усилие на стратегию, управление портфелем, системы экспериментов и ИИ. Продуктовый лидер работает над коучингом, организационным дизайном и финансовыми фреймворками, потому что его рычагом становится качество решений команды.
Программы обычно проваливаются не от нехватки тем, а от перекоса. Учат инструментам, но не тому, как ими думать. Учат аналитике отдельно от стратегии. Считают ИИ делом инженеров, хотя это вопрос продукта. И ставят юнит-экономику в конец программы, хотя от неё зависит каждый компромисс.
Когда курс устаревает быстрее, чем заканчивается
Исследований, которые связывали бы формат обучения с результатами PM, публично нет, поэтому покупателю программы приходится мерить эффект самому. Проще всего сделать это той же оценкой: пройти тест до программы и через квартал после неё, а потом сравнить модули, которые программа обещала закрыть, с теми, что действительно выросли.
У ИИ-модулей есть уязвимое место: всё, что слушатель узнает о стоимости моделей, может устареть к выпуску. Цена запроса при равных возможностях модели быстро падает, и функция, убыточная в январе, к декабрю может стать прибыльной без единого изменения кода.
Для программы, которая учит прайс-листам, это приговор. Программа, которая учит методу, его переживёт: умножать стоимость запроса на распределение нагрузки, смотреть на самых дорогих пользователей, а не только на среднего, и пересчитывать решение при каждой смене цены. Правило для составителя программы: если упражнение перестаёт работать после смены цен у поставщика, это упражнение про прайс; если оно работает при любых ценах, это упражнение про продукт. Оставляйте второе, а цены берите свежие в день занятия.
Нужно ли быть технарём и нужен ли сертификат?
Навыки, которые решают сегодня, в порядке ежедневного использования: владение данными, продуктовое понимание ИИ, стратегическое моделирование, экспериментальная строгость и кросс-функциональное лидерство. Технарём быть не обязательно. Экспертиза в ИИ нужна на концептуальном и продуктовом уровне: PM, который не умеет оценить модель и прочитать её стоимость, не может взвесить построенные на ней фичи.
Сертификаты сохраняют ценность, когда подтверждают прикладной навык, проверенный на кейсах, и теряют её, когда награждают за заучивание словаря: рынок научился видеть разницу. Финансовое моделирование тренируют на сценариях, связывающих цену, затраты и ценность клиента, меняя по одному допущению за раз, чтобы увидеть, какое двигает маржу. Внутри компании PM обучают через симуляции, явные модели компетенций, аналитические лаборатории и оценку навыков.
Проверить любую программу можно одним вопросом к её составителям: в каком упражнении слушатель связывает продуктовое решение с посчитанным эффектом на удержание, маржу или стоимость модели и защищает этот компромисс перед людьми из других функций? Если такого упражнения нет, на выходе останутся сертификат и словарь.