Hard skills продакт-менеджера: список с приоритетами

Зачем продакту hard skills

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

Hard skills продакта — это не «уметь писать код». Это уметь работать с данными, понимать продуктовые метрики, ставить эксперименты и считать экономику. Дальше — конкретный список с приоритетами.

Базовый принцип отбора навыков: что чаще всего проверяют на собесе и что чаще всего нужно в ежедневной работе. Если навык не попал ни в одну категорию — его можно учить позже. Например, R и BigQuery не входят в must-have для большинства PM, в отличие от SQL и базовой статистики.

Продуктовая аналитика и метрики

Базовый навык: знать, какие метрики нужны для своего продукта, и уметь их декомпозировать. DAU, WAU, MAU, retention, churn, LTV, ARPU, CR — это не просто буквы, а инструменты диагностики продукта.

Что должен уметь продакт:

• Подобрать North Star Metric — одну метрику, которая отражает реальную ценность продукта.
• Декомпозировать её на драйверы. DAU = новые + вернувшиеся + удержанные.
• Различать leading и lagging метрики. Retention 30 дней — lagging, активация в первый день — leading.
• Читать когортный анализ и не путать его со срезом «по дням».
• Различать метрики продукта (DAU, retention) и бизнеса (выручка, маржа).
• Видеть, когда метрика «обманывает» — например, средний чек растёт, потому что отвалились дешёвые клиенты.

Если продакт не понимает разницу между retention и churn — это уровень джуна. Сильные продакты ещё умеют выбирать «правильное окно»: D1/D7/D30 или D14, в зависимости от частоты использования продукта.

Шаблон декомпозиции метрики «выручка»:

Выручка = DAU × конверсия в платёж × средний чек

DAU = новые + возвращающиеся + удержанные
Конверсия в платёж = онбординг × предложение × барьеры платежа
Средний чек = микс тарифов × апселы × скидки

Так любая «упала выручка» превращается в конкретный набор гипотез, а не «надо что-то делать».

SQL и работа с данными

SQL — обязательный навык для продакта в 2026 году. Не на уровне дата-инженера, но достаточно, чтобы самому достать цифры, не дёргая аналитика по каждой мелочи.

Минимум:

• SELECT, WHERE, GROUP BY, JOIN.
• Оконные функции (ROW_NUMBER, LAG, SUM OVER).
• CTE (WITH).
• Агрегаты с CASE WHEN.
• date_trunc и работа с датами.
• COALESCE, NULLIF для безопасной работы с null.

-- ретеншен D7 по когортам
WITH cohorts AS (
  SELECT user_id, MIN(DATE(created_at)) AS cohort_date
  FROM events GROUP BY user_id
),
returns AS (
  SELECT c.cohort_date, COUNT(DISTINCT e.user_id) AS retained
  FROM cohorts c
  JOIN events e ON e.user_id = c.user_id
   AND DATE(e.created_at) = c.cohort_date + INTERVAL '7 day'
  GROUP BY 1
)
SELECT cohort_date, retained FROM returns;

Без SQL продакт зависит от очереди в команду аналитики и теряет скорость.

Тонкие места, на которых валятся:

-- плохо: integer / integer → 0 в PostgreSQL
SELECT 5 / 20 * 100;

-- хорошо
SELECT 5::NUMERIC / 20 * 100;

-- плохо: оконку нельзя в WHERE
SELECT * FROM t WHERE ROW_NUMBER() OVER (...) <= 3;

-- хорошо: через CTE
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t)
SELECT * FROM ranked WHERE rn <= 3;

Всегда оборачивать знаменатель в NULLIF(denominator, 0) — иначе в делении словишь ошибку, которая порушит дашборд.

A/B-тесты и эксперименты

Любая фича на масштабе — это эксперимент. Продакт должен уметь:

• Сформулировать гипотезу: метрика, ожидаемый эффект, MDE.
• Посчитать размер выборки и длительность теста.
• Понимать ошибку первого и второго рода, p-value, мощность.
• Читать результаты и не делать выводы по пику первой недели.
• Отличать практическую значимость от статистической.
• Знать защитные метрики и проверять их в каждом тесте.

Самые частые ошибки на собесе: не учитывать сезонность, смотреть на промежуточные результаты и принимать решения, путать статистическую значимость с практической.

Шаблон ответа на вопрос «как ты дизайнишь A/B-тест»:

1. Гипотеза: проблема → решение → ожидаемая метрика и эффект.
2. Аудитория и сплит.
3. Главная и защитные метрики.
4. MDE и расчёт выборки.
5. Длительность не меньше 2 недель.
6. Что делаем при +/0/–.

Если на собесе ответ на этот вопрос звучит «возьмём 50 на 50 и через неделю посмотрим» — это сразу −1 в копилку.

Пользовательские исследования

Цифры показывают «что», но не «почему». Чтобы понять «почему», нужны качественные исследования: глубинные интервью, юзабилити-тесты, surveys.

Что должен уметь:

• Сформулировать гипотезу под исследование.
• Провести интервью без наводящих вопросов.
• Отделить мнение от поведения. «Я бы пользовался» ≠ «я буду пользоваться».
• Сводить выводы из интервью в инсайты, а не цитаты.
• Спроектировать опрос так, чтобы не получить мусор (короткие вопросы, нет двойных трактовок).
• Выбрать правильный метод: интервью, юзабилити-тест, опрос, наблюдение.

Сильный продакт умеет провести 5 интервью за неделю и достать из них больше, чем команда ресёрча за месяц опросов.

Антипатерны вопросов в интервью:

