Нужен ли SQL продакт-менеджеру и как его использовать

Короткий ответ

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

В эпоху AI планку можно опустить ещё ниже: ChatGPT или Claude напишут запрос за тебя, твоя задача — понимать, что в нём происходит, и проверять на здравый смысл. Без этого ты не разберёшься, врёт ли тебе модель.

В вакансиях SQL чаще проходит как «приветствуется». На собесе в больших продуктовых компаниях простую задачу дают почти всегда, но это уровень «джойн + group by», а не «оконная функция с фреймами».

Что PM реально делает с SQL

В типичной неделе PM использует SQL примерно так:

• быстро посмотреть, сколько пользователей сделали целевое действие за неделю;
• проверить, не сломалась ли воронка после релиза;
• собрать когорту для презентации стейкхолдерам;
• посмотреть, как новый сегмент ведёт себя по retention;
• протестировать гипотезу: «правда ли, что пользователи Х конвертируются хуже?»;
• проверить, сходится ли число в дашборде с тем, что показывает PostHog/Amplitude;
• быстро посчитать новый разрез метрики до того, как идти к аналитику.

Глубоких ETL-задач PM не делает. Сложные пайплайны и оптимизация — это работа аналитики и DWH-инженеров. Но базовая исследовательская работа на чтение данных — это PM.

Шкала «когда идти к аналитику»:

• 1 запрос на 10 минут — пишешь сам.
• Сложная воронка с десятком шагов и кастомной атрибуцией — задача аналитику.
• Дашборд с обновлением — задача аналитику.
• Поиск ошибки в данных, проверка гипотезы перед обсуждением — пишешь сам.

Какой уровень SQL ждут на джуне, мидле и сеньоре

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

Джун:

• читать простой select-запрос и объяснить, что он делает;
• самому написать select с where, group by, count;
• понимать разницу inner и left join хотя бы на словах.

Мидл:

• собрать простую воронку или DAU самому, без помощи аналитика;
• читать чужой запрос со CTE и джойнами и не теряться;
• знать про NULL, distinct, integer division — не на уровне «напишу с нуля», а «увижу подвох».

Сеньор:

• то же, что мидл, плюс умение поставить аналитику нормальную задачу: какие метрики, разрезы, окна;
• понимать границы данных — что в логах есть, а чего нет;
• не верить цифрам слепо, задавать аналитику правильные вопросы.

Сложные оконные функции, фреймы (rows between), оптимизация и планы выполнения — это работа аналитика и DWH-инженера. От сеньор PM этого не ждут и не должны. Если в вакансии написано иначе — скорее всего там путают PM и продуктового аналитика, и стоит уточнить на собесе, кто реально пишет SQL в команде.

Что спрашивают на собесе

Типичные форматы:

• live SQL: дают схему таблиц и просят написать запрос (DAU по дням, retention по когортам, топ-3 пользователей по сумме);
• сделать запрос для воронки: сколько пользователей дошли до шага N;
• посчитать конверсию из A в B по сегменту;
• найти ошибку в чужом запросе.

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

• integer division: 5 / 20 * 100 в PostgreSQL даёт 0, а не 25;
• забывают NULLIF(denominator, 0) и получают деление на ноль;
• пытаются отфильтровать по результату оконной функции через WHERE — нужно через CTE;
• не различают inner и left join, теряют пользователей без заказов;
• джойнят два агрегата до деления и завышают числа;
• забывают про DISTINCT, когда считают пользователей по событиям (один юзер = много строк).

Если хотя бы одно из этого узнаёшь как «я бы тут запутался» — стоит порешать задачи перед собесом.

Минимальный набор конструкций

Чек-лист, без которого на собесе будет тяжело:

• select / from / where / group by / having / order by / limit;
• inner join, left join, понимание разницы;
• aggregate: count, count distinct, sum, avg, min, max;
• date_trunc и работа с датами;
• case when для условной логики;
• with (CTE) для разбиения запроса на читаемые шаги;
• window-функции: row_number(), rank(), sum() over (), lag();
• coalesce, nullif для безопасной работы с null;
• INTERVAL и арифметика с датами.

Этого достаточно для 90% задач, которые PM решает сам.

Примеры задач, которые PM решает сам

DAU по дням:

SELECT DATE(created_at) AS day, COUNT(DISTINCT user_id) AS dau
FROM events
WHERE created_at >= NOW() - INTERVAL '30 day'
GROUP BY 1
ORDER BY 1;

Конверсия из регистрации в активацию по неделям:

