Технический продакт-менеджер vs обычный

Когда продукт называется техническим

«Технический продакт» в вакансии обычно означает одно из двух: либо продукт ориентирован на разработчиков (API, SDK, инфраструктура, дев-инструменты), либо это внутренняя платформа компании, которой пользуются другие команды. В обоих случаях пользователь — инженер, и без понимания его контекста принимать продуктовые решения сложно.

Если идёшь на такую роль с CV из B2C-продуктов и ни разу не открывал API-документацию — собес быстро это вскроет. И наоборот: если у тебя инженерный бэкграунд, B2C-собес может ощущаться чужим.

Простой тест: посмотри, кто платит за продукт и кто его настраивает. Если деньги несёт CTO или техлид, а интегрирует разработчик — это технический продукт. Если решение принимает маркетолог или конечный пользователь, а интерфейс рассчитан на клик мышью — это обычный продукт. Бывают гибридные истории: например, банковский B2B-кабинет, где интерфейс пользует бухгалтер, но рядом висит API для бухгалтерских систем. В таких продуктах часто два PM на разные сегменты.

Типичные вакансии «технического PM»: Platform PM, Developer Experience PM, API PM, Infrastructure PM, Data Platform PM, DX PM. Если в описании встречаются слова OpenAPI, gRPC, webhooks, observability, SLO — это маркер технической роли.

Что делает технический PM

Технический PM работает над одним из таких типов продукта:

• API и SDK для внешних разработчиков (платежи, антифрод, карты, AI-сервисы);
• инфраструктура: базы данных как сервис, очередь сообщений, observability;
• дев-инструменты: CI/CD, тестирование, мониторинг;
• внутренние платформы: фреймворки, UI-киты, шины данных.

Его обязанности:

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

Документы, которые ведёт технический PM: PRD с архитектурными деталями, API-спецификации, документация для разработчиков, гайды по миграции версий, RFC и ADR (architecture decision records).

Пример рабочей недели в платёжном API:

• понедельник: разбор фидбэка от 3 интеграторов, которые жалуются на путаницу в кодах ошибок;
• вторник: ревью OpenAPI-спеки нового эндпоинта 3DS, спор с инженерами про идемпотентность;
• среда: интервью с платёжным архитектором клиента, который пилотит интеграцию;
• четверг: отчёт по time-to-first-call и success rate за квартал;
• пятница: писал миграционный гайд для перехода с v2 на v3, согласовывал даты deprecation.

Что делает обычный PM

Обычный PM работает над B2C или B2B-продуктом для конечных пользователей: маркетплейс, банковское приложение, сервис подписки. Пользователь — человек, не инженер. Его обязанности:

• проектирует UX вместе с дизайном;
• работает с пользовательскими сценариями, jobs-to-be-done;
• запускает A/B-тесты на массовой аудитории;
• работает с метриками вроде retention, активации, ARPU;
• общается с маркетингом, продажами, поддержкой.

Главное отличие: обычный PM мало погружён в архитектуру и техническую интеграцию, его задача — UX и бизнес-метрики. Технический PM, наоборот, разбирается в архитектуре и контрактах.

Сравнение зон ответственности:

Зона	Обычный PM	Технический PM
Главный пользователь	Конечный человек	Разработчик, SRE, DBA
Главный артефакт	Прототип, PRD, Figma	OpenAPI-спека, RFC, doc-портал
Метрика успеха	Retention, конверсия, ARPU	Adoption, time-to-first-call, error rate
Канал обратной связи	Интервью, поддержка, NPS	GitHub issues, dev-survey, partner-chat
Партнёр-номер-один	Дизайнер	Архитектор / техлид

Какие технические скиллы реально нужны

Грубый чек-лист для технического PM:

• читает и пишет JSON, понимает базовый REST/GraphQL;
• умеет открыть Postman или curl, повторить кейс пользователя;
• понимает базовую архитектуру: что такое микросервис, очередь, кеш, асинхронный вызов;
• понимает SQL на уровне джойнов и оконных функций;
• может прочитать пулл-реквест и понять суть, не на уровне детальной ревизии кода;
• умеет читать логи и метрики (Grafana, OpenSearch, Sentry).

Этого достаточно. Писать прод-код самому не обязательно — это работа инженеров.

Что почти никогда не нужно: писать продакшн-сервис, оптимизировать алгоритмы под конкретное железо, настраивать кластер Kubernetes руками. Если в вакансии звучит такое — скорее всего, ищут техлида под видом PM.

Нужен ли опыт разработки

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

Опыт разработки даёт быстрый старт: понятна культура инженерной команды, не пугают слова «миграция», «contract-first», «consumer-driven». Но без навыков продуктового мышления, метрик и работы со стейкхолдерами одного инженерного бэкграунда мало.

Если опыта разработки нет — компенсируешь:

• читаешь техническую документацию популярных API,
• сам интегрируешь пару API в pet-проект,
• ходишь на инженерные митинги команды и слушаешь,
• учишь базовую теорию: HTTP-коды, идемпотентность, eventual consistency, бэкоф/ретраи.

Хорошее упражнение: возьми чужой публичный API (Stripe, Twilio, OpenAI, Telegram Bot) и сделай минимальную интеграцию. По ходу запиши, что было непонятно, что искал в Google, где ошибся. Это и есть developer experience глазами пользователя — главный навык технического PM.

Метрики технического PM

В отличие от B2C, где смотрят на DAU и retention, у технического PM свой набор показателей. Это ориентиры — конкретные пороги зависят от продукта и зрелости рынка.

