Как работать с PM эффективно

Почему это важно

PM — ваш основной stakeholder. От того, как вы строите с ним отношения, зависит:

  • Какие задачи вам дают (strategic vs tactical).
  • Как вас оценивают.
  • Какой impact делаете.
  • Кто вас рекомендует для повышения.

Типы PM

1. Data-driven

Понимает метрики, уважает анализ. Dream для аналитика.

2. Опытный, но without data

«Я и так знаю, что надо». Сложно убедить данными.

3. Инициативный, много идей

Куча проектов, trouble приоритизации.

4. Slow / нерешительный

Бесконечный анализ, ничего не двигается.

Подход к каждому — свой.

Коммуникация

1. Регулярный 1:1

Раз в неделю 30 минут. Обсуждаете:

  • Текущие задачи.
  • Приоритеты.
  • Вопросы.
  • Развитие.

2. Async когда возможно

Slack, Notion docs. Не каждый вопрос — meeting.

3. Proactive обновления

«Запустил анализ X, результаты к пятнице». Не ждите, пока PM спросит.

4. Visual communication

Слова < графики. «Метрика упала» → покажите график.

Приоритизация

Когда PM дал 5 задач одновременно

Возвращайте приоритеты:

«У меня 5 задач: A (strategic), B (ad-hoc), C (dashboard), D (A/B setup), E (data quality). По моей оценке: A > D > C > E > B. Это правильно?»

PM либо согласится, либо скорректирует. Вы защитили себя.

Фреймворк ICE

  • Impact: сколько принесёт.
  • Confidence: насколько уверены.
  • Ease: насколько легко.

Score = I × C × E. Приоритизируйте по score.

Когда сказать «нет»

Не бойтесь:

  • «Не могу сделать это завтра — работаю над A. Могу в пятницу».
  • «Эта задача не соответствует нашим целям квартала. Может быть отложим?»

Senior analyst умеет сказать «нет».

Если хочется сразу закрепить тему на практике — открой тренажёр в Telegram. 10 минут в день — и синтаксис в пальцах.

Фразы, которые работают

При непонятном запросе

«Чтобы дать правильный анализ, уточню: вы хотите узнать X или Y? Это разные вопросы.»

При невозможных deadline

«За day это делается только поверхностно. Если хотите качественный анализ — нужно 3 дня. Или можно быстрый, но с caveat, что выводы предварительные.»

Когда данные неоднозначны

«По данным не очевидно. Можно интерпретировать как A или B. Для decision рекомендую запустить A/B.»

При «мы ведь хотели X, сделай Y»

«Я понял, что мы теперь хотим Y. Это отличается от исходной задачи. Готов, но это займёт N дней. Согласны?»

Типичные конфликты

1. PM хочет другой результат

«Я знаю, что feature работает — переделай анализ, чтобы показал positive».

Не делайте. Защищайте данные. Если PM настаивает — поднимайте к head of analytics.

2. PM дёргает ежедневно

«А этот отчёт когда? А это?»

Решение: weekly 1:1, чёткие priority. Ad-hoc запросы в конце очереди.

3. PM игнорирует анализ

«Всё равно катим, доверяю интуиции».

Решение: это его право. Задача аналитика — дать данные. Решения — PM. Но документируйте anti-data решения для будущих retrospects.

4. Конфликт с другим PM

Два PM хотят одного аналитика одновременно.

Решение: head of analytics приоритизирует. Или split времени (2 дня одному, 3 другому).

5. PM не понимает статистики

«P-value = 0.06 → значит эффекта нет».

Решение: объясняйте проще. Используйте analogies. Терпение.

Что PM ждёт от вас

Tactical

  • SQL-запросы по его запросу.
  • Расчёт метрик.
  • Ad-hoc analytics.

Strategic

  • Insights он не ожидал.
  • Рекомендации by priority.
  • Переводить данные → decisions.

Работа для junior — tactical. Для middle+ — strategic.

Что вам ждёт от PM

Good PM

  • Чёткие задачи с context.
  • Доверяет данным.
  • Защищает аналитика от chaos.
  • Учит product-мышлению.
  • Рекомендует для повышения.

Bad PM

  • «Мне вчера нужно было».
  • Доверяет интуиции > данным.
  • Загружает всех без приоритетов.
  • Таскает на все meetings.
  • Присваивает ваши инсайты.

Если у вас bad PM — решайте с head of analytics или меняйте работу.

Позиционирование

Не будьте «SQL-обезьяной»

Junior пишет SQL. Middle+ думает над продуктом.

Growth pattern:

  1. Junior: «сделай этот запрос».
  2. Middle: «я сделал запрос + заметил X, не проверим ли?»
  3. Senior: «увидел в метриках тренд, предлагаю гипотезу Y, готов A/B».

Постепенно забирайте ownership.

Ownership over metrics

Не просто «считаю метрики по запросу». «Я — owner этих метрик, слежу за ними, alertю, предлагаю action».

PM уважает ownership.

Чтобы не только читать теорию, но и решать реальные задачи — загляните в бот Карьерника. Там по каждой теме подборка вопросов с разборами.

Встречи

Product standup

  • Быть.
  • Слышать про roadmap.
  • Задавать вопросы.

Roadmap planning

  • Аналитик должен участвовать — принести data insights.
  • Предлагать, какие эксперименты из roadmap важнее.

Retrospective

  • Честно говорить, что помогало / мешало.
  • Предлагать improvements.

Email и Slack этикет

Subject/заголовок конкретный

  • ❌ «Вопрос»
  • ✅ «DAU упал 15% — нужен ли анализ сегодня?»

TL;DR в начале

Для длинных посланий:

TL;DR: Новая фича дала +5% конверсии (p<0.01), катить.

Подробно:
...

Context upfront

Не «можешь посчитать X?», а «для PRD по feature Y нужен X».

Emoji разумно

🔴 🟢 — ок для статусов. 🎉 🙌 — ок иногда. Overuse — непрофессионально.

Примеры good interactions

Good

PM: «Почему DAU упал?»

Analyst: «Видел тренд, копаю. Первичный разбор к 16:00 сегодня. Если нужен финальный анализ — к пятнице.»

(Proactive, чёткий timing, прозрачность.)

Good

PM: «Нужно сделать дашборд по конкурентам.»

Analyst: «Уточним: конкуренты каких продуктов? Какие метрики? Для кого audience? Приоритет относительно task X, которую делаю?»

(Уточнение, защита приоритетов.)

Good

PM: «A/B не сработал, но я думаю, если изменить X — сработает.»

Analyst: «Могу провести post-hoc анализ. Если segments показывают, что где-то работает — пере-тест имеет смысл. Иначе — лучше новая гипотеза.»

(Объективность, не прогиб под желаемый вывод.)

Читайте также

FAQ

Сколько PM на одного аналитика?

Типично 1:1 или 1 аналитик на 2–3 PM. Больше 3 — перегрузка.

Что, если PM игнорирует аналитика?

  1. 1:1 разговор о ожиданиях.
  2. Если не помогает — head of analytics.
  3. Если и это — искать другую команду.

Нужно ли аналитику посещать все PM-meetings?

Нет. Приоритетно: standup, roadmap, retros, user interviews. Остальное — по необходимости.

Как не стать «SQL-обезьяной»?

Постепенно предлагайте инсайты, а не просто запросы. Брать ownership. Показывать strategic thinking.