Вакансия PM пятилетней давности просила уметь писать требования и ладить со стейкхолдерами. Сейчас от того же продакта ждут большего. Он сам читает когорты, проектирует эксперимент и объясняет ML-команде, почему модель «достаточно хороша» или нет. А потом сводит всё это в одно решение.
Ранние модели обучения делали ставку на маркетинг, требования и работу со стейкхолдерами. Теперь к ним добавились данные о поведении пользователей, экономика продукта, понимание того, что умеют и чего не умеют модели ИИ, исследование клиентов (discovery) и короткие циклы обучения. Список длинный, и в этом главная опасность: его хочется пройти целиком.
Три дуги нужны, чтобы найти одно узкое место
Путь PM удобно разложить на три дуги: Основы, Ключевую практику и Продвинутую стратегическую компетентность. Деление не самоцель. Оно помогает увидеть, какая именно компетенция сейчас держит вас на месте.
Каждая дуга лечит свои типичные проблемы. Продакт не понимает границ роли, задачи провисают между командами, навыки не совпадают с тем, что нужно. Книга Линды Горчелс «The Product Manager's Handbook» даёт карту умений. Материалы Amplitude по аналитике показывают, как проверить эти умения на практике.
Первый год: discovery, метрики и письмо должны стать рефлексом
Эта дуга для тех, кто входит в профессию или переходит в неё из дизайна, инженерии, маркетинга, поддержки, операционного управления или собственного дела. Задача первого года звучит скромно: решать типовые задачи самостоятельно и объяснять, почему выбран именно этот подход.
Начинается всё с того, как продукт живёт во времени и кому он вообще нужен. Здесь осваивают жизненный цикл продукта, ценностное предложение и точную постановку проблемы. Учатся смотреть на решение глазами клиента, а не команды, и различать сегменты вместо усреднённого «пользователя».
Сюда же относятся модели кросс-функционального взаимодействия: в одиночку PM не делает почти ничего. Базовые тексты не случайно называют продакта мини-CEO продукта, который сводит воедино множество разнородных решений. Эту мысль подробно разворачивает Горчелс.
Дальше идут рабочие инструменты. Дерево возможностей (opportunity tree), Jobs To Be Done и модель Кано помогают решить, что делать первым. Документ с требованиями (PRD) учит описывать замысел так, чтобы его нельзя было понять двумя способами. Дорожная карта показывает, куда движется продукт, и не превращается в список обещаний. Agile, Kanban и user stories полезно понимать с позиции PM, а не как ритуал команды.
Рядом с инструментами стоит привычка сначала проверить, а потом строить. Интервью с пользователями, гипотезы, список своих допущений и быстрые прототипы складываются в один навык: не верить себе на слово. Стив Бланк в подходе customer development ставит поиск раньше разработки. Поэтому исследование клиентов здесь входит в основу.
Минимальная грамотность в данных нужна, чтобы никто не выдал желаемое за факт. На этом уровне держат в поле зрения три сигнала:
- метрики активации, удержания и вовлечённости, по которым видно, приживается продукт или нет;
- воронки и когорты, которые показывают, на каком шаге теряются пользователи;
- разницу между метриками поведения и «метриками тщеславия», которые красиво растут и ничего не значат.
Amplitude не зря ставит метрики в центр работы продакта. Технический минимум скромный: базовый SQL (select, join, group by) и умение читать графики. Тогда данные можно смотреть самому, не дожидаясь аналитика.
Последний кирпич первого года: умение писать. PM почти никогда не отдаёт приказы. Поэтому уже сейчас он учится писать ясные брифы, спецификации и короткие записки. Учится договариваться с коллегами, спокойно поднимать проблему на уровень выше и собирать разрозненные мысли в связный рассказ. Так начинается умение вести людей без формальной власти.
Проверить, что первый год прошёл не зря, можно по пяти вопросам:
- можете ли вы назвать сегмент, проблему и метрику для каждой задачи в своём бэклоге;
- писали ли вы сами SQL-запрос, который изменил чьё-то решение;
- было ли интервью с пользователем, после которого вы отказались от своей гипотезы;
- читал ли инженер ваш PRD без уточняющих вопросов о том, что строить;
- можете ли вы отличить метрику, которая растёт сама, от метрики, которую двигает ваша работа.
Три «да» из пяти значат, что основа на месте. Два и меньше значат, что переходить к следующей дуге рано, сколько бы курсов ни было пройдено.
От года до пяти лет ремесло проверяется цифрами
На этом отрезке PM отвечает за всю проблему целиком, а не за отдельные задачи. Он всерьёз осваивает аналитику и учится работать с ИИ. За свои цифры он теперь отвечает сам.
Сначала нужно построить систему метрик и настроить их сбор: какие события пишем, в каком виде и по какому плану. Потом выбрать главную метрику продукта (North Star). Важно отличать метрики, которые предсказывают будущее, от тех, что фиксируют уже случившееся. Сюда же относятся кривые удержания, разбор роста на новых, вернувшихся и ушедших пользователей и аналитика по отдельным функциям. На практике PM сам собирает дашборды, делит пользователей на группы по поведению и честно взвешивает метрики, которые почти всегда тянут в разные стороны.
Продакт сегодня всё время что-то тестирует. Отличать совпадение от причины приходится постоянно, и часто в спешке. Прежде чем выкатить изменение в продукт, эксперимент проходит несколько шагов:
- Сформулировать гипотезу, которую реально проверить и опровергнуть.
- Посчитать, сколько нужно пользователей, чтобы тест заметил эффект.
- Выбрать защитные метрики, чтобы не выиграть в одном показателе и не обрушить другой.
- Выбрать формат: обычный A/B-тест, тест нескольких вариантов сразу или поочерёдное включение по времени.
- Держать в поле зрения все тесты сразу и понимать, какой вывод о причине из них можно сделать.
Иначе чем больше тестов, тем больше ложных выводов. Самая известная ошибка: смотреть на результаты до конца теста и останавливать его, как только график позеленел. Её разбирают Johari и соавторы в статье «Peeking at A/B Tests» (KDD 2017). Поэтому правило простое: когда остановить тест, решают до запуска.
Писать модели PM не обязан, но должен понимать, как они устроены. Как машинное обучение работает в общих чертах. Почему модель может отвечать медленно, стоить дорого, со временем портиться или ошибаться в пользу одной группы. Где ИИ решает реальную задачу, а где его добавляют ради галочки. Когда модель «достаточно хороша» и как это проверить.
Сюда же относятся поведение людей в интерфейсах с ИИ, риски безопасности и этики и типичные продукты на ИИ: рекомендации, классификаторы, ИИ-помощники, ответы по базе знаний компании (RAG), прогнозы. С таким багажом продакт говорит с ML-командой на равных и не тянет модель туда, где она не нужна.
Нужна и техническая база. PM понимает, как сервисы обмениваются данными через API, как данные идут по системе и почему сложные системы ломаются. Он читает схемы архитектуры, видит зависимости и умеет договариваться с инженерами об ограничениях. Это роль связующего звена, о которой пишут крупные руководства по продакт-менеджменту.
К этому же отрезку относится экономика продукта. Сколько приносит и сколько стоит один клиент. Как назначить цену и собрать тарифы. Чем бесплатный базовый план отличается от оплаты за использование. Что такое маржа, LTV (сколько клиент принесёт за всё время), CAC (сколько стоит его привлечь), срок окупаемости и размер рынка. Без этого монетизация превращается в набор догадок.
Одна формула окупается быстрее остальных. Срок окупаемости CAC = CAC / (ARPU × валовая маржа). Допустим, привлечение клиента стоит 600 долларов, клиент платит 100 долларов в месяц, валовая маржа 60%. Получается 600 / 60 = 10 месяцев. Хорошо это или плохо, решает срок жизни клиента: при 30 месяцах он трижды возвращает свой CAC, при 12 едва окупается. Скидка 20% на тариф при той же марже в процентах сдвигает срок к 12,5 месяца. Если же себестоимость обслуживания в долларах не изменилась, срок вырастает до 15 месяцев, и запас исчезает.
Приказывать продакт обычно не может, поэтому держит всё ясностью и договорённостями. Он решает, что делать первым, договаривается об объёме работ, следит за рисками и готовностью к релизу, вместе с инженерами и дизайнерами проверяет качество. Книги о продакт-менеджменте повторяют одно: больше всего продакту мешают размытые задачи и вопросы, которые провисают между командами.
После пятого года вопросы теряют готовые ответы
Этот отрезок готовит к старшим ролям: экспертным (Senior PM, Lead PM, Principal PM) и управленческой (PM Manager). Траектории у них разные, но общее одно: готовых ответов становится всё меньше.
Senior PM смотрит шире одного продукта. Он видит, как продукты компании связаны между собой, что можно сделать общим для всех и куда вложиться в первую очередь. Он считает отдачу с учётом риска. Ценится умение просчитать несколько сценариев, заметить, куда движется рынок, разобрать конкурентов и понять регулирование. И отличить большую ставку на будущее от небольшого улучшения.
На старших ролях PM решает, как ИИ даёт продукту преимущество. Он планирует развитие модели, решает, какие данные собирать, на чём всё будет работать и какие правила ответственного ИИ соблюдать. И отвечает за метрики модели: долю верных ответов (accuracy), полноту (recall), скорость ответа и цену одного запроса.
Лидер задаёт и то, как работает вся команда продактов. Он наставляет младших, описывает уровни навыков, собирает сообщество, запускает внутреннее обучение и улучшает то, как в компании принимают решения. От зрелости этой команды напрямую зависят результаты компании.
На верхних уровнях PM учится говорить с руководством на его языке. Он строит рассказ, который выдержит разговор с инвестором. Объясняет компромиссы так, чтобы их можно было взвесить. Формулирует, каким продукт должен стать через несколько лет. Так продуктовое ремесло превращается во влияние на решения топ-менеджмента.
Сверяйтесь со своей дугой
Полный список пугает, поэтому проще сверяться со своей дугой. Если вы ищете первую работу, важнее всего продуктовое мышление, основы исследования клиентов, воронки и аналитика, требования, дорожная карта и умение общаться.
Если вы уже в профессии, фокус смещается на сложные метрики, эксперименты, понимание ИИ, техническую базу, монетизацию и работу с другими командами. Если вы целитесь в Principal или директора, на первый план выходят стратегия для нескольких продуктов, расчёт сценариев, место ИИ в продукте и разговор с топ-менеджментом.
Если выбирать один навык на ближайший год, берите понимание ИИ вместе с умением грамотно ставить эксперименты. Новичку не нужен инженерный уровень, но техническая интуиция обязательна: API, азы архитектуры, поведение моделей. Экспериментирование осваивается через структурированную практику, наставничество и инструменты, а не через чтение. PM среднего уровня быстрее всего растёт, когда берёт на себя метрики, монетизацию и AI-решения целиком.
Ориентироваться помогают матрицы компетенций, то есть таблицы навыков по уровням. Они дают ясность ожиданий: видно, куда расти и что подтянуть. Без них сложно растить команду продактов системно.
Двенадцать недель с тестом в конце каждого блока
Дуги рассчитаны на годы, но тот же порядок укладывается в двенадцать недель вечерних занятий, если закрывать каждый блок одним из тестов netpy. В каждом тесте 80 вопросов, разбитых по модулям, поэтому результат показывает слабые модули, а это полезнее общего балла.
Первые три недели уходят на слой метрик: воронки, когорты, North Star и события под ней. В конце проходите Mastering Product Analytics и смотрите на модули про воронки, когорты и таксономию событий. С четвёртой по шестую неделю идут эксперименты: гипотеза, размер выборки, защитные метрики, ранний взгляд на результаты. Рассчитайте размер выборки для одного теста в своём продукте, даже если запускать его не будете, и перепройдите модуль экспериментов того же теста.
Седьмая и восьмая недели отданы discovery и требованиям: пять интервью по одной проблеме и один переписанный PRD, а проверкой служит тест Product Management. Если команда работает по Scrum или Kanban, сюда же стоит добавить Agile Coach Assessment. Девятая и десятая недели про экономику: окупаемость, вкладная маржа, LTV и CAC на цифрах своего продукта. Проверка здесь двойная: модуль атрибуции в Mastering Product Analytics и модуль маркетинговой аналитики в Marketing & Growth Skill. Последние две недели про ИИ: как проверять модель до запуска и на живых пользователях, что такое точность (precision) и полнота (recall), сколько стоит один запрос к модели. Итоговая проверка: AI Product Management.
Каждый тест стоит пройти дважды, до блока и после. Если слабые модули после блока так и остались слабыми, блок продлевают на неделю и к следующему не переходят.
Слой метрик нужен раньше всего остального
Из всего списка раньше других нужен слой метрик: воронки, когорты, удержание и привычка формулировать метрику до того, как о ней начнут спорить. На него опирается почти всё остальное. Без него эксперимент нечитаем, а монетизация превращается в угадайку. Здесь же проходит граница между PM, который читает дашборд, и тем, кто его проектирует.
Попытка расти по всем фронтам сразу обычно разбивается именно об это. Вперёд двигает один навык из вашей дуги: тот, что сейчас мешает принять следующее решение. Отработайте его на реальной задаче, пока не сможете защитить свой выбор цифрами.