WITH new_users AS (
  SELECT user_id, DATE_TRUNC('week', created_at) AS cohort_week
  FROM users
  WHERE created_at >= NOW() - INTERVAL '60 day'
),
activated AS (
  SELECT DISTINCT user_id
  FROM events
  WHERE event_name = 'first_activation'
)
SELECT
  cohort_week,
  COUNT(*) AS regs,
  COUNT(a.user_id) AS activated,
  100.0 * COUNT(a.user_id) / NULLIF(COUNT(*), 0) AS rate
FROM new_users n
LEFT JOIN activated a USING (user_id)
GROUP BY 1
ORDER BY 1;

D7 retention по когортам недели:

WITH cohorts AS (
  SELECT user_id, DATE_TRUNC('week', MIN(created_at))::DATE AS cohort_week
  FROM events GROUP BY user_id
),
returns AS (
  SELECT c.cohort_week, COUNT(DISTINCT e.user_id) AS d7
  FROM cohorts c
  JOIN events e
    ON e.user_id = c.user_id
   AND e.created_at >= c.cohort_week + INTERVAL '7 day'
   AND e.created_at <  c.cohort_week + INTERVAL '8 day'
  GROUP BY 1
)
SELECT cohort_week, d7 FROM returns ORDER BY 1;

Если эти три запроса можешь написать без подсказок — на средне-сложных собесах SQL не отсеет.

Как прокачаться без опыта

Рабочий план:

1. Поднять локальную базу с тестовыми данными (PostgreSQL + sample dataset на 5 минут).
2. Пройти бесплатные интерактивные тренажёры (sqlbolt, sqlzoo, leetcode по теме «SQL»).
3. Решить 30–50 задач уровня easy/medium с фокусом на product-метрики: DAU, retention, когорты, воронки.
4. Воспроизвести у себя классические задачи: «топ-3 пользователя в каждой категории», «retention по неделям», «конверсия по шагам воронки», «running total».
5. Регулярно практиковаться, чтобы не забыть. Лучше 15 минут в день, чем 4 часа в воскресенье.
6. Перед собесом — прорешать 10 задач из публичных собесов (DataLemur, StrataScratch и подобные).

После этого на любом PM-собесе SQL уже не отсеет.

Шаблон ежедневной 30-минутной тренировки:

• 5 минут — повторение конструкции (например, оконные функции).
• 20 минут — решение задачи на медиумном уровне.
• 5 минут — разбор «правильного» решения, фиксация ошибок.

Когда SQL не критичен

Есть редкие позиции, где SQL действительно не нужен:

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

Это исключения, не правило. На большинстве рынка SQL — базовый навык, как умение читать.

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

• Учить SQL по теории, не решая задачи. Без практики не закрепляется.
• Зубрить редкие конструкции до того, как закрыта база. Сначала простые джойны, потом window-функции.
• Игнорировать integer division и NULLIF. Это самые частые ошибки на собесах.
• Считать, что аналитик всё сделает за тебя. На крупных продуктовых собесах ждут, что ты сам.
• Решать задачи только в задачниках, не на боевых данных. Боевые данные грязные и учат внимательности.
• Не уметь читать чужой запрос. Часто на собесе дают 30-строчный SQL и просят объяснить.
• Учить «модный» диалект (Snowflake, BigQuery) до базового PostgreSQL.

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

• Что должен знать продакт-менеджер
• Нужен ли Python продакт-менеджеру
• SQL запросы для продуктовых аналитиков
• Метрики продукта: DAU, MAU, ARPU
• Cohort analysis простыми словами

FAQ

Какой диалект SQL учить — PostgreSQL или ClickHouse?

PostgreSQL как базу. ClickHouse — если идёшь в компанию, где он стек (тогда добавишь специфику поверх PG).

Сколько времени нужно, чтобы дойти до собес-уровня?

Если уделять 30–60 минут в день — 4–8 недель до уверенного уровня джуна-мидла.

Нужно ли уметь писать сложные оптимизации?

PM — нет. Это зона аналитика и DWH-инженера. Достаточно понимать, почему запрос медленный.

Что важнее — Python или SQL?

SQL. Python приятный бонус, без SQL на PM-собесе будет очень тяжело.

Можно ли пройти собес PM, не написав ни одного SQL-запроса?

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

Чем отличается аналитический SQL от инженерного?

Аналитический — про чтение данных и метрики (SELECT, агрегаты, окна). Инженерный — про DDL, ETL, индексы, оптимизацию. PM нужен только аналитический.

Как тренировать SQL, если нет своей базы данных?

Использовать публичные датасеты (Kaggle, Northwind), интерактивные тренажёры (sqlbolt, sqlzoo, DataLemur). Альтернатива — локальный Docker с PostgreSQL и dump-файлом.

Можно ли заменить SQL на Tableau / Looker?

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

---

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