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

Зачем сравнивать эти роли

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

Если зайти не в ту роль — потеряешь год на не своих задачах. Ниже разбор, чем БА действительно отличается от PM, где они пересекаются, как смотреть на зарплаты и кому какой трек подходит.

Что делает бизнес-аналитик

БА — мост между бизнесом и разработкой. Его задача — превратить размытое «нам надо ускорить процесс согласования заявок» в чёткое техническое задание, которое команда сможет реализовать. В обязанностях:

• собирает требования у заказчика, проводит интервью;
• описывает бизнес-процессы (например, в нотации BPMN);
• пишет ТЗ или функциональные спецификации;
• проектирует логику работы системы вместе с архитектором;
• сопровождает разработку, отвечает на вопросы команды;
• участвует в приёмке.

БА чаще встречается в B2B, корпорациях, банках, госсекторе, на проектах внедрения. Инструменты: Confluence, Jira, BPMN-редакторы, иногда SQL для проверки данных, реже — BI-инструменты.

Главное в работе БА — детально и точно описать систему. Если в требованиях неоднозначность, проект зайдёт в тупик на тестировании.

Типовой артефакт БА — функциональная спецификация: акторы, сценарии, бизнес-правила, поля, валидации, состояния. Документ может быть на 30–50 страниц для среднего модуля. Это нормальная плотность для крупной корпорации.

Что делает продакт-менеджер

PM отвечает за продукт целиком — от «зачем эта фича вообще» до «выросла ли метрика после запуска». В обязанностях:

• определяет продуктовую стратегию,
• работает с метриками и unit-экономикой,
• ставит и проверяет гипотезы через A/B-тесты,
• общается с пользователями и собирает обратную связь,
• защищает приоритеты перед бизнесом,
• ведёт запуски фич и анализ результатов.

PM чаще встречается в продуктовых компаниях: маркетплейсы, сервисы, мобильные приложения, SaaS. Инструменты: PostHog/Amplitude/Mixpanel, SQL, Figma для прототипов, Notion/Confluence для PRD.

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

Типовой PRD продакта — 2–4 страницы: проблема, цель, гипотеза, метрика успеха, скоуп, риски. Дальше детали уходят в макеты, тикеты и обсуждения. Меньше документа, больше итераций.

Где роли пересекаются

И БА, и PM:

• работают с требованиями;
• общаются со стейкхолдерами;
• декомпозируют большие задачи;
• работают с данными (хотя у PM этого больше);
• участвуют в приоритизации.

В небольших компаниях один человек закрывает обе роли. В вакансиях это иногда так и звучит: «продакт/бизнес-аналитик». В крупных продуктовых командах роли разделяются: БА на интеграциях с внешними системами, PM — на пользовательских сценариях и метриках.

Сравнение по ключевым осям:

Ось	БА	PM
Главный вопрос	Как именно это будет работать	Что и для кого мы вообще делаем
Главный артефакт	Функциональная спецификация, BPMN	PRD, дашборд метрик
Метрика успеха	Сданная и принятая система	Изменение продуктовой метрики
Тип компании	B2B, банки, телеком, госсектор	Продуктовые компании, SaaS, маркетплейсы
Главный инструмент	BPMN, ER-диаграммы, требования	A/B-тесты, аналитика, SQL
Кому защищает решения	Заказчику и архитектору	Пользователю и бизнесу

Зарплаты и рынок

По публичным данным с hh.ru и Habr Career, на 2025–2026 годы:

• зарплаты PM и БА на джуниор-уровне примерно сопоставимы;
• на мидл-уровне PM в продуктовых компаниях зачастую опережает БА в среднем сегменте;
• БА в крупном корпоративном секторе (банки, телеком) держит конкурентные грейды и предлагает более стабильную работу;
• сениор-PM в успешных продуктовых компаниях имеет потолок выше, чем сениор-БА, за счёт привязки части дохода к результатам продукта (опционы, бонусы).

Это ориентиры, не гарантии. Конкретный оффер зависит от компании, города и опыта.

Ещё один фактор — устойчивость роли. БА в банке — менее волатильная позиция: проекты длинные, увольнения редкие. PM в продуктовой компании больше зависит от роста бизнеса: на падении рынка часть PM-команд режут первыми. Учитывай это при выборе.

Как перейти из БА в PM

Распространённый трек. Что нужно докрутить:

