Обязанности продакт-менеджера

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

Зачем нужен этот чек-лист

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

Этот чек-лист — попытка собрать обязанности по зонам, чтобы было удобно сверяться: что у тебя в работе, а что забыто. Полезно для трёх случаев. Первый — собеседование, когда нанимающий спрашивает «что входит в твои обязанности». Второй — онбординг, когда заходишь в новую компанию и не понимаешь, где границы. Третий — самопроверка, чтобы не зарываться в одной зоне и не забивать на остальные.

Не все обязанности одинаково актуальны во всех компаниях. В стартапе продакт делает всё, в корпорации часть зон забирает product marketing или strategy team. Адаптируй под свою реальность.

Лучше всего использовать этот чек-лист раз в квартал: пройтись по зонам, отметить «делал/не делал», увидеть провалы. Если три квартала подряд игнорируешь discovery — со стратегией скоро будут проблемы.

Стратегия и видение

  • Сформулировать видение продукта на горизонте 1–3 года.
  • Определить, какую проблему и для кого решаем, на каком рынке играем.
  • Поставить продуктовые цели на квартал и год (часто — через OKR).
  • Согласовать стратегию с бизнес-целями компании.
  • Анализировать рынок и конкурентов: следить, что появляется, что отмирает.
  • Принимать решения о выходе на новые сегменты и отказе от устаревших.

Это самая «невидимая» часть работы. Её эффект становится заметен через полгода-год, поэтому джуны её часто пропускают. Зря.

Ориентир по времени: сениор-PM тратит на стратегию около 15–20% недели. Мидл — 5–10%. Джун — почти ноль. Это не плохо, у каждого грейда свой фокус, но если в мидл-роли стратегия съедает 1% времени — это маркер того, что ею занимается кто-то ещё (директор, founder), и ты в продуктовых решениях не главный.

Discovery и работа с пользователями

  • Регулярно проводить интервью с пользователями (1–2 в неделю — здоровый ритм).
  • Слушать звонки в саппорт, читать тикеты и отзывы в сторах.
  • Сегментировать аудиторию: кто наши пользователи, как они отличаются.
  • Строить customer journey map для ключевых сценариев.
  • Формулировать гипотезы о проблемах и проверять их через интервью и данные.
  • Поддерживать research repository — место, где живут все инсайты команды.

Хороший продакт всегда может назвать топ-3 проблемы своих пользователей и подкрепить их цитатами из недавних интервью.

Антипатерн: «у нас уже всё про пользователей известно». Если это правда, то почему свежие фичи иногда ловят 15% активации вместо ожидаемых 50%? Discovery нужен не «когда непонятно», а постоянно, как чистка зубов.

Планирование и приоритизация

  • Вести продуктовый roadmap на 3–6 месяцев вперёд.
  • Поддерживать бэклог: добавлять новое, выкидывать устаревшее.
  • Приоритизировать задачи через RICE, ICE, Kano или просто здравый смысл.
  • Декомпозировать большие фичи на куски размером со спринт.
  • Писать PRD: проблема → цель → решение → метрики → риски.
  • Планировать релизы с учётом маркетинга и саппорта.

Признак зрелого продакта — он чаще выкидывает задачи из бэклога, чем добавляет.

Шаблон PRD на одну страницу:

Блок Что пишем
Проблема Кто страдает, в чём боль, как часто встречается
Цель Какую метрику двигаем и на сколько
Гипотеза Если сделаем X, то метрика вырастет потому что Y
Решение Краткое описание + ссылка на макеты
Скоуп Что входит, что не входит
Риски Что может пойти не так и как мы это поймём

Длиннее — обычно лишнее. Если PRD не помещается на одну страницу, фича декомпозируется плохо.

Доставка фич и работа с командой

  • Защищать приоритеты команды от внешнего шума.
  • Снимать блокеры — отвечать на вопросы по ТЗ, согласовывать решения, добывать данные.
  • Участвовать в груминге, планировании, ретро.
  • Принимать готовые фичи: проверять, что всё работает по ТЗ.
  • Координировать запуск с маркетингом, саппортом, юристами.
  • Готовить release notes и внутренние анонсы.

Продакт не управляет командой как босс, но он отвечает за то, чтобы команда выпускала правильные фичи в разумные сроки.

Чек-лист запуска фичи (минимальный):

  • макеты подтверждены;
  • AC прописаны и поняты QA;
  • метрика успеха зафиксирована и доступна на дашборде;
  • релиз-ноты для пользователей готовы;
  • саппорт предупреждён, готов FAQ для тикетов;
  • план отката если что-то сломается.

Если хоть один пункт пропущен — релиз-риск растёт.

Метрики и эксперименты

  • Знать ключевые метрики продукта: DAU/MAU, retention, конверсия, выручка.
  • Ежедневно или еженедельно мониторить главные показатели.
  • Проектировать A/B-тесты: гипотеза, метрика, размер выборки, длительность.
  • Анализировать результаты экспериментов: учитывать стат-значимость, не путать корреляцию с причиной.
  • Принимать решения по результатам теста: раскатываем, откатываем, итерируем.
  • Уметь самостоятельно достать цифру из дашборда или SQL — не ждать аналитика.