Метрика	Что значит	Порядок ориентир
Time to first call	От регистрации до первого успешного API-вызова	Минуты для зрелых API, часы для сложных
Time to first value	До первого настоящего бизнес-сценария	От часа до недели
Activation rate	Доля интеграторов, дошедших до прода	30–60% для self-serve API
API success rate	Доля 2xx ответов от попыток	Целятся в 99,5%+ для платёжных
SDK adoption	Доля клиентов, использующих SDK, а не голый HTTP	Зависит от языка
Doc bounce	Доля ушедших с doc-портала без действия	Меньше — лучше

Под каждую метрику строится воронка: «получил токен → дёрнул sandbox → получил 200 → сделал прод-вызов». Где обвал — туда летит фокус продакта.

Что спрашивают на собесе технического PM

Типичные блоки:

• кейсы про API: «спроектируй эндпоинт для X»;
• вопросы по архитектуре: понимаешь ли разницу между REST и веб-сокетами, что такое idempotency, как работает rate limiting;
• метрики dev-tool продуктов: time to first call, success rate API, adoption SDK;
• работа с инженерной аудиторией: как собираешь обратную связь, как приоритизируешь технический долг;
• иногда SQL и базовые алгоритмы.

На обычном PM-собесе таких вопросов обычно нет. Зато больше кейсов по B2C-метрикам, активации и работе с массовой аудиторией.

Шаблон ответа на API-кейс «спроектируй эндпоинт для отправки уведомлений»:

1. Уточняешь сценарий: кто пользователь API, какой объём, синхронно или асинхронно.
2. Описываешь контракт: метод, путь, тело запроса, ответ, коды ошибок.
3. Проговариваешь идемпотентность: ключ запроса, поведение при повторе.
4. Обсуждаешь rate limiting и квоты.
5. Думаешь про асинхронность: webhook о доставке, polling, статусный эндпоинт.
6. Закрываешь версионированием и обратной совместимостью.

Главное на собесе — не написать «правильный» API, а показать ход мысли и понимание того, что разработчик-пользователь увидит первым.

Куда идти из технического PM

Распространённые треки:

• глубокая специализация: technical PM → senior technical PM → group PM в инфраструктурной команде;
• переход в обычный PM в B2B-продуктах с техническим оттенком (security, devops);
• переход в архитектурный или менеджерский трек (engineering manager, если есть кодовый бэкграунд).

Обратный переход в B2C-PM возможен, но требует пересборки CV: технический опыт сам по себе мало впечатляет нанимающего на B2C-роль, если нет кейсов работы с массовой аудиторией.

Хороший аргумент при переходе в B2C: «я работал с миллионами API-вызовов в день, понимаю масштаб и метрики». Плохой: «у меня был сложный технический продукт, поэтому я справлюсь с любым».

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

• Считать, что технический PM = инженер с продуктовыми задачами. Это всё ещё PM, и продуктовое мышление здесь главное.
• Идти на собес обычного PM с инженерным CV без подготовки B2C-кейсов.
• Игнорировать UX. Даже у API есть UX — это developer experience.
• Не уметь объяснить, как продукт меряется. Технический PM тоже работает с метриками adoption и удовлетворённости.
• Считать, что технический PM не нуждается в SQL. Очень нуждается.
• Путать PM и solution architect. PM отвечает за «зачем и для кого», архитектор — за «как».
• Уходить в архитектурные споры на собесе вместо продуктовой логики.

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

• Что должен знать продакт-менеджер
• Нужен ли SQL продакт-менеджеру
• Нужен ли Python продакт-менеджеру
• Продакт без технического фона
• Growth PM и обычный продакт

FAQ

Технический PM получает больше обычного?

По публичным данным с hh.ru и Habr Career, на 2025–2026 годы зарплаты сопоставимы. В отдельных нишах (инфраструктура, finance API) технический PM может опережать B2C-сегмент, но это ориентир, не правило.

Нужно ли уметь кодить?

Уметь читать и понимать код полезно. Уметь писать прод-код — нет. Минимум — Python или JS на уровне скриптов и быстрой проверки гипотез через API.

Можно ли быть техническим PM без опыта разработки?

Можно. Многие приходят из аналитики, бизнес-анализа или поддержки. Главное — глубоко погрузиться в технический контекст продукта.

Чем заняться pet-проектом, чтобы прокачаться?

Интегрируй чужой API в простое приложение: оплата, отправка SMS, AI-вызов. Прочувствуешь developer experience с обеих сторон.

Что почитать по проектированию API?

Документации Stripe, Twilio, GitHub — золотой стандарт. Читать их публичные доки полезнее любого учебника. Из книг — «Designing Data-Intensive Applications» Клеппмана, чтобы говорить с архитекторами на одном языке.

Чем технический PM отличается от Platform PM?

Platform PM почти всегда работает с внутренней инфраструктурой компании, его пользователи — внутренние команды. Технический PM может вести и внешний API, и внутреннюю платформу. Platform PM — частный случай технического PM.

Технический PM решает архитектурные задачи?

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

Подойдёт ли техническому PM работа в стартапе на 10 человек?

Если в стартапе нет инженерной команды — нет, продукта без инженеров не бывает. Если 3–5 разработчиков и есть API-сегмент клиентов — да, технический PM на ранней стадии часто закрывает ещё и developer relations.

---

Готовишься к собесу на технического PM — открой тренажёр Карьерник и прокачай метрики, SQL и продуктовые кейсы.