• «А вам бы понравилось, если…» — наводящий, всегда «да».
• «Вы бы заплатили за…» — гипотетический, не предсказывает поведение.
• «Что для вас важно?» — слишком широко.

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

Юнит-экономика

Продакт без понимания юнит-экономики — это художник, который не считает стоимость красок. Можно сделать красивый продукт, который убыточен на каждом пользователе.

Минимум:

• CAC — стоимость привлечения.
• LTV — ценность пользователя за жизненный цикл.
• Payback — срок окупаемости.
• Маржа на пользователе и на платящем.
• LTV/CAC как ориентир здоровья экономики (часто называют 3:1, но это эвристика, не закон).
• Contribution margin — что остаётся после переменных издержек.

Продакт, который умеет считать unit-экономику, может сам обосновать запуск фичи в деньгах, а не «потому что классно».

Простой пример:

CAC = 1500 руб
ARPU в месяц = 200 руб
Маржа = 70% → contribution = 140 руб/мес
Payback = 1500 / 140 ≈ 11 месяцев
LTV (при retention в среднем 18 мес) = 140 × 18 = 2520 руб
LTV/CAC = 2520 / 1500 = 1.68 → пограничная экономика

Если LTV/CAC <1 — продукт убыточен. 1–2 — рабочая, но рискованная. 3+ — здоровая. Это ориентиры, не строгий закон.

Приоритеты по уровню

Ориентир, который часто встречается в требованиях:

Уровень	Приоритеты hard skills
Junior	Метрики, базовый SQL, чтение дашбордов, фреймворки приоритизации
Middle	A/B-тесты, юнит-экономика, исследования, продвинутый SQL
Senior	Стратегия, метрики на уровне бизнеса, дизайн экспериментов, монетизация
Lead	Системное мышление, метрики команд/портфеля, найм и менторство

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

План прокачки на 12 недель

Если идёшь с нулевого уровня и хочешь дойти до уверенного middle:

• Недели 1–2. Метрики: AARRR, DAU/MAU, retention, ARPU, LTV. Прочитать одну книгу по продуктовой аналитике и одну по юнит-экономике.
• Недели 3–4. SQL базовый: select-where-group-join. Решить 30 задач уровня easy.
• Недели 5–6. SQL средний: оконные функции, CTE, когорты. Решить 30 задач уровня medium.
• Недели 7–8. A/B-тесты: гипотеза, MDE, ошибка 1-го и 2-го рода, мощность. Дизайн 3 учебных тестов.
• Недели 9–10. Юнит-экономика: разобрать 5 публичных кейсов, посчитать CAC/LTV/payback своими руками.
• Недели 11–12. Кейсы на собес: декомпозиция метрик, продуктовое мышление, mock-собесы.

15–30 минут в день — этого хватит. Хуже, когда учишь 4 часа в воскресенье и забываешь к среде.

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

• Учить всё подряд. Лучше глубоко SQL и метрики, чем по верхам всё.
• Путать инструменты и навыки. Знать Amplitude — не значит уметь в продуктовую аналитику.
• Игнорировать SQL. «Я продакт, у меня аналитик» — на собесе не работает.
• Учить теорию без практики. A/B по учебнику — одно, дизайн реального теста — другое.
• Зубрить формулы LTV. Важнее понимать, что они показывают и где ломаются.
• Игнорировать качественные методы. Без интервью гипотезы становятся «потолочными».
• Не считать защитные метрики. Видишь рост главной — а churn вырос.
• Учиться без коллег и обратной связи. Без mock-собесов и разборов идёшь на реальный собес неподготовленным к давлению.

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

• Soft skills продакт-менеджера
• Продакт и эксперименты
• Продакт и исследования
• SQL для аналитика
• A/B-тесты и статистика

FAQ

Нужен ли продакту Python?

Не обязательно. SQL покрывает 90% задач. Python — плюс, особенно если работаешь с ML-продуктом или хочешь делать сложные расчёты сам.

Какой уровень SQL достаточен для продакта?

Уверенно писать запросы с JOIN, GROUP BY, оконными функциями и CTE. Запросы на 30–50 строк — нормально. Оптимизация и индексы — задача аналитика/инженера.

Что важнее — hard или soft skills?

На джуне — примерно поровну, на собесе чаще валят hard. На senior — soft становятся важнее, потому что hard уже базово ожидаются.

Как готовиться к hard-секции собеса на продакта?

Решать кейсы по метрикам, тренировать SQL, разбирать дизайн A/B-тестов. Ежедневная практика по 20–30 минут даёт результат за пару месяцев.

Сильно ли отличаются требования по компаниям?

Да. В крупных IT — больше про эксперименты и аналитику. В стартапах — про скорость, юнит-экономику и discovery. В B2B — про работу с клиентами и интеграции.

Можно ли стать PM без знания SQL?

В небольших стартапах — да. В средних и крупных компаниях SQL спросят на собесе почти всегда. Без него выбор позиций сильно сужается.

Стоит ли учить ML, чтобы быть конкурентоспособным?

ML — для специфичных продуктов (рекомендательные системы, AI-ассистенты). Для большинства PM достаточно понимать, что ML может, а не уметь его настраивать.

Где взять реальные данные для тренировки SQL?

Локальный PostgreSQL + публичные датасеты (Northwind, Pagila, Kaggle). Альтернатива — sqlbolt, sqlzoo, leetcode. Тренироваться надо до автоматизма.

---

Прокачать hard skills продакта — открой Карьерник: SQL, метрики, A/B и продуктовые кейсы в формате коротких тренировок.