Если продакт не умеет читать данные — он не продакт, а «менеджер по согласованию макетов».

Базовый набор метрик, которые продакт должен знать наизусть про свой продукт:

  • DAU и MAU, stickiness DAU/MAU;
  • retention D1, D7, D30;
  • конверсия в ключевое действие;
  • ARPU или ARPPU, если есть монетизация;
  • время до первого ценного действия;
  • топ-3 канала привлечения и их CAC.

Это ориентиры — точный набор зависит от продукта. Главное — что ты знаешь свои числа, а не открываешь дашборд раз в квартал.

Коммуникация и стейкхолдеры

  • Регулярно апдейтить руководство о статусе и результатах.
  • Презентовать roadmap и итоги квартала.
  • Согласовывать решения с маркетингом, продажами, саппортом, юристами.
  • Поддерживать прозрачность: документация, статусы, открытые каналы.
  • Учить команду продуктовому мышлению — рассказывать «зачем», а не только «что».
  • Говорить «нет» — мягко, но обоснованно.

В корпорации эта зона занимает до 50% времени. В стартапе — 15–20%.

Шаблон еженедельного апдейта руководству:

  1. Что делаем сейчас и зачем.
  2. Что выпустили на этой неделе и какой эффект.
  3. Что планируем на следующую неделю.
  4. Где блокеры и что нужно от руководства.

Три-четыре буллета на каждый блок. Длиннее не читают.

Как обязанности меняются по грейдам

Грейд Главный фокус Что делает руками Что делегирует
Junior Доставка фичи Тикеты, AC, тесты, чтение метрик Стратегия, найм, переговоры
Middle Метрики и эксперименты Гипотезы, A/B, PRD, discovery Стратегия команды, бюджеты
Senior Стратегия и команда Видение, OKR, найм, ментворство Большую часть рутины джунам/мидлам
Lead / Group PM Координация нескольких продуктов Стратегия портфеля, найм PM, политика Конкретные фичи

На собеседовании эта таблица помогает не уйти не в свой грейд: джун, который начинает с «строю стратегию на 3 года», звучит подозрительно. Сениор, который три минуты рассказывает про написание AC, звучит как мидл.

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

  • Делить обязанности на «мои» и «не мои». Продакт отвечает за результат целиком. Если разработка не успевает — это проблема продакта, даже если технически отвечает тимлид.
  • Забывать про маркетинг и саппорт. Фича без коммуникации — это фича, о которой никто не узнал.
  • Игнорировать малые метрики. Не только DAU и выручка важны. Ошибки 500, время загрузки, NPS саппорта — всё это влияет на главные цифры через 2–3 месяца.
  • Переписывать roadmap каждую неделю. Если стратегия меняется так часто, её нет.
  • Не документировать решения. Через полгода никто не вспомнит, почему сделали именно так. Будут переделывать.
  • Сводить роль к написанию ТЗ. Это маркер, что ты исполняешь, а не управляешь продуктом.
  • Не закладывать время на discovery и думание. Если день закрыт встречами от 9 до 19, продуктовых решений ты не принимаешь.

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

FAQ

Какая обязанность продакта самая важная?

Понять, какую проблему мы решаем и для кого. Всё остальное — следствие. Если эта часть провалена, дальше не имеет значения, как круто построен процесс.

Должен ли продакт сам писать SQL и копать в данных?

Да, хотя бы базово. Иначе каждое решение упирается в очередь к аналитику, и скорость работы падает в разы. Не обязательно писать оптимизированные запросы, но JOIN, GROUP BY, оконки — must.

Кто пишет ТЗ для разработки — продакт или аналитик?

Обычно продакт пишет PRD (что и зачем), а технический ТЗ пишет тимлид или сам разработчик. В небольших командах эти роли совмещаются.

Кто принимает финальное решение по фиче?

По продуктовому решению — продакт, опираясь на данные и команду. По техническому — тимлид. По дизайну — дизайнер с консультацией продакта. Хорошая команда не имеет вертикали власти, но имеет ясные зоны ответственности.

Должен ли продакт участвовать в найме?

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

Сколько roadmap должен вести продакт одновременно?

Один — для своего продукта или направления. Если ведёшь 3 параллельных направления и в каждом по 5 целей — приоритизация сломана.

Должен ли продакт отвечать за маркетинг продукта?

За прoдуктовый маркетинг — частично да. Готовит позиционирование, релиз-ноты, помогает маркетингу понять ценность фичи. За кампании и закупку трафика — обычно отдельная команда.

Чем обязанности продакта отличаются от обязанностей product owner в Scrum?

В классическом Scrum product owner управляет бэклогом, AC и приёмкой. Это часть обязанностей продакта. Полный продакт-менеджер ещё отвечает за стратегию, метрики, рост и P&L. На практике в России роли часто склеиваются.


Готовишься к собесу на продакта или аналитика? Открой тренажёр Карьерника с вопросами по SQL, A/B-тестам и метрикам.