• метрики продукта: DAU, MAU, retention, ARPU, LTV, CAC;
• A/B-тесты и базовая статистика (p-value, мощность, MDE);
• SQL не на уровне «селект из одной таблицы», а на уровне когорт и оконных функций;
• продуктовое мышление: умение сформулировать проблему, гипотезу, метрику успеха;
• кейсы по росту и активации.

Самый быстрый способ собрать пробелы — взять конкретные задачи на собесы PM и порешать. Что не получается — закрываешь точечно.

Минимальный план на 2–3 месяца:

1. Прочитать «Inspired» Кагана и пару продуктовых блогов на русском.
2. Прорешать 50+ вопросов по продуктовым метрикам и A/B.
3. Подтянуть SQL до уровня оконок и когорт.
4. Сделать кейс на текущей работе: предложить продуктовую метрику, посчитать, защитить.
5. Пройти 5–7 собесов на джун/мидл PM, получить обратную связь.

Что выбрать новичку

Грубо:

• если нравятся чёткие процессы, документация, работа с интеграциями и требованиями — БА;
• если нравится принимать решения по продукту, копать в данные, общаться с пользователями — PM.

Если ещё не определился — попробуй обе роли через стажировку или проект. На собесе быстро становится понятно, какие задачи откликаются, а какие — мука.

Простой тест на «своё»: прочитай две статьи — одну про BPMN-нотации и моделирование процессов, вторую про A/B-тесты и продуктовые метрики. Где у тебя возникло «о, интересно» — туда и иди.

Как читать вакансии

Тайтл в шапке мало что значит. Смотри на блок «обязанности».

Маркеры PM в описании:

• «работа с метриками retention, активации, выручки»;
• «гипотезы, A/B-тесты, эксперименты»;
• «приоритизация бэклога, OKR»;
• «интервью с пользователями»;
• «продуктовая стратегия».

Маркеры БА:

• «BPMN, UML, ER-диаграммы»;
• «функциональные спецификации, ТЗ»;
• «работа с требованиями, согласование с заказчиком»;
• «анализ бизнес-процессов»;
• «интеграции с внешними системами».

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

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

• Идти на собес PM с портфолио из ТЗ. PM-собес про метрики, а не про BPMN-схемы.
• Идти на собес БА без знания нотаций и без опыта работы с требованиями. Это базовая часть роли.
• Считать, что БА — это «PM попроще». Это другая роль с другой ценностью на рынке.
• Не уточнять, какие задачи реально лежат на роли в конкретной компании. Тайтлы обманчивы.
• Решать «через зарплату, что больше». В разных сегментах рынка картина разная.
• Прыгать в PM, потому что «модно», без интереса к данным и метрикам. Через полгода захочется обратно.

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

• Что должен знать продакт-менеджер
• Product Manager и Product Owner: разница
• Нужен ли SQL продакт-менеджеру
• Продакт без технического фона
• Метрики продукта: DAU, MAU, ARPU

FAQ

Может ли БА стать PM?

Да, переход типичный. Достаточно докрутить метрики, SQL, A/B и продуктовое мышление, и это уже плюс-минус готовый PM с дополнительной силой в работе с требованиями.

Может ли PM стать БА?

Технически да, но это редкий шаг назад по рынку, если речь не про переход в крупный B2B на проект внедрения с понятным грейдом.

В какой роли быстрее карьерный рост?

В продуктовых компаниях у PM зачастую более крутая траектория — за счёт прямой связи с метриками продукта и бонусами от успехов.

Кому БА подходит больше?

Тем, кто любит работать с документацией, нотациями, чёткими требованиями, интеграциями и системной работой. Меньше неопределённости, больше структуры.

Что лучше учить первым — БА или PM-стек?

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

Чем БА отличается от системного аналитика?

Системный аналитик ближе к разработке: проектирует API, базы данных, сервисы. БА — ближе к бизнесу. На практике границы размыты, но ключевой маркер — где живёт основной артефакт. У БА — в Confluence, у системного аналитика — в спеках интеграций.

Стоит ли указывать оба тайтла в резюме?

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

Кто из них чаще работает удалённо?

Оба формата встречаются. БА чуть чаще привязан к офису из-за работы с заказчиками и проектной спецификой, PM в продуктовых компаниях чаще распределён.

---

Готовишься к собесу на PM или хочешь перейти из БА — открой тренажёр Карьерник и прокачай метрики, A/B и SQL.